Appの配信 – アドホックからエンタープライズまで

(音楽)

(拍手喝采) 私はアシュリー･キャロル アプリケーション開発の コンサルティングエンジニアです 企業 政府 教育機関といった 大口のカスタマーが 従業員向けアプリケーションを構築し 配布するのを助けています セッション304へようこそ アプリケーションの配信を したことがある人は？ なるほど　オーケーです 皆さんのアプリケーションが App Storeで公開する一般向けAppでも 企業内で使う非公開のAppでも 今日 学べることはあるはずです

アプリケーションの配信について 説明するため まずアプリケーションの ライフサイクルについて話します ご存じのとおり すべては問題に直面し 解決策を探るところから始まります その後アプリケーションを構築し 完成させて 大抵はApp Storeを介して ユーザに届けます

今日の話はユーザがアプリケーションを デバイスに入れる最終段階の話です App Storeで公開する場合は単純ですが アプリケーションの配信方法は 他にもあります

カスタマーによって違うのです

ユーザにアプリケーションを届ける 最善の方法とは？ ユーザは 一般人か企業 または教育機関ですか？ アプリケーションの目的により 配信方法も異なります 今日 紹介する配信方法は４つ “Ad Hoc”“App Store” “In-House”“カスタムApp”です 皆さんのアプリケーションに 適した方法は？

これを判断するために 考慮すべき要因は複数あります オーディエンスは誰か？ ソースコードの保守をするのは誰か？ 誰かの依頼で構築する アプリケーションか？ 誰かが 従業員や学生のために 購入するアプリケーションか？ 問題になるのは“誰”であり 中でも着目すべきは ユーザと 購入するカスタマーです

カスタマーとユーザが 別の場合もあると認識しなければ 自分のアプリケーションに適した 配信方法を見極められません オーディエンスが特定できれば 配信方法も選びやすいでしょう 大抵 カスタマーとユーザは 同一の個人です App Storeから所有デバイスに Appをダウンロードし 使います Ad Hocは テスト用アプリケーションを 限定数のデバイスに配信する方法で App Storeは一般公開用です ビジネスや教育の市場では カスタマーが組織のこともあります 組織がユーザグループのために アプリケーションを購入し ユーザは 組織所有のデバイスや 自前のデバイスにAppを入れて使います

この場合の配信方法は In-HouseまたはカスタムAppです どちらも組織内に限って アプリケーションを配布できます

全部を段階的に経る アプリケーションもあれば １つの方法しか経験しない アプリケーションもあるでしょう 配信方法の区別は― Apple Developer Programでの メンバーシップ種別とも関係します 詳細はこれから１つずつお話しします 皆さんに知っておいてほしいことや 配信方法の決め方もお伝えします

まず アプリケーションの ライフサイクルの話から プロトタイプを作り App Storeで配信するまで または事業用にカスタマイズし 組織内で配布するまでです これは“LunchControl”というAppで 用途は食事の注文です このAppのデベロッパになったつもりで 私の話を聞いてください まず 誕生のいきさつです テイクアウトを注文したがる人が オフィスに大勢いました しかし それぞれの注文を聞き 買ってくるのは面倒な作業です 全員の注文を聞き 情報を集約しなければなりません トレバーはトマト抜きバーガーで ボスは“いつもの”で 新人のロッドは ターキーのクラブハウスサウンド ありがちですよね 時間がかかり 注文したくなくなります しかしAppで解決できそうなので プロトタイプを作ることに Xcodeをダウンロードし SDKをいじるため Apple IDでログインします 最初の手順は 多くの方が知っていると思いますが 駆け足で紹介しておきます 未経験の人もいるでしょうし 念のため全ステップを話せば どこかで目新しい話も出てくるでしょう

共同注文ができるAppの プロトタイプができました 注文の内訳も各自の支払額も 表示される仕組みです さて これをデバイスで動かすには？ XcodeにApple IDでログインし Personal Teamという 無料アカウントを活用してください SDKが使え 自分のデバイスで アプリケーションのテストができます 少数のアプリケーションを 数台のデバイスに展開できます 数日で期限が切れるので 本格的な配信ではありません

