iBeaconハンドブック 出版のお知らせと雑感

このブログに長らく下書きを掲載していたiBeaconハンドブックを、Kindleストアで出版しました。 本書をまとめるまでの事業、講師や講演またハッカソンに呼んで頂いた方々、またハッカソンに参加された方々に感謝します。

出版までの作業

Kindleの入稿ファイル形式はMS-WORDなど様々な形式がサポートされていますが、今回はepub形式で入稿しました。出版までの手順は:

  • Markdown形式で執筆する
  • 図の作成と図表参照を本文に記述
  • 校正

です。

本文はMarkdownという記法で執筆しました。エディタには Submime Text2を使用、SmartMarkdown, Pandoc の2つのパッケージを追加しています。これらのプラグインはハイライト表示に使うだけで、フォールディングや見出しの深さの一括変換といった便利機能は使いませんでした。使い方を都度忘れるため、結局は手作業でやってしまったほうがはやかったのです。

この環境でMarkdown形式の箇条書きの文章に日本語を入力しようとすると、日本語変換の確定時点で入力文字列が空文になりました。しかたがないので、普通のテキストとして書いてから箇条書きの先頭マークを追加する方法でしのぎました。

Markdown形式からepub形式への変換は Pandoc a universal document converter を利用しました。このツールには図表番号の割り振りとその図表番号の参照挿入機能がなかったので、プリプロセッサを作り補いました。そのプリプロセッサとファイル生成のビルドスクリプトは、Githubにあげています https://github.com/reinforce-lab/pandoc_kindle_sample

校正はテキストファイルを印刷したものとMacのiBooksとでおこないました。まず原稿のテキストを印刷してペンで赤入れをしていきます。自分にとっては画面では気づかない誤字脱字に気づく一番効果的な方法です。

テキストを校正したらepub形式のファイルをMacのiBooksで開き、画面出力を確認していきます。Markdown記法のミスで変なタグが本文にそのまま出ていたりしました。

最後にAmazonがMac向けに出しているKindleのプレビュツールで、Kindle形式への変換とプレビュの確認をしました。

Kindle形式の変換時に、テキスト中"#タグ名"みたいなハイパーリンクがあると警告がでたり、数式のマークアップは受付できないと警告が出たりしました。リンクは自分のプリプロセッサの誤りなのでリンク自体を入れないようにプリプロセッサを変更(ちゃんと対応するのが手間だったのと、図表へのハイパーリンクがなくても読む分には同じだと思ったので)、数式は元のテキストをHTMLでベタ書きにしました。PandocはTeX環境を整えれば、数式を画像ファイルに変換して埋め込む変換モードもあるっぽいので、数式をバンバン使うKindle本はそれで作れるのでしょうか?

執筆時間と価格設定

ブログに書いていた内容をそのまま本にしたようなものですが、不特定多数の方が読めるように背景知識の説明を加えて章立てを整えると紙換算で60ページ程度の分量になりました。

一般書店で販売する紙書籍には、ページ数と単価のだいたいの区分があるそうです。開発本なら120ページとか240ページとか、1ページ10円くらいで1200円とか2400円とかのページ数と価格の納得感があるっぽい? 60ページでは薄すぎて流通させるのは無理っぽい。

校正までのかかった時間をページ数で割ると、私の場合はフルタイム1日で1ページを割るくらいのスピードです。1ヶ月20万円を最低収入とすると1ページあたりの最低でも1万円の収益がほしいところです。

Kindleのロイヤリティ(売上のうち販売者の取り分)は35%と70%の2通りが選択できます。70%nロイヤリティの条件の1つは、電子版はKindleでの限定取り扱いとすることです。この限定設定は3ヶ月毎に契約更新ができます。当初3ヶ月はこの設定を使うことにしました。

紙で開発本の価格感は1ページ10円くらいだと思います。240ページくらいで2400円くらい。その換算だと今回の書籍は600円が設定値になります。iBeaconという単語が今話題になっているので、強気の920円としました。

ですから目標販売部数は、60万円 / (920円 * 0.7) = 930部、となります。この手のニッチな開発の電子書籍が売れる部数はせいぜい500部程度っぽいので、労役に対して儲かるものにはならないっぽいどころか、ご飯を食べるのにも困るっぽい。

出版まで

あとはKindleのアカウントを作り口座を登録するくらいです。米国での源泉徴収の免除対象とするために、EINというコードが必要だそうです。