これがXcodeへのログイン後 見える画面です アプリケーションを実行すると Xcodeがインストールを開始 しかし デバイス側で 開発元を信頼する必要があります 開発元を信頼するには― デバイスの“設定”から“一般”に入り “プロファイルとデバイス管理”へ

このPersonal Teamでの配信は デベロッパの学習が目的です デベロッパが自分のデバイスに 展開する前提であり それ以外のデバイスには配信できません CloudKit Siri APNSなどは 使えませんし App Storeに出したり 他ユーザにテストさせたりもできません

LunchControlは この段階では終わりません どう進むか 配信方法と絡めて説明します Ad Hocは テスト用の配信に使います

これまではデスクを回って ランチの注文を受け アプリケーションは シミュレータと 自分のデバイスでテストしていました ここで数人にAppを試してもらい フィードバックを得ましょう Siriと連携させたり プッシュ通知をつけたりもできます これらはPersonal Teamでは無理です

この段階で Apple Developer Programの メンバーシップが必要です アカウントをお持ちでなければ この時点で 法人または個人でご登録ください 登録したら いよいよ他の人に配信できます

Ad Hoc配信では 限られた人数のユーザが デバイスにAppをインストールできます この時 デベロッパWebサイトで デバイスの登録が必要です 開発とテストに登録できるデバイスは 数に限りがあります １プロダクトファミリーにつき 年間100台までです

一般的には Macにデバイスを接続し FinderのサイドバーかXcodeから 識別子を確認します つまり物理的にデバイスが必要です

その識別子を デベロッパWebサイトに登録します 登録が済んだら ビルドを作り インストールします

Ad Hocビルドをインストールするには テスターのデバイスをMacに接続し Xcodeか Mac App Storeにある Apple Configuratorを使います リンクからのインストールも可能です 以上は 少人数のグループに 手動で配信する方法です

テストのため 登録済みデバイスに Appを展開するのがAd Hocです 長期の展望も 拡張性もありません プロビジョニングプロファイルは 年１回 期限が切れるので アプリケーションを継続して使うには 再署名が必要です チームが大人数なら デバイス上限の確認を 使えるデバイスが不足すると 新製品の開発は困難です テスター用の開発デバイスを使う場合は ご注意ください 登録デバイスは年１回リセットされます 当該アカウントのリセット期限は デベロッパWebサイトの メンバー用ページでご確認ください

Ad Hoc配信では 数人でテストができます テスターが増えるにつれ 拡張性の限界を実感するでしょう そこでApp Store配信です

App Store配信なら 大人数で ベータ版のテストができます LunchControlへの関心が高まったので テスターを増やしましょう

TestFlightは Appを試したい デベロッパとユーザ双方に使いやすく インストールもアップデートも 簡単です テスターは１万人まで増やせ ビルドは３カ月 動かせますし おなじみの手順で インストールできます 外部テスター用ベータ版ビルドは 審査が必要なので App Store Reviewガイドラインに 従ってください 広範に配信するのですから 安定性が必要です App Store Connectチーム内だけで テストするビルドなら 審査は不要です Apple Developer Programメンバーしか TestFlightは使えません

TestFlightは App Store Connectの中で使います Apple Developer Enterprise Programを 普段使っている皆さんは この画面は 初めて見るかもしれませんね App Store Connectでは App Storeへのアップロードや 提出 管理が楽にできます TestFlightビルドがここで全部見え テスターも招待できます テスターは TestFlight Appから アプリケーションをインストールします

TestFlightでテスターを招待すると 彼らはＥメールを受け取ります テスターは詳細を確認して Appをインストールし テストを開始

ビルドが十分に安定したら App Storeに提出します

LunchControlは ベータ版テスターの意見を得て 機能が追加され アップデートされました 配信準備を整え アイコンも新しくしました