説明を呼んでも一生に1回しかやらない事務作業だと思ったので、取得代行を http://ein.bz に依頼しました。ここを選んだ理由は、自分がもし手続するならどういう手順でなにをするかを詳細説明していて、また他社との価格比較が正確になされていたので、フェアだなと思ったからです。

図書を管理するためにISBNコードというものがあります。個人でも2万円程度の手数料で取得できるっぽいです。このコードは図書分類区分に使われ特定の図書を表す管理コードですが、電子書籍の場合はバイナリが同一であることが条件になるので、電子書籍の販売サイトがそれぞれにDRMをかけるとバイナリが違うものとなり、販売サイトごとに違うISBNが必要となります。

Kindleでの出版登録でも任意入力になっています。紙の制度を電子書籍に持ってきているからでしょうが、制度として同一性に納得がいかないのと、Kindleでの限定販売なので商品の同一性はKindleストアの商品番号で十分だと思い、ISBNは取得しませんでした。

こんな感じ。

大垣第3回iBeaconハッカソン

第3回目を数える大垣でのiBeaconハッカソンは、本物のバスを走らせて、バス停という日常の場面およびバスという移動体でのハッカソンとなりました。 Facebbokのイベントページ

参加された方のブログなど

会場の写真

Facebookにまとめられた iBeaconハッカソン3の写真 写真。

/post/2014-02-26-ibeaconhackathon3/ibh03_bus1.jpg
/post/2014-02-26-ibeaconhackathon3/ibh03_bus2.jpg

今回走ったバスとバスの内部写真です。ちょっとした衝撃でした。MOBIUM

MOBIUMは移動を主体とした表現の場です。 大型バスをベースとしており停車可能な場所であればどこでも作品の展示や音楽の公演、映像上映など問わず表現活動を行うことができます。 この移動空間でさまざまな地域に表現活動を届け、地域間の文化交流を行なっていきたいと私たちは考えています。

/post/2014-02-26-ibeaconhackathon3/ibh03_flag1.jpg
/post/2014-02-26-ibeaconhackathon3/ibh03_flag2.jpg

実験用にバス停にみたてたノボリが用意されました。ハッカソンの文字入りです。ノボリの先端には、3Dプリンタで印刷したケース(選択の黒い筒状の部分)に収納されたビーコンが設置されています。風向きでノボリが回転するので、ビーコンのアンテナの指向性と回転角度が組み合わさって、面白いビーコン領域になりそうです。

/post/2014-02-26-ibeaconhackathon3/ibh03_flag3.jpg
/post/2014-02-26-ibeaconhackathon3/ibh03_flag4.jpg

室内で実験するために小さなノボリも用意されました。手のひらサイズのノボリの下部に、こちらも3Dプリンタで印刷されたケース(黒い部分)に格納されたビーコンが置かれています。場面にあわせた機械部品を3Dプリンタで作れると、便利なのですね。

会場及び懇親会の様子を微速度撮影したものです。解像度が落としてありますが、皆さんがどのような動きをされていたのかわかります。

第3回iBeaconハッカソン

iBeaconは、Apple社がiOS7で導入した位置と近接検出技術です。 iOS:iBeaconについて 昨年12月に初めてのハッカソンを開催してから3回目を数えるまでになりました。ハッカソンは、“ハック"と"マラソン"を組み合わせた造語で、開発者やデザイナが集まり集中的に共同作業をするイベントを表す言葉です。

第1回iBeaconハッカソン は本物のiBeaconに触れる体験を、 第2回めのハッカソン はOnline to Offline (O2O)、オンラインの体験とオフラインの体験が相互に影響しあう時代、をテーマに設定しました。

第3回目 は、本物のバスを走らせて、バス停というありふれた日常の場面そしてバスという移動体を取り上げました。スマートフォンの普及率が高まった今年は、ありふれた日常の場面でビーコン活用が徐々に登場するでしょう。

ハッカソンには、東京からの日帰り参加が難しい大垣という場所ですが、30名弱が集まりました。 iBeaconのビーコンを次々と発表されている(株)アプリックスそしてiBeaconのビーコンとコンテンツ管理システムの統合フレームワークを提供されている(株)ACCESSからも参加をいただきました。第1回目および2回目から引き続き参加されている方が半分弱、新規参加者が半数と参加者の顔ぶれがある程度固定してきたのかなと思います。

第3回目もビーコンは(株)アプリックスから提供を受けました。

プログラム

ハッカソンは午前と午後の部の2部構成です。 午前中に、自己紹介とiBeaconの紹介とバスでの体験を行い午後はアイディア出しと実装を行いました。 お昼及び夕方には、Google GlassとiBeaconの連携や、コンテンツ管理システムのデモンストレーションなど、2回目に参加された方々が作られたものを持ち込まれてのデモンストレーションがありました。

  • 11:00〜12:30:イントロダクションとデモアプリの体験
    • 11:00〜11:30:自己紹介
    • 11:30〜12:00:プレゼン
    • 12:00〜12:30:実際に体験(iPod touch配布)
  • 12:30〜13:30:昼食(お弁当)
    • Googleグラスのデモンストレーション(体験)
    • コンテンツ管理システムのデモンストレーション (2〜3回講演 5分間程度)
  • 13:30〜14:30:チームごとにアイデアスケッチ
  • 14:30〜17:30:実装
  • 17:30〜18:30:体験(日没は17:40)
  • 18:30〜19:00:ディスカッション(GoogleGlassデモ等)
  • 19:00〜22:00:懇親会(近くの居酒屋を予定)

イントロダクション

イントロダクションのプレゼンテーション資料です。

/post/2014-02-26-ibeaconhackathon3/ibh03_map.jpg

今回のハッカソンは初めて屋外にビーコンを設置しました。写真はB地点にある、今は使われていないバス停の金属柱に貼り付けたビーコンと、そのビーコンの電波が届く範囲(青色の楕円部分)を示しています。ビーコンが出す2.4GHzの電波は金属で反射され、柱の反対側(地図上では北側/上方向)にはほとんど届きません。下方向(地図上で南側/下方向)にはビーコンがよく見通せて50m近く電波が受信できます。

iBeaconハンドブックの下書き

このブログに長らく下書きを掲載していたiBeaconハンドブックを、Kindleストアで出版しました。 本書をまとめるまでの事業、講師や講演またハッカソンに呼んで頂いた方々、またハッカソンに参加された方々に感謝します。

1月29日 大垣 第2回iBeaconハッカソン

いただいた紙の名刺をスキャナで取り込みながら、第1回iBeaconハッカソンに出ていた、ビーコンのある領域に一定時間一緒にいた人たち間で、名刺的なデータを自動記録できるアプリケーションでも作っておけばよかったと、今頃思っている(同)わふうの上原です。

会場の写真、参加された方のブログ

第2回iBeaconハッカソン

iBeaconは、Apple社がiOS7で導入した位置と近接検出技術です。単語として話題になるiBeaconですが、ビーコン体験の実際とその体験談を交換しあう場として、昨年12月に(おそらく世界初、確実に日本初)のiBeaconハッカソンを開催しました。ハッカソンは、“ハック"と"マラソン"を組み合わせた造語で、開発者やデザイナが集まり集中的に共同作業をするイベントを表す言葉です。

第1回iBeaconハッカソン http://reinforce-lab.github.io/blog/2013/12/18/ibeaconhackathon/は、iBeaconの体験を通して自由な場面想定をしました。ビーコンというガジェットと自分、あるいはガジェットと周囲にいる人という場面でのアイディアが多く出ました。

第2回めは2014年1月29日に第1回と同じ岐阜県大垣市 ドリーム・コア2Fメッセで開催されましたイベントページ: https://www.facebook.com/events/628415297227268/

第2回めは、あえて単語として話題になってきているOnline to Offline (O2O)、オンラインの体験とオフラインの体験が相互に影響しあう時代をテーマに設定しました。第1回で提供した技術の理解と実際の振る舞い体験を糧にして、道具としてのiBeaconが未来にどのような形で一般世間に溶け込んでいるかを体験するのが狙いです。

ハッカソンには、東京からの日帰り参加が難しい大垣という場所ですが、30名弱が集まりました。第1回に参加された方が半数、今回第2回めに参加された方が半数という感じでした。2回めは1回めよりも経営者や企画そして大手やベンチャーで、業務としている方やこれから事業を立ち上げる方が多く参加されていました。技術という手段ではなく、道具としての技術手段に興味を持っていただきたい狙いに、反応して欲しい立場の方々が集結されたのだと思います。

第2回も、ビーコンは(株)アプリックスから提供を受けました 岐阜県、iBeaconハッカソン(第2回)を開催 http://www.aplix.co.jp/?p=8240