では いよいよ提出しましょう ここでユーザと カスタマーについて考えます どちらも一般人なら App Storeでの公開が適切です 誰でも皆さんのAppを使えますし 購入者とユーザは同じでしょう

ここでApp Storeでの配信の説明を 個人も組織も Apple Developer Programに登録して Storeで アプリケーションを配信できます デベロッパが選んだ市場に向けて アプリケーションが公開され Appleがホストと審査を行います

つまりデベロッパはApp Store Review ガイドラインに従うべきです そして 時代の流れに合わせ― 最新のハードウェア 画面サイズ API 新機能をサポートしてください WWDCの発表内容にも対応を 繰り返しになりますが App Storeで公開するAppは一般向けです 特定企業の従業員だけが使うAppを 構築しているなら App Storeで公開するのは おそらく不適切です デベロッパが経験しそうな筋書きを もう少し紹介します

例えばカスタマーが グループ向けに Appを一括購入するケースです これを実現する プログラムがあります

LunchControlを作ったあなたには 教員の友人が多く 彼らの学校が 全教師のために このAppを購入したいと言ったら？ デベロッパが App Store Connectで 割引を有効にすることも可能です この場合 Appを使うユーザは教師 つまり一般人ですが Appを購入するカスタマーは ユーザが勤める学校です

カスタマーはApple Business Managerか Apple School Managerを使い LunchControlのようなAppを Storeから 一括購入してユーザに配布します

教育機関が割引を 受けられるようにするには デベロッパがApp Store Connectの “価格および配信状況”で設定します デフォルトの配信オプションは “教育機関用の一括購入割引で 配信可能”です 教育機関がまとめて20以上 ライセンスを購入した場合に ５割引きになるオプションです カスタマー側は Apple School Managerが必要です

次に 適切なバージョン設定と 機能の追加についてお話しします LunchControlは人気が出て 追加機能の要望が入り始め 多くの組織が興味を持ち始めました 一部のユーザや組織が 全オーディエンスに向かない機能を 要望するかもしれません よってバージョンアップは 注意深く行うべきです 顧客ベースが拡大すれば 複数のバージョンを 配信することもあり得ます 例えば管理者バージョンと 通常バージョンなど ユーザごとにバージョンを 変える場合も考えられます その場合 App Storeでの表示は？

きちんと管理しないと こんな状況になり得ます 実際に見られるケースです 配信している企業と アプリケーションの名前だけが同じです これはダメです バージョン設定に失敗したAppを ユーザが検索したら こんな画面が出ます どれを購入すべきか分かりませんし 誤ったアプリケーションを購入すれば 使えない可能性も ユーザは さぞ怒るでしょう ソフトでバージョン管理をすれば 容易に避けられる問題です 購入済みアプリケーションも 適切にバージョンアップさせられます

デベロッパはAppのバージョンを 極力 統合すべきです 左のような１バージョンが理想でしょう 開発側の手間は増えますが 顧客体験を改善するためです Appについて様々なカスタマイズの 要望を聞くようになったら カスタムAppとして 非公開版の配信を検討しましょう この詳細は後ほど

別の筋書きは 誰かの依頼で アプリケーションを構築する場合です あなたの会社 Liquid Oxygen社が カスタマーに 一般向けAppの構築を 依頼されたとします 具体的には Liquid Oxygen社が カスタマーの飲食チェーンTaco Barに アプリケーション開発を依頼されました

Taco Barは LunchControlを気に入り 食事注文用のアプリケーションが 欲しいとのこと 客はAppで 近くの店舗を見つけ 支払いも済ませます Taco Barにとって 初めての主力アプリケーションです デベロッパのあなたが 知的財産を渡したくなかったら？ この筋書きでは Appのユーザは一般人ですが カスタマーはTaco Barとなります Taco Barのためのアプリケーションを 彼らの客向けに開発しつつ 知的財産を維持し Liquid Oxygen社の名を残すには？ この場合 別のバンドルIDを持つ 新アプリケーションを LunchControlと並べて App Storeに出すことになります 同じアプリケーションを 別のカスタマー名で出すのとは違います 顧客体験が違うからです Liquid Oxygen社がTaco Barの サードパーティになる場合 カスタマーと どう協力するのがベストでしょう？

Taco Barは Liquid Oxygen社の人を雇い 自社アカウントからAppを売り出します デベロッパはTaco Barの Developer Programに加わり アプリケーションのビルドを 提供します ワークフローは次のとおり Taco Barは Liquid Oxygen社に ２つの役割をアサインします DeveloperとMarketingです この２者は ビルドをアップでき Appの詳細やスクリーンショットなど 販売メタデータも渡せます Adminの役割は Taco Bar内に残すべきです

そうすれば Taco Barが TestFlight配信や価格や提出を制御でき 配信を開始できます App Managerも内部で担当すべきです

これがApp Store Connectの “ユーザとアクセス”画面です AdminとApp Managerの役割を持つ人が ユーザの追加と編集ができ そのアプリケーションへの アクセス権を制限できます サードパーティデベロッパの アクセス権は 担当Appに限定を ただし デベロッパWebサイトでの アクセス権は制限できません デベロッパWebサイトでは ユーザは 全バンドルIDにアクセスできます ご覧のとおり デベロッパのトレイシーは Taco Barのアプリケーションにしか アクセスできません LunchControlとLiquid Oxygen社が Taco Barと無関係になれば カスタマーはユーザから サードパーティデベロッパを外せます

事業向けアプリケーションを 開発しているなら App Storeへの提出は その事業体にしかできません クライアントのアカウントを 通す必要があるのです Taco Barの利用客はアプリケーションを Taco Bar社からダウンロードします Liquid Oxygen社ではありません 詳細はApp Store Review ガイドライン 5.2へ

AdminやApp Managerなど重要な役割は サードパーティデベロッパには与えず 彼らがアクセスできるAppは 担当分に限るべきです アプリケーションの 適切なバージョン設定もお忘れなく

以上 App Storeで公開するAppの 配信についてご説明しました

残りの時間は 事業向けカスタムAppの 配信方法を― ２つお話しします 内部用途に限った アプリケーションの配信方法です １つ目はIn-House すなわち組織内配布です LunchControlの例に戻ります

うれしいことに Acme社から連絡がありました LunchControlのカスタマイズ版を 社食とケータリング用に欲しいそうです LunchControlと同じ方法で 従業員に食事を注文させたいとのこと つまり同社のバックエンドシステムを アプリケーションに組み込み 完全なカスタマイズ版を構築するのです このケースでは Acme社がカスタマーとなり ユーザグループとなる従業員のため アプリケーションを購入するわけです このアプリケーションを “Acme社カフェ”とします オーディエンスは非公開で 企業の従業員だけなので App Storeで公開するのは 明らかに不適切です 内部用途のアプリケーションを 配信する方法は２つ想定できます In-HouseとカスタムAppです

以前なら Acme社は― Apple Developer Enterprise Program アカウントを使ったでしょう そしてIn-House配信を 活用したはずです 長い間 これしか方法がなかったのです 最近 こうしたアプリケーションを カスタムAppとして App Storeのインフラで ホストすることが可能に その方が多数の利点があるのです Apple Developer Enterprise Programも まだありますが 内部用アプリケーションを配信する 標準的な仕組みではなくなりました そちらが好都合な時もあります ただ 組織内部向けアプリケーションを 構築する人の大半は カスタムAppを選ぶべきです

In-House配信については 参考までに仕組みだけ紹介します この方法では 全配信過程を制御でき 自らアプリケーションをホストできます Apple Developer Enterprise Programの メンバーシップが必要で その上 厳格な資格要件もあります カスタムApp配信では 解決できない場合にのみ使います Apple Business Managerが 使えない地域や 州や連邦政府で使う場合などです その他 知的財産の問題で In-Houseが妥当なケースもあります In-House配信を活用する組織は ソースコードを所有かつ保守します 自らアプリケーションを構築し 管理するのです 配信は完全にApp Store外で 通常 組織が― モバイルデバイス管理 すなわちMDMにより行います