プログラム

ハッカソンは午前と午後の部の2部構成です。午前中に、自己紹介とiBeaconの基礎、そしてPassbookのプレゼンテーションを通して知識を共有しました。

  • 11:00〜12:30:イントロダクション+iBeaconとPassbook連携レクチャー
  • 12:30〜13:20:昼食(実店舗でのiBeacon体験)
  • 13:20〜14:30:施設内でのiBeacon体験
  • 14:30〜18:00:グループ毎にアイデア出し、実装、テスト – アイデアスケッチセッションの説明:10分 – だれ/いつのマトリクス(デザインパターントランプを使って):20分 – アイデアスケッチ:30分 – 実装とテスト(前半):60分
  • 進捗の共有、実装とテスト(後半):90分
  • 18:00〜19:00:各チームの実装したものの体験とディスカッション
  • 19:00〜22:00:懇親会

このように内容をぎっちり詰め込んだタイム・テーブルでしたが、時間通りに進行しました。進行を担当された小林先生と参加者の方々のレベルの高さがすごかったです。

お昼ごはんは、ソフトピアジャパン1階のレストラン、こみゅれす美濃味匠で、iBeaconでPassbookを反応させて割引クーポンを出して、ワンコインランチを注文する体験をしました。これは、割引クーポン(割引費用)の提供とレストランへのビーコン設置と注文受け付けの対応など、(株)デリカスイトの提供と協力で実現しました。

午後はiBeaconの振る舞いを体験した後、チームに分かれてアイディアスケッチとディスカッション、そしてビーコンに反応するコンテンツを作り、デモンストレーションを行いました。

ビーコンに反応するコンテンツを作れるiOSアプリケーションは、(有)トリガーデバイスから提供されました。提供されたアプリケーションは、館内地図にビーコン配置が表示され、訪問したビーコンの表示変化およびコンテンツ表示をするアプリケーションで、コンテンツをDropbox経由で更新できるものです。

/post/2014-01-30-ibeaconhackathon2/20140129-01.jpg

イントロダクション

イントロダクションのプレゼンテーション資料です。

最初は上原がiBeaconの概要をプレゼンテーションしました。Slideshareにアップロードしたこの資料はよそ向きですが、実際のプレゼンテーションは"ぶっちゃけ話"を入れていました。

プレゼンテーションでは、O2Oという単語は様々な人がそれぞれの文脈で使うため定義があやふやでわからない、と切り出しました。そこでO2Oという単語はあえて忘れて、2年後の(O2Oっぽい)日常を想像してみよう、と提案しました。その日常を支えているビーコンなどの設備、そしてコンテンツを作り配布する会社やサービス提供会社がどのようなものか、その日常に至るまでの2年間の経緯を具体的に想像することを、提案しました。

次のPassbookのプレゼンテーションは、ユーザが手軽にPassbookを使えるサービス、パスタhttp://passta.jpを展開されている、株式会社モノプレーン代表取締役 小西 啓一郎さんにお願いしました。

O2OでのiBeacon活用のデザイン・パターン

O2O(オーツーオー)は、オンラインとオフラインの購買活動がそれぞれ連携/影響しあう、またオンラインでの活動が実店舗での購買活動に影響をすることを示す用語です。出典 http://www.sophia-it.com/content/O2O

ネットワークと常時同期するスマートフォンが普及した今日では、もはやオンラインとオフラインを区別する意味はありません。経済活動の主体となる個人を軸にすえれば、スマートフォンや実店舗は、購買の手続きや支払いの窓口や、受け取り場所といった手段にすぎません。

ここでは、iBeaconがO2Oでどのように活用できるか、また逆に、O2OでやりたいことにiBeaconが使えるか、を考えるうえで押さえたい項目を列挙します。

基礎知識

iBeaconはなにか、その原理とiOSでの振る舞いは、スライドを参照してください。

iBeaconは、Appleの登録商標で、領域と近接の検出技術をしめす言葉です。電波を出すビーコンがあり、iOSはビーコンの電波を監視して、ビーコンの領域に入った/出たをアプリケーションやパスブックに通知します。

iBeaconは単なる領域と近接の検出です。これを使いアプリケーションを作れば、 例えば決済やカタログ表示など、位置に紐付いたサービスを提供できます。