In-House配信を使うべきケースがあれば 次の点に注意してください 第１に In-House配信により 展開するアプリケーションは 絶対に 従業員以外に 渡らないようにしてください 第２に Appには組織が署名した 配布用証明書がついており その証明書を保護する必要があります 何らかの理由で 漏えいや取り消しがあると その証明書で展開した全Appが 即座に動作を停止します そして改めて 署名と展開が必要になります そんなことが起これば 事業にとって大打撃です

第３に期限ですが 証明書は３年ごとに プロビジョニングプロファイルは １年ごとに切れます よって期限を管理し それに合わせて 配信計画を立ててください 第４に ベータ版のテストとホストは 組織とMDMで実施すべきです 法人アカウントは TestFlightにアクセスできません 第５に Appは定期的に ネットにアクセスするため エアギャップネットワークでの展開は 困難です

以上を鑑みると Acme社のケースは In-House配信には不適でしょう では次は 今後の選択肢である カスタムAppについて

２つの筋書きが想定されます まず デベロッパ自身が カスタムAppとして配信する方法 デベロッパのアカウントで売るので 知的財産が守れます 取引形態はB2Bで これが旧来のカスタムAppの使い方です デベロッパがAcme社と交渉し ソースコードを渡す方法もあります Acme社が 自身のアカウントから カスタムAppを提出するので 法人対個人の取引となります いずれにしてもカスタムAppが適切です

カスタムAppの配信方法は？ カスタムAppは Apple Developer Programの一部で Apple Business Manager内で Appleがホストします かつてカスタムAppは他組織にAppを売る デベロッパが使うものでした しかし今は In-House配信と同様に 従業員への内部配布にも使えます この方が楽に 従業員に アプリケーションを配布できます カスタムAppは 従業員 協働者 クライアント フランチャイズ加盟店 関連会社にも配布できます カスタマーは MDMや引き換えコードで ライセンスを配布できます

Apple Developer Enterprise Programに 慣れている人には カスタムAppは便利です １つのプログラムで App Store用と 内部配布用Appを管理できます アプリケーションに期限がないので 証明書の取り消しや 期限切れの心配がありません In-House配信は従業員限定ですが カスタムAppなら 関連会社まで 広いオーディエンスに届けられます サードパーティデベロッパにとっても 楽です ソースコードへのアクセスがなくても カスタマーがAppを配布でき バイナリの再署名とも無縁です App Storeの自動アップデートや キャッシュ生成 Appの最適化 TestFlightや App Store Connectなどの ツールも活用できます

カスタムAppの提出方法ですが― 最初に カスタムAppをサポートするよう アカウントを設定します ２つの契約に同意し 口座や税金の情報を提供してください セットアップが済んだら ユーザ登録とアクセス権設定を行います

デベロッパは デベロッパWebサイトに 新しいApp IDを作成し App Store Connectに アプリケーションのレコードを作成 カスタムAppを配信する時には 常に 新しいApp IDとレコードを 作成する必要があります App Storeで公開するAppと 非公開で配信するカスタムAppに 同じバンドルIDはつけられません この２つは別のアプリケーションなので バンドルIDも別です

次にビルドをアップロードすると App Store Connectで表示されます

ベータ版のテストはTestFlightで行い それが完了したら アプリケーションの全メタデータと 販売素材を確定し 追加します

そして“価格および配信状況”で カスタムAppとして配信準備をします Appがカスタムまたは公開として 審査に提出されたあとは オーディエンスの公開と非公開を 切り替えられません 組織内向けカスタムAppとして 配信するには カスタマーのDEPお客様IDと組織名を 入力する必要があります