ビーコンはUUID(128ビットの識別子)、major番号(16ビットの符号なし整数)、そしてminor番号の情報を電波に乗せて、周囲に送信しつづけるものです。iOSのパスブックおよびアプリケーションは、ビーコンの監視にUUIDを必ず指定しなければなりません。つまり、ビーコンのUUIDを事前に知っていなければなりません。

また、ビーコンが多数同じ場所にあっても、互いの電波がぶつかったりして、ビーコン信号が検出できなくなることは、ほとんどありません(1つの場所に100個以上のビーコンがあれば、すこし衝突するかもしれませんが)。ですから、同じ場所に思い思いに多数のビーコンを配置しても、混信してビーコン信号が検出できなくなったりは、しません。

デザインパターン、その1

/post/2013-12-26-ibeacon-o2o-design-pattern/20131227_fig4.png

エリア

iBeaconは領域と近接の検出技術です。そのビーコンの配置と建物の構造を組み合わせます。

ゲートは、入り口の領域をビーコンで覆います。この入り口への出入りを検出できます。エリアは、どの領域にいるか、またどの領域からどの領域に移動したかを検出します。最後のスポットは、例えばレジの周囲でのみイベントを起こしたいときには、そのスポット領域を覆うようにビーコンを設置します。

/post/2013-12-26-ibeacon-o2o-design-pattern/20131227_fig1.png

ビーコンを出している時間

ビーコンの電池は、24時間電波を出し続けても、数年程度連続動作します。ですから、ビーコンは電波を出し続ける設定で、どこかに設置して利用します。ビーコンのハードウェアの内部にあるマイコンで、ファームウェアという小さなプログラムを入れることができます。ですから、ビーコンの発信を決まった時間に設定したり、あるいはいまビーコンを出したい/止めたい、という操作ができるビーコンも、作れます。

検出のタイミング

iOSがビーコンの電波を検出するタイミングは、3つあります。1つはロック画面が表示された瞬間です。例えばiPhoneをポケットから取り出して、ホームボタン/スリープボタンを押した瞬間に、ビーコンの電波をチェックします。2つめは、アプリケーションのバックグラウンド状態です。iPhoneの画面が表示していない間も、領域を監視し続けるアプリケーションが作れます。3つめは、アプリケーションのフォアグラウンド状態です。バックグラウンド状態で取れない、ビーコンとのおおよその距離(10m程度のばらつきがある)まで取得できます。

作用

ビーコンを検出した時に、iPhoneからユーザになにかしらの影響を与えられます。アプリケーションがバックグラウンドでサーバと通信するだけのように、ユーザにはなにも影響を与えないこともできます。ロック画面に通知を表示したり、電話着信のように音や振動をだすこともできます。またユーザが画面を見ている時であれば、画面の上に通知を表示したり、またアプリケーション自体が実行されているならば、画面に何かを表示することができます。

モチベーション

iBeaconの話題の多くは、売り込む側の人たちや大手流通を想定した、もっと儲かりますと主張する場面説明でうめつくされています。しかし、大切なのは、iBeaconを利用する側の動機です。例えば、ビーコンの領域に入った時に、割引クーポンを発行することができます。また、買い物の場面であれば、自分にあったサイズの商品がどれかをお知らせすることもできます。売り手が買い手に主張するほかに、ユーザ自身がやりたいことをできる場面も多くあります。例えば、牛乳を買おうとメモをしていれば、牛乳がどこにあるのか、教えてくれる仕組みも作れます。

デザインパターン、その2

/post/2013-12-26-ibeacon-o2o-design-pattern/20131227_fig2.png

表の目的、裏の目的

ユーザに、こう使ってくださいという説明と、その使いかたをすると副次的に得られる情報を別の用途につかうことも、規約とユーザの受け取り方や感情に問題がないならば、できるでしょう。例えば、広大なショッピングモールでお目当てのお店までナビゲーションを提供するアプリケーションがあったとします。どの経路を通ったかをサーバとやりとりしていれば、ユーザの移動経路はサーバ・ログに残るでしょう。そのログには、仕入れや売上計画を作る基礎データとして、解析する価値があるでしょう。また、ビーコンを利用した支払いやクーポンの利用履歴は、サーバに記録が残ります。いつ、だれが、なにを購入したかは、仕入れ計画や商品開発に役立つ貴重な情報です。

商品の性質