DEPお客様IDとは 組織が Apple Business Managerに登録した際に 付与される固有IDです

最後にアプリケーションを 審査に提出します 承認され 配信可能になったら カスタマーはAppを購入できます

購入はApple Business Managerから 行います カスタマーは business.apple.comから入れば App StoreのApp カスタムApp ブックを一括購入できます そしてユーザに配布します アプリケーションの ライセンス管理もできます ただし 配信前に デベロッパが設定する必要があり カスタマーのDEPお客様IDと組織名が 必要です カスタムAppは 間もなく Apple School Managerでも使用可能に

これがApple Business Managerの 画面です カスタマーは 配信可能になったAppを カスタムAppの項で見られます

カスタマーとデベロッパそれぞれの プロセスを追いましょう カスタマーは 組織名とDEPお客様IDを デベロッパに提供 デベロッパは App Store Connectの “価格および配信状況”で設定を実施 事業向けカスタムAppとして アプリケーションを非公開にし DEPお客様IDと組織名を指定します アプリケーションが承認されたら― カスタマーはApple Business Managerで ライセンスを購入

カスタムAppを提出できなかったり 割り当てられたアプリケーションが カスタマーに見えなかったりすることも その場合 以下を確認します デベロッパ側は ２つの同意事項と 口座情報がクリアされているか 確認してください カスタマーにAppが見えない場合 Apple Business Managerの “組織の設定”の“登録情報”で カスタムAppを有効に Apple Business Managerで Appが見えるようになるまで 数分かかる場合もあります App Store Connectヘルプの情報も ご参照ください

最後に カスタムAppの留意点です カスタマーはApple Business Managerの アカウントが必要です アプリケーションは 配信される国を サポートしているべきです デフォルトでは アプリケーションは 全テリトリに配信可能で 通常は変更しないでください 引き換えコードで配布するつもりなら コードは非公開にして 特定のユーザだけに渡るよう ご注意ください

新しいカスタムAppは審査が必要です Reviewチームが全機能に アクセスできるようにしてください Appが審査に提出されたあとは 公開設定を切り替えられません

カスタムAppの話は以上です ここまで４つの配信方法を 紹介してきました 自分のアプリケーションの 配信方法を決めるには オーディエンスが 公開か非公開かを考えることです Ad Hocなら テスト用に 限られた人に非公開で配信でき App Storeなら一般に公開できます In-HouseとカスタムAppは 非公開での配信です

配信の筋書きをおさらいします

アプリケーションは公開用ですか？ 一般に公開するアプリケーションなら App Storeへ

知的財産を企業に渡したくない？ その場合 カスタムAppを完成させて カスタマーに提供します 一般向けのアプリケーションを 他企業のために作る場合は その企業にバイナリを渡せば 彼らが自社アカウントからアップします

カスタマーが MDMを持っていなかったら カスタムAppを作り 配信時に MDMソリューションを案内しましょう

コンサルタントとして企業にAppを作り 支払いを受けるなら？ App StoreとカスタムAppで― サードパーティデベロッパとして アプリケーションを配信できます Apple Business Managerを 使えないカスタマーなら？ カスタマーが欲しがっているAppが 従業員向けなら In-House配信を活用できます

アプリケーションが従業員向けなら？ 非公開なら カスタムAppと In-Houseで配信できます

自組織内に アプリケーションを配布したいなら？

カスタムAppとIn-House どちらの配信方法も使えます セッションの締めくくりに 私の同僚の言葉を “アプリケーションは大砲に似ている” “発射前に方向を定めた方がいい” 賢明にアプリケーションを拡張し 成功を収めてほしく思います ユーザとカスタマーが誰かを慎重に考え 適切なバージョン管理を行い デベロッパ用プログラムの ガイドラインを理解してください 事前に仕組みを理解すれば 適切な配信方法を選べて 難なくユーザに展開できます

関連情報は セッション304のWebページへ ラボにもお越しください セッション303も参考になると思います

それでは楽しいWWDCを (拍手喝采)