iBeaconとO2Oとを商品販売に活用する場合、その商品が、いつどこで購入できるものかで、ビーコンの活用方法が異なります。 例えば、工芸品や季節の果物など今この時しか購入できない一品物の商品は、その商品が欲しくて買いたい人と商品の出会いを作ることになるでしょう。 自社のオリジナルの商品群をもち、オンラインと実店舗それぞれで販売をしているならば、実店舗はショールームとして、商品を体験できる場に特化していくかもしれません。 また本やCDなど、どこで購入しても同じ商品が手に入るものならば、納品予定日と価格、そして故障対応などのアフターケアと、価格を比較して、たとえ目の前に商品があっても、別の場所で購入するかもしれません。 それぞれの場で、ビーコンの活用場面はあるでしょうが、その活用方法は異なるでしょう。

更新をかけるところ

パスブックをつかうにせよ、アプリケーションをつかうにせよ、実店舗と連携してコンテンツを更新していくことが重要です。その更新を、いつ、だれが行なうかは、2通りあります。チェーン展開をしている場合は、全体の運営を取り仕切る部署が行うでしょう。また、個別の店舗ごとに、あるいは現場の担当者の判断で、更新をかけたい場合もあります。

UUIDの所有/利用範囲

ショッピングモールなど、ビーコンを利用するがそのデータは一切外部にださず自社内部でのみ利用するならば、UUIDは自社内だけで運用します。決済のように、サービスの利用のためにビーコンを顧客店舗に設置する場合も、サービス提供会社自体がUUIDを管理し、外部に提供することはないでしょう。公共機関やイベント施設であれば、設備として設置されたビーコンを、第3者が利用できるようにルールを作るかもしれません。

デザインパターン、その3

/post/2013-12-26-ibeacon-o2o-design-pattern/20131227_fig3.png

動作環境

データが全てiPhoneにあるならば、ビーコンとアプリケーションのみで、ローカルで閉じた利用ができます。3GやWiFiが使えない場所や、WiFiが利用できない場所でiPod touchで運用したい場合には、これを選択します。またロギング系であれば、アプリケーションからクラウドに、データを送ります。コンテンツを更新するものであれば、クラウド側と通信をして、ローカルのデータを更新します。

購入と利用の流れ

O2Oという単語では、これは重要だと思うのですが、商品やサービスの購入のタイミングと利用するタイミング、あるいは購入から利用までの流れで、ビーコンの活用方法が異なります。実店舗は、目の前に商品があり、それに触れることができます。そして購入できます。もしもショールーム化した店舗であれば、実店舗で購入手続きを行い、宅配便で後日配送されます。航空券や宿泊施設は、購入と利用タイミングがずれます。オンラインなどの手段でまず購入して、実店舗で利用します。購入時に入力した情報と実店舗での利用者をひもづけるために、アプリケーションを使うならば、簡便にアプリケーションを表示するためにビーコンを利用するのもいいでしょう。

ペンと紙は強い

/post/2013-12-26-ibeacon-o2o-design-pattern/20131227_fig5.png

モバイル、あるいは自動化の仕組みがあっても、それを運営するのは人間です。 そして人間が理解できるものは、ペンと紙でできること、だと思います。

電車に乗る場合でも、スマートフォンで予約してICカードで入場する人がいる一方で、切符を窓口で購入して切符で入場する人もいるように、利用者視点での手段の提供が求められます。

デザインパターン、その0

ロック画面を表示した時に、iOSはビーコンをチェックします。実店舗にビーコンを設置しておくと、そのビーコンの周囲でロック画面を表示した時に、実店舗に該当するパスブックやアプリケーションをロック画面に表示させられます。今いる場所に紐付いた自然な表示方法として、これを活用できます。

たくさんあるパスやアプリケーションをいちいち起動するのは、大変な手間ですし、支払いのためにユーザがアプリケーションをレジ前で探していては、レジに長蛇の列ができてしまいます。

パスブックとアプリケーションの使い分け

パスブックとアプリケーションの使い分けは:

  • 1画面を表示するだけの機能ならばパスブック、その他の機能を提供するならアプリケーション。
  • ロック画面に、ビーコンがあれば表示すればよいパスブック、表示する/しないをiPhone内部で判断させたいならばアプリケーション。

とします。パスブックは、Appleの審査は不要で、電子メールなどで配布ができ、コンテンツの作成も楽で、安価です。アプリケーションは、任意の処理を盛り込めますが、AppStoreの審査をうけて一般配布ができます。開発費用がかかります。