ただやっぱりこの先は分からないということで、予め備えておきたいと考える企業様に、InHouseからカスタムAppへの移行について質問を頂くことが増えてきました。

(InHouseからカスタムAppへの移行とはつまりADEPからADPへの移行を意味する)

開発会社視点で真っ先に気になるのはADEPに代わって使うことになるADPです。そこで本稿では、ADEPの理解がある方々向けにADPの豆知識を幾つかご紹介します。以下一覧です。

1. App Store には公開領域と非公開領域がある
2. ADEP契約済み企業でもADPは新規契約が必要
3. ADEPとADPは排他的ではなく法人として両契約可能
4. 作成できる配布用証明書の数がADEPより1つ多い
5. 配布用証明書の有効期間は3年間で一緒
6. 証明書の期限が切れたりrevokeしてもアプリは起動し続ける
7. ADPの契約が切れるとAppStoreからアプリが消える
8. ADPの更新には審査がない
9. カスタムAppの審査はそれほど難しくない
10. 無審査でのアプリ配布が全くできなくなるわけではない

1つ1つはちょっとしたことですが、あらかじめ知っておくと知識ゼロで始めるよりずっと良いカスタムApp移行を行うことができます。

1. App Store には公開領域と非公開領域がある

カスタムAppとは実はAppStoreアプリです。「え？AppStoreって公開されるのでは？」と思った方はこれを機会に是非、認識を改めて下さい。

AppStoreには企業内用途の非公開アプリのために非公開領域が存在する

のです。実は2010年頃からそうです。最近になって整備されたのではなく、昔からあったのです。ただADEPが便利すぎて単に使われていなかっただけに過ぎません。昔はCustomB2Bと呼ばれていました。

(2014年頃。iTunes Connect (現在の App Store Connect)にCustomB2Bで非公開アプリ申請しようとする様子)

InHouseアプリからカスタムApp化するとは、つまりAppStoreアプリにするということであり、ゆえにADPの契約が必要になるとうわけです。

2. ADEP契約済み企業でもADPは新規契約が必要

ADPは新たに契約する必要があります。

ADEPの契約がADPの契約に切り替わるわけではない点に注意して下さい。また、いわゆるSaaSサービスの契約プランではないため、ADEPからADPにプランを落とすといった関係性のものでもありません。

(あるMDMのプラン表。ADPとADEPはこのようなプラン的な考え方とは全く異なる)

ADEPとADPは名前は似てますが全く別物の扱いですので、たとえADEP契約済みであってもADPは新規に契約することになります。

Appleが気を利かせてADP契約も手配してくれるとか、Appleの認定リセラー企業が契約代行してくれるといった事もありません。自社が主体となって新たに契約手続きを行います。

3. ADEPとADPは排他的ではなく法人として両契約可能

ADEPとADPはそれぞれ全く別の契約で、かつ独立しています。

従って、ADEP契約期間中でもADP契約が可能です。また、ADPを契約するとADEP契約が解除されてしまうといったこともありません。

(Apple Developer 画面でのアカウント切り替えの様子。ADEPには頭にEnterpriseの表記がある。併存可能なことが分かる)

4. 作成できる配布用証明書の数がADEPより1つ多い

ADEPでの配布用証明書(InHouseアプリの署名に必要な証明書)は、最大2つでした。2つ作成済みの状態で新規作成しようとすると以下のように選択できません。

一方、ADPでは配布用証明書(AppStore申請用アプリの署名に必要な証明書)は、最大3つまで作成することができます。Appleの公式ドキュメントにも記載がありますので確認してみて下さい。

複数の秘密鍵や証明書に分けて管理してきた企業の場合、ADPでは運用の柔軟性が向上するでしょう。

5. 配布用証明書の有効期間は3年間で一緒

配布用証明書の有効期間は3年間で、ADEPでもADPでも一緒です。

Provisioning Profile の1年更新とセットにして毎年証明書も更新している企業をたまに見聞きしますが、ADPへの移行を機に更新手順を見直しましょう。配布用証明書の有効期間はADEPもADPも3年です。

6. 証明書の期限が切れたりrevokeしてもアプリは起動し続ける

InHouseアプリでは、証明書期限が切れたり証明書をrevokeするとアプリが起動しなくなりますが、ADPによるAppStoreアプリでは、証明書期限が切れてもrevokeされても起動し続けます。

AppStore申請用の証明書で署名し申請通過したアプリは、一度端末にインストールされたなら証明書の期限や有効性に関係なく起動し続けることができるのです。

審査通過後に証明書のことを気にしなくてよくなるのは、ADEPからADPに移行するメリットです。オペレーションミスでアプリが起動しなくなるといった惨劇も避けられます。(証明書の状態に関係なく起動可能な理由は解説すると長くなるので省略します)

7. ADPの契約が切れるとAppStoreからアプリが消える

ADPの契約更新を忘れると、ADP契約期間終了日以降、ユーザはアプリをダウンロードすることができなくなります。(起動できなくなるのではない)

(ADPの契約終了日からカスタムAppを端末にインストールできなくなる)

ABM で一括購入してMDM経由で配信される監理対象ライセンスでも、ABMから取得する引き換えコードでも同じです。アプリの存在がないものとみなされると考えて下さい。

しかし、ADP契約を更新すると再びダウンロードできる状態に戻すことができます(ただし1年以内)。カスタムAppに移行したらADP契約更新に細心の注意をはらいましょう。

端末にインストール済みのアプリは、たとえADP契約が期間終了しても起動し続けることが可能です。詳しくは公式情報を確認して下さい。

8. ADPの更新には審査がない

別の投稿で紹介した通り、2022年春以降、大半の企業ではADEP更新にAppleの審査が必要となりました。一方、ADPの更新に審査は不要です。これは昔も今も変わりません。

9. カスタムAppの審査はそれほど難しくない

iOSアプリ黎明期、AppStore審査は厳しく理不尽なことがままありました。審査拒否された理由を共有する投稿サイトまであったぐらいです。(参考。約14年前の紹介記事)

その頃の「審査は厳しい」という噂情報のまま、今でもAppStoreの審査はとても難しいと誤解している方が多くおられます。未体験であれば仕方がないことです。分からないことは、普通怖いものですから。

ただ知れば怖くなくなります。審査基準を知るために App Store Review ガイドラインを関係者全員で事前に一読しておくと良いでしょう。可能なら英語で読むことが推奨されます。

(ガイドラインは度々更新されるが、日本語版への反映は遅れることが多い)

審査基準はアプリ黎明期に比べるとかなり明瞭で、従っていさえすれば、理不尽なreject(審査で落ちること)を食らうことは余りありません。また、TestFlight の外部テストを使えば、事前に審査の感触を掴むことも可能です。

10. 無審査でのアプリ配布が全くできなくなるわけではない

無審査配布の一形態であるAdHocをADPでも使うことができます。ADEPでのAdHocと条件は同じで、

• 事前登録済みUDIDの端末のみで起動可能
• 登録可能なUDIDの数はiPhone/iPad/AppleTV/AppleWatchで各100台

となります。

これまで ADEPの InHouse アプリだけを使ってきたという場合、AdHocという配布手段を知らない方もおられるでしょう。実は、無審査配布には InHouse と AdHoc の2種類があります。前者はADEPでしか使えませんが、後者はADEP/ADPの両方で使えます。

(ADEP公式ページでも AdHoc が非公開配布の選択肢であると述べている)

上記の条件が許容できるのなら、AdHoc配布も検討する価値があります。また、ADEPのInHouseアプリを社内テスト用の配布にしか使っていないのなら、TestFlightの内部テストに移行できます。ADPに移行したからといって、全てのアプリで常にAppleの審査が必要になるというわけではないのです。

以上、ADEPからADPに移行する方に向けてADPの豆知識を紹介してみました。ADPへの移行の際に参考にして下さい。

そろそろADEP契約更新ができなくなるかも知れない

投稿以後、ADEP契約更新が例年のように進められないという声が幾つも届いています。数ヶ月が経過してみて、契約更新可否について興味深い傾向が見えてきたほか、拒否された後のInHouseアプリの振る舞いについて新たな情報を得ましたので、2回に分けてシェアしたいと思います。

ADEPの契約は意外に更新できている

2022年4月の時点で、一律全ADEP契約が拒否されているのではないうえに基準が不明瞭…というなんとも気持ち悪い状況でした。

しかしAppleの InHouse アプリに対する態度硬化が加速してる流れから、拒否が基本で、更新可能なのは例外的ケースだろうと見ていました。それで以前の投稿では、90日前のメールをトリガに動き出したほうが良いかも知れないと見解を記していた次第です。

(90日前から動き出せば対応期間を長く確保できる)

それから数ヶ月。

実際に見えてきたのは、ADEPは意外に更新できているという状況です。ADEPの公式ページに記載されている条件を満たしていれば、おおよそADEPの更新に成功しているように見えます。

(従業員が100人に満たない要件未達な組織や、従業員以外が使うアプリに使っている不正利用はやはり拒否される)

ただ、条件さえ満たせばすんなり更新できるかというとそうでもなく、以下のようなステップを踏むことが多いようです。

1. ADEP契約終了90日前に更新とカスタムApp移行の案内メールが届く
2. 更新申請に際し数十項目のフォーム入力を求められる (何に使っているか等)
3. 審査にかけられ暫く放置される
4. ADEP契約終了日直前になってもAppleから連絡が来ない
5. 突然ADEP契約終了日が延期されて審査中状態が続く
6. 審査を通過しクレジットカード決済を経て更新完了する

このようにADEP更新には心穏やかでない状態が待ち受けてます。しかもやっかいなのは、全ての企業がこの通りに進むわけではなく、企業によって若干異なっていること。

3,4 がなく審査を通過して6に行くパターンもあれば、3(審査待ち)に2週間や1ヶ月の期間を要したりと所要期間はバラバラ。一方拒否される場合は余り待つことがなく1週間程度で返ってくる傾向にあるようです。また、更新成功の変則的ケースとして 4→5→4→5 と回答待ち＆強制延期が2周するパターンも見受けられました。

要するにやってみないと分からないということですね。困ったものです。

これからどうすべきか

上記状況をふまえた弊社見解は、

• 明らかなADEP契約違反や条件未達でなければ過度に神経質になる必要はないかも
• が、いずれ拒否されることを見据えてアプリの今後を考えておいたほうが安心かも

です。

やはり InHouse アプリからの脱却は推奨と考えます。Appleが毎年少しずつ更新条件を厳しくしていくかも知れませんし、「1年の猶予は与えたよね？なぜ何もしなかったの？」と2023年に更新拒絶を強行する可能性もゼロではないでしょう。無論、今まで通り毎年更新し続けられる可能性も全否定はできません。

よくよく考えておきたいのは、Appleの気持ち次第というモヤモヤした状況を続けるのは、業務用ソフトウェアのあるべき姿なのかということです。毎年毎年ドキドキするぐらいであれば、早めに手を打つほうが健全でしょう。

(ADEPの公式ページの選択範囲の文言に注意。十分に対応できるという判断はApple次第)

エンドユーザ企業においては、社内に開発部隊がいて内製しているなら、カスタムAppに移行しましょう。端末台数が少ないならAdHocです。もしWebアプリにガワをかぶせたに過ぎないならこの際アプリをやめ、WebClipのMDM配信に切り替える事も視野に入れましょう。以下を参考にして下さい。

• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (前編)
• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (後編)

テスト用途で配布が便利だからという理由だけでInHouseを使っているなら、面倒臭がらずにTestFlightを学習して移行しましょう。TestFlightに慣れると、InHouseビルドをテスト用配布することが逆に面倒になるぐらい便利です。

(TestFlightはもう10年の歴史がある洗練されたテストツール。使わない手はない)

また、受託開発会社においては、いつまでもカスタムAppの経験がない状態が続けば、いずれ業務用iOSアプリの受託が厳しくなる未来を迎えることになる可能性も考慮に入れて下さい。

新規はもちろん、ADEPからの移行組エンドユーザ企業の多くが目にすることになるABMユーザガイドには、カスタムAppなるものの手はずをデベロッパーがしてくれると明記されています。

エンドユーザ企業にして見れば、Appleが「デベロッパがやります」と書いているカスタムAppについて全く何も知らない開発会社に発注したいと思うでしょうか。業務用iOSアプリの受託開発事業を行う企業は、ADP/ABM/MDMを自社で一通り揃え、カスタムAppについて学習しておくことが推奨されます。本サイトのカスタムAppに関する全投稿を参考にして下さい。

本稿ではADEPの更新可否が今どうなっているかについて書きました。次回投稿では、実際にADEPの契約を拒否されたケースで見られた興味深い現象について記そうと思います。

(あるアプリの例。AppStoreへのアプリ申請では最初にBudnelIDを指定することになる)

業務用iOS関連の作業では、ときおりiOS端末にインストールされているアプリの BundleId を知りたくなることがあります。構成プロファイルを作成したり、MDMでアプリケーション関連の操作をしたり、Apple Configurator2 を触っているような時です。

自分が開発を担当しているアプリならそのBundleIDを記憶しているでしょうが、そうでない場合はどうやってBundleIDを調べるのでしょうか。本稿ではその方法を幾つか紹介します。

Xcode (development, InHouse, AdHoc)

手元にMacがあり開発環境のXcodeがインストールされているなら、iOS端末をMacにUSB接続した上で Xcode の Devices and Simulators の画面を見るとすぐに分かります。

(Xcode を起動した状態で、command + shift + 2 のショートカットが便利)

サイドバーで見たいiOS端末を選択すると、INSATLLED APPS の蘭にインストールされているアプリの一覧が表示されます。Identifier の列がアプリの BundleID です。

AppStoreからインストールされたアプリ(公開App/カスタムApp/非表示App/TestFlight)は基本的に表示されません。

MDM (InHouse, AppStore)

対象となるiOS端末がMDMの管理下にあるならMDMの管理画面を見るのが一番手っ取り早いでしょう。

どんなMDMにも端末の詳細情報画面があり、その中でインストールされているアプリの一覧が表示されている筈です。

(MDMは管理化の端末にインストールされているアプリ一覧を把握している)

アプリの種類によらず全て確認できます。MDMによっては、MDMで配信したアプリのみを表示する設定ができる場合もあります。(BYOD端末の場合、個人がその端末で使用するアプリを見ることは適当でないため)

cfgutil (development, InHouse, AdHoc, AppStore)

Apple Configuratoe2 に付属している cfgutil を使って確認することもできます。cfgutil の詳細はApple Configurator2 付属のコマンドラインツール cfgutil の使い方の投稿をご覧下さい。

iOS端末をmacにUSB接続し、ターミナルを起動して、cfgutilの list コマンドで端末のECIDを特定します。

$ cfgutil list

(cfgutilの大半のコマンドで ECID は必須となる)

次にECIDを引数に指定して以下のように get installedApps コマンドを実行すると、インストールされたアプリの一覧が出力されます。数秒程度待った後に、ECIDで指定された端末にインストールされているアプリ一覧が表示されます。

$ cfgutil -e [ECID] get installedApps

(出力テキストのアプリ名がエスケープされないため、加工しやすいテキストとは言えない)

cfgutil コマンドでは、development, InHouse, AdHoc だけでなく、AppStore からインストールしたアプリも表示されます。

iTunes Search API (AppStore)

AppStoreに公開されているアプリに限りますが、iTunes Search API を使ってアプリidから BundleID を調べることもできます。

まずアプリidを調べる必要がありますが、アプリのURLが分かるならそのURL末尾の数字がアプリidです。

アプリのURLを探すには、アプリ名とiOSでググると良いでしょう。あるいは、マーケティング担当者向けに用意されている App Store Marketing Tools を使うこともできます。

検索ボックスにアプリ名を入れると、アプリのURLやアイコン画像等の情報を確認することができます。

(アプリアイコンの高解像度画像ファイルをダウンロードすることもできる)

アプリidを特定したら、ターミナルから以下のように入力すると BundleID を特定できます。(iTunes Search API は JSON を返すため、jqコマンドで必要な箇所のみに絞り込んでいます)

% curl -s 'https://itunes.apple.com/lookup?id=[アプリid]' | jq -r '.results[0].bundleId'

(jqコマンドについては公式ページを参照のこと)

なお iTunes Search API を使う方法は InHouse アプリでは使えません。AppStoreに登録されないアプリだからです。またカスタムAppでは、アプリidは付与されるものの使えませんのでご注意下さい。

以上、アプリのBundleIDを調べる方法を紹介しました。BundleID(バンドルID)を調べる必要がある時に、試してみて下さい。

その時が迫っているのかも知れません。

上図はあるADEP契約企業の ADEPの契約更新が拒否され期限切を迎えてしまった様子です。あるInHouseアプリを業務で常用している企業で、突然ADEP更新を拒否されこの状況になってしまいました。

Software associated with this membership will continue to run for the next XX days.

とあり、あとXX日で InHouse アプリが起動できなくなると警告されています。(XXには具体的な数字が入り毎日1ずつ減っていく)

以前の投稿でも紹介した通り、ADEP契約が切れると期限日から91日目以降はInHouseアプリが動かなくなります。企業によっては最悪の場合、業務が停止しかねない事態ですね。これを避けるには期限日から90日以内に原則カスタムAppに移行しなければなりません。

意図してADEP契約更新を止めて期限日を迎えているのなら良いのですが、例年通り更新しようと思って拒否されてしまった場合は困った事態になります。

そこで本稿では、そうした状況に備えられるようにするため、実際にADEPを拒否された事例とそうでない事例を紹介するとともにADEP更新契約の2022年における実態とその対策について解説します。

全ADEP契約企業が置かれている状況のおさらい

審査もなく、配布端末数の制限もない。ADEPによるInHouseアプリは、業務用アプリとしてこれ以上ないほど使い勝手がよく都合の良い配布形式でした。

ただ、ADEPはもう取得することができないと諦めたほうが良い理由の投稿で解説した通り、2020年頃から新規のADEP契約締結は事実上不可能となっていました。加えて、既存の契約済み企業もいつ契約更新不可となるか分からないという状況にあったのです。

(ADEPでのBundleID詳細画面では、InHouseを使う理由を明記する必要があった)

新規契約は実質不可になっても、ADEP契約済み企業は更新はできていたわけです。まだまだ InHouse アプリは使い続けられる。そう思って多くの企業が更新し続けてきたのが2020年、2021年でした。

が、2022年1月末にAppleが動きます。非表示App(Unlisted App) という新しい仕組みを発表したのです。詳細は非表示App(Unlisted App)とは何かの投稿で紹介した通りですが、この非表示App(Unlisted App)はある意味、Appleが自らADEPにとどめを刺す最後の一手でした。

詳細は別の投稿に譲りますが、非表示App(Unlisted App)の登場によって「ABMとMDMの契約は現実的ではない、だからADEPが必要なんだ」という、ADEPとInHouseを正当化する唯一の理屈が封じられたのです。Apple は「それならADPで非表示App(Unlisted App)にしなさい。ADEPはいらないよね」と言えるようになりました。

• 原則、業務アプリもADPでAppStoreに申請
• 非公開にしたいならカスタムApp
• MDMやABMの都合でカスタムAppが無理なら非表示App
• テスト用ならAdHocかTestFligth

これがAppleの結論です。非表示App の仕組みが発表された直後に、冒頭で紹介したようなADEP更新を拒否される事例が出てきたのは偶然ではないでしょう。

もう、Apple にADEPが必要だと言えなくなりました。2010年からエンタープライズiOSの世界にいる筆者も、ADEPを正当化する理屈を組み立てるのは完全に不可能であると断言できます。Apple は本気でADEPを潰そうとしていると感じます。(自分で作ったのに！)

ADEP契約更新が拒否される条件

冒頭で紹介した例のように更新拒否される条件は不明です。Appleから公式な発表はありません。ただ、弊社が得ている事例情報では

• Appleに審査されると不都合な実装をしているアプリだが毎日業務で使っている
• ADEPの契約から5年以上経過しており例年何の問題もなく更新してきた

というInHouse利用常態化＆ミッションクリティカルなケースでさえ、明確な理由の提示なく契約拒否されてしまっています。ADEP公式ページの対象条件を満たした企業であってもです。

(更新を拒絶された直後。期限までは操作が可能だがADPに移行するよう促される)

ただ全てのADEP契約の更新が2022年から不可になったというわけではなく、

• iDEP(ADEPの前身)の契約条件が緩和された時期に契約できていたアプリ開発会社
• 業務用アプリというよりも単に社内のテスト用ビルドの配布手段として便利だから使用中

といった緩い利用状況の企業が更新できたという例も情報として届いています。中にはADEP公式ページの対象条件を満たしていない企業の例すらあります。

本来なら、前者が更新できて後者が不可であるべきでしょう。なぜそうなっていないのか理由は分かりません。ただハッキリしているのは、InHouseアプリが使えなくなれば業務停止しかねない企業であっても、問答無用にADEP更新を拒否される事例が現れてきているということです。

ADEP契約更新はどのように拒否されるのか

通常、ADEPの契約期日の30日前には以下のようなメールが届きます。

そして developer.apple.com にADEPアカウントでサインインすると以下のように表示されます。

ここで Renew Membership ボタンをクリックするとクレジットカードによる決済に案内され、支払いができれば更新完了、例年ならただそれだけのことです。ADP(Apple Developer Program)を契約している方には、金額は違えど馴染みのあるフローでしょう。

(ADEPの更新もただただ支払いをするだけだった)

しかし、ADEP契約更新時に以下のようなフォームが現れる場合が出始めました。

なぜ InHouse が必要なのか、誰が管理してるのか、どのように配布しているのか、等々ですね。ADEPはもう取得することができないと諦めたほうが良い理由の投稿でも紹介した、BundleID内の自己申告項目にも似ています。

必要事項を入力して submit した後、Apple からADEP更新審査の回答が来ます。拒否されれば、前述の通り以下のような画面となりADEP更新の道が完全に閉ざされます。

警告文の末尾には、

Learn how to transition to the Apple Developer Program

というリンクが貼られていて、以下のページに誘導されます。

InHouseいらないよね？カスタムAppに移りましょう…と、取りうる手段や必要なものを解説してくれます。

ADEP契約更新が拒否される兆候？

ADEPの契約更新が認められる場合と拒否される場合とで、明らかな相違点があります。それはAppleからADEP更新に関して届くメール。

以下は、拒否された企業に宛てられた、契約期日の90日前のメールです。内容は先に紹介したApple Developer Programへの切り替えの内容とほぼ同じです。

一方、更新が認められた企業には、例年通り契約期日の30日前に以下のようなメールが届いています。

Renew Now と更新を促すリンク付き。例年はこの形式なのです。90日も前にメールが届くことはまず無かったことです。

このように例年とは違う内容で、且つ、かなり早いタイミング(90日前)でADEPの更新に関するメールがAppleから届いた場合、ADEPの更新可否がひょっとしたらひょっとするかも？と警戒しても良いかも知れません。

全ADEP契約企業にお勧めしたいこと

ADEP契約更新は、余程の理由がない限りいずれ拒否される時がくると考えましょう。Appleのここ2,3年の動きを総括すると、ADEPをもはや過去のものにしようとしている、以外の結論は導けないからです。

全てのADEP契約企業におかれては、InHouse アプリが使えなくなる前提で開発体制や配布・運用体制を見直すことをお勧めします。もし諸事情ですぐに動けないのなら、最低でもADEPの契約期日を確認し、その90日前に上記で紹介したメールが Account Holder 宛に届いていないか確認するぐらいはしても良いでしょう。

もしメールが届けば、カスタムApp化に動く時かも知れません。メール受信からADEP期限到来までは90日。そして、更新拒否されればADEP期限切れ後から90日間のみInHouseアプリを起動可能です。

つまり、上記で紹介したメールが届いた直後にすぐ動けば、最大で180日間の準備期間を持てるということです。

早いにこしたことはありません。

期限日直前にいざ申請してみたら拒否された…なんて展開を想像してみて下さい。90日強でカスタムApp化と配信とテスト、運用切替まで滞りなく進めるのは難しいでしょう。InHouseで業務アプリを開発・運用してきた多くの方にとって、ADPでアプリをAppStore申請することすら初めてだったりすることも多いからです。

(App Store Connect で申請する様子。InHouseアプリ運用とは勝手がかなり違う。経験がなければ戸惑うこと必至)

前述した通り更新が可能な時もありますが、その場合は先手を打てて良かったと解釈しましょう。いずれカスタムApp化はやらなくてはならないのですから。ADEPが廃止され InHouse アプリを使えなくなるのは時間の問題です。

以上、ADEPの契約更新拒否について解説しました。個人的にはInHouseな業務アプリがあるなら、今すぐカスタムApp化することを強くお勧めします。

(追記) その後、半年経過したADEP契約更新状況について以下にまとめました。

• そろそろADEP契約更新ができなくなるかも知れない…その後(1)
• そろそろADEP契約更新ができなくなるかも知れない…その後(2)

併せてご覧下さい。

業務用アプリを配布する方法は、全て列挙すると実に7種類もあります。どの配布方法を選ぶべきかはアプリの特性や各社の状況によりますので、一通り配布方法を知っておくのは良いことです。

(用途やアプリに応じて様々な配布方法がある)

そこで本稿では全ての配布方法の概要を網羅的に紹介します。また、各方式について詳細を記している本サイトの別投稿へのリンクも紹介しますので、詳しく知りたい場合は各リンク先を参照して下さい。

本稿は、アプリの配布方法に迷った時の道標として使えるページです。是非、本稿をブックマークして頂き、アプリ配布方法に迷ったら参照するようにして下さい。

配布方法全7種

以下に一覧を列挙します。

AppStore公開アプリ

AppStore上に公開されている既存アプリは全てABM+MDM経由で配信することができます。例えば Box や DocuSign など既存アプリを業務でそのまま使う場合が該当します。

(業務用バージョンを別アプリとしてAppStore公開しているものもある。上手はBoxの例)

ABMやMDMという言葉が初見という方は以下を参考にして下さい。

• MDMとは何か 〜今さら聞けないMDMの基礎〜
• ABM(Apple Business Manager)とは何か
• iOSDC 2020 Day1 でエンタープライズiOSについて講演しました（YouTubeで収録動画が公開されました）

ABMでAppStoreのアプリを一括購入(VPPということもある)してMDMに同期して、MDMから配布します。

(ABMでAppStoreにあるGMailアプリを一括ライセンス購入する様子)

多くのMDMで、アップデート時の振る舞いをアプリごとに制御できます。

(アプリ毎に自動更新するかどうかを決めることができる。上手はBizMobile Go!)

自動で更新させることもできれば、明示的な更新を強いることもできます。通常は自動更新としておくのが良いでしょう。

カスタムApp

現時点(2022年3月)で、特定企業用の非公開アプリを無制限に配信できる唯一の方法です。

AppStoreのインフラをそのまま使いますので、ADP(Apple Developer Program)の契約が必要で、アプリ毎にAppleの審査が必要です。

(AppStoreに申請する際に、実は「非公開」を選択できる)

審査が通ればそれで完了…ではありません。ABMから当該カスタムAppを一括購入し、MDM経由か引き換えコードを使った配布をする必要があります。カスタムAppについては以下に記事をまとめていますので御覧下さい。

• カスタムAppのカテゴリ全記事 (全記事11件の一覧)

非表示App

2022年に新たに登場した配布形式です。

AppStore公開アプリではあるものの、AppStoreアプリでの検索に出てこなくなり、当該アプリのURLを知っている人だけがインストールできるという配布形式です。

例えば「特定組織内で限定的に使うわけではないが第三者に見せる必要のないアプリ」で利用できます。

AppStoreへの通常のアプリ審査の他、非表示化を申請して受理される必要があります。申請時に合理的な理由(なぜカスタムAppではないのか)を説明することが求められます。詳しくは以下をご覧下さい。

• 非表示App(Unlisted App)とは何か

InHouseアプリ

ADEP(Apple Developer Enterprise Program)の契約を締結できている組織だけが利用できます。現在その契約を持っていない組織ではこの配布方法は事実上採用不可です。

AppStoreインフラを使いませんので審査は不要です。配布台数制限もなく、MDMとABMの連携も不要で、最もシンプルで理解しやすい配布方法です。詳しくは以下の投稿をご覧下さい。

• ADEPとは
• ADEPはもう取得することができないと諦めたほうが良い理由

なお、ADEPを契約済である企業であっても、ADEP契約が更新できなくなってきている点は注意して下さい。2022年に入ってから ADEP の更新を Apple に拒絶されたとの報告が幾例かあります。更新を拒否された場合、急いでカスタムAppを使った配布体制に切り替える必要があります。以下を御覧ください。

• ADEP契約を更新せず放置するとInHouseアプリはどうなるのか
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜

ADEPを継続できている企業は、規約違反で契約取り消しとならないよう注意しましょう。以下で規約違反になるパターンをおさえておくことをお勧めします。

• ADEPの契約ができないパターン集

Webクリップ

WebサイトやWebシステムをアプリのように配布する形式です。MDMを使ってWebのショートカットを配布するようなイメージです。

(アプリのように見えるが実はWebサイトのショートカットという例)

ハードウェアの機能を使わない、オンライン前提にできる、通知はメールやチャットで十分、といった条件を満たせる環境なら、わざわざネイティブアプリを開発しなくても擬似的にアプリ配布が可能です。

面倒なAppleへのアプリ申請やABMの操作等が不要になります。MDMさえ用意できればアプリ配布ができますので、ネイティブアプリ開発に課題がある場合、積極的に活用を検討すべき配布方法です。アプリ開発の知見が余りないWebシステム会社にとっては、アプリ開発提案の「亜種」として採用できる可能性があります。詳細は以下にまとめていますのでご覧下さい。

• Webクリップのカテゴリ全記事 (全7記事)

TestFlight

アプリの申請前や、申請後の本配信前に、関係者限定のテスト用途で使用する配布方法です。

前述したAppStore公開アプリやカスタムAppを使って業務用アプリを配布する場合に、アプリの初回配布前のフェーズや、アプリのアップデート版の本配信前テストに使用します。

ADPの Apple Developer サイトでテストしたいバージョンを指定し、テスターをグループ単位や個人単位で紐付けます。

(これまでInHouseでの配布経験しかない企業は TestFlight をよく理解することが求められる)

テスターは情シス担当者、社内評価担当者等が対象となります。テスターのiOS端末には TestFlight なるApple公式専用アプリを予めインストールしておく必要があります。

TestFlightアプリでインストールされたテスト用アプリには、有効期限が90日、旧バージョンにいつでも戻せる、などの特徴があります。なお、TsetFligth は原則、本番運用アプリで使ってはいけません。

AdHocアプリ

上限100台という台数制限があるものの、審査不要のアプリ配信が可能な方法です。動作対象端末のUDID(端末識別子)をあらかじめ収集しておく必要があって運用は少々面倒です。

UDIDを紐付けたAdHoc用の Provisioning Profile を使ってアプリを署名して生成した .ipa ファイルは、UDIDが一致する端末でのみインストール・起動できるようになるという仕組みです。

(UDIDを登録した権限ファイルを生成する様子。生成したファイルをビルド時にアプリに紐付ける)

インストールには有線・無線の両方が使えます。それぞれ以下を参照して下さい。(前者のタイトルはInHouseアプリだが、AdHocアプリでも使用できる)

• Apple Configurator2 で InHouse アプリをインストール・アンインストールする方法と「信頼」について
• OTA(Over The Air)とは何か

また、AdHocアプリの用途や配布先制限については以下を参照して下さい。

• AdHoc配布はテスト用途以外に使用できるのか
• AdHocアプリを社外ユーザに配布できるのか

以上、業務用アプリの配布方法7種を解説しました。詳細についてはそれぞれ対応する投稿がありますので併せてご覧下さい。

結論を先に書くと、アプリ配信の選択肢が1つ増えました。今後アプリの配信方法は以下の4つから選ぶことになります。

今回追加された非表示App(D)は、公開App(A)と非公開App((B)または(C))を足して2で割った、かゆいところに手が届く特別な配信方式です。ただ開発者が自由に設定できるものではなくAppleの審査があります。また、非公開にしたい企業向けアプリは(B)(C)のいずれか、という点は従来と何ら変わりません。

以下、詳しく見ていきましょう。

非表示Appの概要

早速公開されたAppleの日本語ドキュメントによると

以下のような記述があります。

開発中のAppが一般配信に適していない場合は、App Storeで非表示Appとしてリリースし、ダイレクトリンク経由に限定して、ユーザーに見つけてもらうことができます。非表示Appは、App Storeのカテゴリ、おすすめ、ランキング、検索結果、その他のリストのいずれにも表示されません。

非表示アプリは、AppStore上に公開されるが、URL直リンク以外ではそのアプリにたどり着けないようにしたものです。URLを知っている人だけがインストールできる状態になりますが、URLを知ってさえいれば誰でもインストールできるという点が注意事項です。

YouTubeで動画を公開するときの限定公開と同じです。検索結果や関連動画には現れませんがURLを知っている人だけが見れる動画。そのアプリ版です。非表示Appは、限定公開Appと言い換えても良いのかも知れません。

一部の業務用アプリやイベント参加者向けに提供するアプリ等で活用できるでしょう。

非表示Appにするには、特別に用意されたフォームから申請が必要になります。β版やテスト用途では使えません。既に公開されているAppStore上のアプリや、通常のAppStore公開アプリとして審査提出前状態のアプリのみが対象です。

では今後、業務用アプリは非表示Appで良い？

いいえ。

非表示Appは非公開App ではないことに注意して下さい。AppStoreで公開されるアプリにたどり着く方法を直リンクに限るだけの話です。直リンクURLが広く知られたら、AppStoreで公開するのとさほど変わらない状態になります。

Appleは公式ドキュメントで

Unlisted Appは、リンクを持っているユーザーなら誰でも利用できます。そのため、不正使用を防止するための仕組みをAppに実装することを検討してください。

と注意を促しています。そもそも存在を知られたく無いような非公開状態を期待するアプリは、やはり

• ADEPによるInHouseアプリ
• カスタムApp

のいずれかを選択することになります。前者のInHouseアプリの手段が使える企業は限られていますので、非公開状態を望む場合は、ほぼすべての企業が後者カスタムApp配信をすることになります。非公開Appの配布方法は、従来と何ら変わらないわけです。

(非公開アプリであるカスタムAppとして申請しているアプリの例)

URL漏洩や不正利用に注意すれば、業務用アプリは非表示Appでも良い？

いいえ。

非公開App のカスタムAppは、MDMやABMの導入と運用が前提で、加えてVPPの理解も必要ですからかなり複雑になります。色々新しいことを調べるよりも、今までのよく知ったAppStore向け公開アプリの開発や申請フローで進めて、最後に非表示App申請するほうが楽そうだ…と思えなくもありません。

(iOSDC2021の講演資料より)

ですが、非表示Appは開発者の意思で自由に設定できるわけではないため、そう簡単ではなさそうです。Appleに申請し、非表示App化を認めて貰わなくてはなりません。その申請フォームに気になる項目があります。

Why do you prefer to distribute this app unlisted on the App Store instead of privately to specific organizations on Apple Business Manager or Apple School Manager?

「ABMを使わずに非表示Appにしたい理由はなんですか？」と説明を求められます。ABMをなぜ使わないのか。さすがに「面倒だから」とか「ABMはよく分からないから」と書いて申請しても認めて貰えないでしょう。

またフォームの末尾には「これらを理解しています」と自己宣言するチェックボックスがあり、幾つか並ぶ項目の1つにこんなものがあります。

• Because the app will be accessible by anyone with the link, unlisted distribution is not private. If you need private app distribution, consider offering a custom appon Apple Business Manager or Apple School Manager.

非公開アプリはカスタムAppとABMの利用を検討して下さいと明記されています。ここからも、ABMやカスタムAppやMDMの検討をすっ飛ばして「とりあえず非表示Appの申請をすりゃ良いや」とはならなさそうなことが分かりますね。

その他、非表示Appの申請フォームには結構な数の回答項目があります。全て素直に回答すると「いぁそれはABMとカスタムAppでやれるでしょ」と Apple がツッコミを入れやすいよう誘導しているかのような設問で、ADEPを取らせないようにするAppleの姿勢に似たものを感じます。

では、どんなときに非表示App申請が適切になるのでしょうか。

非表示Appの審査が適切なケース

既存の配布方法ではカバーできない用途です。つまり、

• AppStoreで広く公にする必要がないアプリで、
• ABM + カスタムApp での非公開Appが適切ではない or 難しいアプリ

になるでしょう。具体的には以下のようなアプリが該当します。

• イベントやカンファレンスの参加者専用アプリ
• 雇用関係にはないが一時的に組織外の人物に使わせる業務用アプリ
• あるメーカ製品を営業するための販売代理店使用を前提とするアプリ
• 海外を含む全グループ子会社に提供する従業員専用アプリ

いずれも、限定的なユーザに使わせたいアプリで、かつ、ABM + カスタムApp の配布可能範囲の制約が障壁になるケースです。

こうした例では従来、カスタムAppをインストールした端末を貸与する形をとったり、全関係企業でABMが必要になったり、カスタムAppを引き換えコード付きで入手して配布したりしていました。非表示Appは、これらの運用が複雑になるパターンを救済する仕組みと捉えるべきです。

ですので今後、業務用アプリを新たに開発する場合は、

• STEP1 : ABM + カスタムApp での非公開のApp開発・配布を検討する
• STEP2 : カスタムApp のライセンス的に現実的でないなら非表示Appを申請する

で進めるのが順当でしょう。以下のカスタムApp関連の投稿が参考になりますので併せてご覧下さい。

• カスタムAppとは何か(1) 〜非公開アプリをリリースする唯一の方法〜
• カスタムAppとは何か(8) 〜業務用アプリを配布しても良い範囲〜

以上、2022年1月に発表された非表示App(Unlisted App)について解説しました。

• ライセンス
• 引き換えコード

本稿では、後者の引き換えコードでカスタムAppを配布した場合の再インストールやアップデートについて解説します。(ライセンス配布の場合については前回の記事を参照して下さい)

引き換えコード配布はAppleIDに紐づく

カスタムAppを引き換えコードとして購入した場合、コードを従業員に配布し、各従業員は受け取ったコードを使ってインストールするのでした。下図中央の配布フローです。

(AppStoreアプリ内で引き換えコードを使ってインストールする)

この引き換えコードで配布した場合、 カスタムAppのアップデートや再インストールはどのように行うのでしょうか。

MDMを介したライセンス連携配布とは異なり、引き換えコード配布されたカスタムAppは必ず従業員のAppleIDに紐づくことになります。従って何か特別な運用になるというよりは、通常のAppStore公開アプリを従業員が勝手にインストールしている時と同じような運用になります。順にみていきましょう。

引き換えコード配布したカスタムAppのアップデート

通常のAppStore公開アプリと同じです。

従業員の端末側の設定でAppStoreアプリの自動アップデートがONになっていれば、カスタムAppも自動的にアップデートされます。一方、自動アップデートの設定がされていなければ、従業員が手動でアップデートするまで最新バージョンはインストールされません。

(OFFにしている従業員がいるかも知れないので、カスタムAppのアップデートの周知徹底が必要になる)

カスタムAppは、過去に紹介した通りAppStoreアプリの一種です。また引き換えコードのインストールではAppStoreアプリを使います。非公開アプリであるということ以外に、AppStore公開アプリと異なる点は全くないわけですね。

ですから、アップデートが配信されるかどうかは従業員側に委ねられ、管理部門は一切コントロールできません。カスタムAppを引き換えコード配布で運用する場合は、アプリ内部で「最新バージョンになっていなければアップデートを促す」といった仕組みが必要になるでしょう。

引き換えコード配布したカスタムAppの再インストール

削除してしまったアプリは通常AppStoreアプリから検索して再インストールします。が、カスタムAppはAppStoreアプリで検索しても検索結果には現れないのでした。ではどうやってカスタムAppを再インストールするのでしょう？

答えは、AppStoreアプリの購入済みアプリの一覧からとなります。配布済みの引き換えコードを再度使ってもらうのではないことに注意して下さい。引き換えコードは一度使うと再利用できないからです。

(引き換えコードは使い切り。再インストールに未使用コードを提供しても良いが運用が煩雑となり現実的ではない)

購入済みアプリの一覧を見るには、AppStoreアプリを起動して、画面右上のAppleIDアイコンをタップします。

(AppStoreアプリからアカウント画面を表示する。多くのユーザには余り馴染みのない画面)

次に、[購入済み]をタップすると、過去に入手したアプリの一覧が確認できます。

→
(カスタムAppとAppStore公開アプリとの区別は無い。上図では2つ目のアプリがカスタムApp)

一覧には引き換えコードでインストールしたカスタムAppも含まれていますので、アプリ右端のアイコンタップで再インストールできます。

分かってしまえば何のことはないのですが、事前に知らされていなければ誤ってカスタムAppを削除した従業員は混乱してしまうことでしょう。引き換えコードを使って運用する場合は、アプリの再インストール方法を一緒に案内しておくことをお勧めします。

以上、引き換えコードを使ってカスタムAppを配布した場合のアップデートと再インストールについて紹介しました。完全に従業員に委ねることになりますので、管理部門にとって不都合である場合がほとんどです。

従って、業務用アプリは原則的にライセンス連携でMDM経由の配布を行うべきです。MDM経由で配布できない事情がある特別な場合や、MDM経由の配布が不適切なアプリである場合でのみ、引き換えコードを使うのが良いでしょう。

• ライセンス
• 引き換えコード

本稿では前者のライセンス購入でカスタムAppを配布した場合の、アプリの再インストールやアップデートについて解説します。何度か掲載している下図の一番右端の配布フローとなります。

カスタムAppをライセンス購入した場合、アプリの個数情報がMDMに同期されます。MDM側では購入個数を超えない範囲で「どの端末にどのカスタムAppをインストールするか」を設定し、その設定に従ってアプリがインストールされるのでした。

では運用フェーズに入ってから、カスタムAppがアップデートされた時はどんな挙動になるのでしょうか？また、万が一ユーザが端末側でアプリを誤って削除してしまった場合、どうすれば再インストールできるのでしょうか？順にみてみましょう。

ライセンス購入配布したカスタムAppのアップデート

MDMの設定によりますが、

• 自動でアップデートされる
• 手動でアップデートしてもらう

のどちらかになります。通常の個人利用の端末では、自動 or 手動をユーザが設定アプリで指定しますが、MDM管理下にある業務端末の場合はMDM側でアップデートのポリシーを定めます。

(BizMobileの場合はアプリ毎に自動更新にするかどうかを切り替えられる、自動更新のチェックを入れていなければ手動)

自動にするか手動にするか。これはカスタムAppの種類にもよりますし、同じカスタムAppでもバージョンによってどちらが良いかは変わってきます。よく吟味して設定しましょう。

ライセンス購入配布したカスタムAppの再インストール

デバイス側で万が一カスタムAppを削除してしまったらどうなるのでしょうか。答えは、

インストール命令が再び送られ、再インストールされる

です。大半のMDMサービスは、端末をMDMで設定した通りの状態にしようと積極的に働きかけてきます。端末側のアプリ一覧にMDMでインストール指定したアプリがなければ「欠けてるぞ。インストールせよ！」と命令が降ってくるイメージです。そうしないと遠隔管理の意味がないですから当然の動きですね。

(MDMの設定と差分がないか定期的な確認と同期命令が送られる)

よってユーザがカスタムAppを勝手に削除してしまった場合でも心配無用。MDMからの命令により再インストールされることになります。ただし監視モードでない端末では以下のようになる点は留意してください。(参考 : iOSの監視モードとは何か)

(監視モードでない場合は再インストールを強制できない。強制したい場合は監視モードにすること)

MDMがカスタムAppの削除を認識するタイミングや再インストール命令を送ってくるタイミングは、MDMサービスによって異なります。詳しくはMDMベンダーに確認しておくのが良いでしょう。(弊社がよく利用するBizMobileでは毎日深夜2:00頃とされています)

一方ユーザ(従業員)から「間違って削除してしまった…」と連絡があった場合は、その都度MDMから当該端末を「同期」してあげれば数秒後に再インストールされます。

なお当然ながら、自動手動に関わらずアプリ内に含まれていたデータは復旧しませんので注意して下さい。

以上、ライセンス購入したカスタムAppのアップデートと再インストールについて解説しました。次回はもうひとつのカスタムApp配布方法である「引き換えコード」を使った場合の、アップデートと再インストールについて解説します。

カスタムAppには、MDM連携するライセンス配布と引き換えコードによる配布と2種類があります。

• カスタムApp（CustomApp）とは何か（４）〜自社専用業務アプリをMDM連携で配布する〜
• カスタムApp（CustomApp）とは何か（５）〜自社専用業務アプリを従業員の個人所有端末に配布する〜

前者はともかく、後者の引き換えコードの場合はコードやURLを配布すれば誰にでもカスタムAppを提供できますから、業務に全く関係のない人に配布しようと思えばできてしまいます。ただ、さすがにAppleがそれを許容する筈もなく、カスタムAppには配布対象制限が設けられています。

そこで本稿では Apple Business Manager の利用規約を読み解き、カスタムAppの配布可能範囲について考察してみたいと思います。

なお本記事の内容は、Apple Buisness Manager Agreement についての弊社解釈を記すものです。必ず自社で利用規約を確認し、法律に詳しい専門家にも確認の上で最終判断を行うようにして下さい。

Apple Business Manager 利用規約の入手方法

まず利用規約の入手の仕方をおさえておきましょう。ABMの利用規約は過去分に遡っていつでもPDFを入手できるようになっています。ABMにサインインして、[設定]→[契約情報]→[利用規約] の順にクリックして一覧を表示して下さい。

(過去にABM上で同意した利用規約が全てPDFで入手できる)

一覧の中から Apple Business Manager 利用規約 をクリックするとPDFで入手できます。一覧下にスクロールすると過去に同意した分まで確認できますが、一番上の新しいものだけで十分です。

日本語で書かれていますがPDF後半には英語での原文があります。以下では日本語部分のみを引用しながら解説しますが、原文も併せて確認することが推奨されます。

利用規約の1ページ目に結論が書いてある

身も蓋もないのですが、利用規約を読み進めると最初のページいきなりこんな記述が飛び込んできます。

「契約」とは、このApple Business Manager契約を意味します。明確性のために明記すると、
このApple Business Manager契約はApple Device Enrollment Program契約の後継となる契約です。

実は、もう規約上でABMはADEPの後継であると明記されているのですね。よって、配布対象の制限も同じと考えるのが自然です。ADEPでは契約主体企業の従業員や業務委託者にしかアプリを使わせてはいけないのでした。であれば同じ解釈で、カスタムAppの配布可能範囲もまたABM利用主体企業の従業員や業務委託者に限定される筈です。

さすがに「後継です、以上！」の説明しかないわけではありませんので、配布可能範囲について書いている箇所を以下で詳しく見てみたいと思います。

利用規約を読み解く

カスタムAppの配布可能範囲に言及があるのは「2.6 コンテンツの購入」です。

本サービスではコンテンツの取得が自動的に無効化され、お客様による利用には、
アプリケーションとブックを利用する前に本サービスにおいて提示されるVolume Contentの利用に関する要件
および諸条件が適用されます。

お客様は、お客様の管理者に購入権限を付与し、Appleの Volume Purchaseの諸条件へのアクセスを許可して、
本サービスの一環として利用および管理のためのコンテンツを購入できるようにすることにより、
当該管理者が本サービスを介してコンテンツにアクセスできるようにすることを選択できます。

お客様は、こうした購入および適用される諸条件の遵守について単独で責任を負います。
お客様が本サービスの一環としてコンテンツを購入する場合、
お客様は、お客様がお客様の正規ユーザーに代わってそうした諸条件を受諾する権限を有していること、
およびそうした条件を受諾することに同意するものとします。

ここでいうお客様はABMの利用者のことですが、最後の一文に「正規ユーザーに代わって諸条件を受諾する」とあります。ABMでは情シス等の部門担当者が、従業員ユーザの代わりにカスタムAppを一括購入して配布することになるため、このような書き方になっています。

ということは、代わられることになる「正規ユーザー」が、コンテンツ(つまりアプリ)を配布する対象を示していると言えそうです。では「正規ユーザー」とは誰でしょうか。利用規約のp.2には以下のように定義されています。

「正規ユーザー」とは、お客様の会社もしくは組織の従業員および外部契約者(もしくはサービスプロバイダ)、
またはお客様の認可事業体の従業員および外部契約者を意味し、
お客様が病院である場合、「正規ユーザー」の用語には認定医、紹介元となる医師および臨床医も含まれます。

正規ユーザーとは、まず従業員か外部契約者とあります。これにより、

• 企業が雇用する正社員・非正規社員
• 企業が雇用するアルバイト
• 企業が業務委託する個人事業主

などが含まれることになると解釈できるでしょう。組合系組織や合同会社の場合は雇用という関係性が無い場合がありますが、その場合は組織の構成員や所属する人員まで解釈を拡大しても問題ないでしょう。いずれにしてもABM利用企業の「身内」に限定されるというわけです。

NGケースとなる例をあげると、ある製品の販売支援アプリを製品開発企業が開発し自社のABMを介してカスタムAppとして販売代理企業のスタッフに使って貰う….といったケースでしょう。販売代理企業の従業員は、製品開発企業の「正規ユーザー」に含まるとは考えにくく、ADEPと同様にNGと考えるのが妥当です。(参考 → ADEPの契約ができないパターン集)

ただ、「正規ユーザー」に「認可事業体の従業員および外部契約者」も含まれるという定義は、カスタムAppの配布可能範囲を広げる可能性があります。「認可事業体」とは何でしょうか。同じく利用規約のp.2に定義されており、

「認可事業体」とは、（a）お客様が⾃動⾞メーカーである場合は、お客様の正規ディーラーお
よび認定サービスパートナーのことを、（b）お客様がホテルの持株会社である場合は、お客様
の名称、商標、もしくはブランド（またはその持株会社が所有もしくは管理している名称、商
標、もしくはブランド）の下で運営されているホテル資産のことを、または（c）Appleがその単
独の裁量により書⾯で承認することのあるその他の類似する事業体を意味します。

とされています。

(a)(b)はまさに販売代理店的な位置づけとして期待されるものですね。ただ自動車業界とホテル業界についてのみ明示的に許容されているだけであり、残念ながら該当しない事業の場合は (c) 該当となるようAppleの承認を求める必要があります。

実はこの(a)〜(c)も最新のADEP契約書と同じ記載なのですが、開発するカスタムAppが自動車業界とホテル業界に関係する場合は、カスタムAppの配布可能範囲を広範囲に解釈できる可能性があります。

以上、カスタムAppの配布可能範囲について解説しました。

原則は ADEP と同じであり、ABM利用主体の企業の従業員や業務委託者にしか使わせてはいけないということです。カスタムAppの多くはMDM連携して管理デバイスに配布されますから、おのずから従業員や業務委託者以外には配布されにくくなっていますが、引き換えコードを使って配布する場合には注意が必要でしょう。

なお冒頭の繰り返しになりますが、ご紹介した解釈はあくまで弊社による解釈ですので、各エンドユーザ企業におかれてはABM利用規約の英語原文も確認のうえで最終判断されるのが良いでしょう。

結論から言うと、カスタムAppとしてリリースするための審査回避方法はありません。

必ず審査を受ける必要があります。自社専用の業務アプリは、カスタムAppとして申請して、審査に通過して、ABMで「購入」して、ようやくiOS端末に届けることができます。ABMを介する以上、審査は必須です。

(原則的にカスタムAppでも審査を免れることはできない)

これまでADEPでのInHouseアプリ開発・納品経験のある開発会社やSIerにとっては、残念なお知らせでしょう。ただ全く方法がない訳ではありません。そこで本稿では、審査回避しるう配布方法を1つ紹介します。

TestFlightの内部テスト使う

AppStoreには、TestFlightというアプリ公開前テストのための仕組みがあります。

(元々あるベンチャーが開発していたテストの仕組み。Bustly社が買収後、Appleが買収・統合し2014年から公式提供)

通常、AppStore公開アプリを事前テストする文脈で紹介されますが、このTestFlightはカスタムAppでも使うことができます。カスタムAppはAppStoreアプリの一種だからですね。

→

(左はテストバージョンが配布されるTestFlightアプリ。TestFlight経由でインストールしたアプリは黄色い●印がつく)

TestFlightを使えば、ABMを介すことなくTestFlightアプリ経由でカスタムAppを配布することができます。カスタムAppの説明でよく載せている図に描き加えるとすると以下のような感じですね。一番右端です。

(TestFlightは審査通過を前提とするABMの迂回路になりうる)

TesetFlightには以下の通り内部テストと外部テストがあり、内部テストを使うと実質Appleの審査を受けることなくカスタムAppが配布できます。

ただしTestFlightは、

• テスト・評価の用途限定
• 有効期限が90日(90日毎に再ビルド再配信が必要)
• AppleID必須
• 配布対象数に上限がある
• 配布ツールとして専用のTestFlightアプリのインストール必須

など様々な制約があります。審査回避できるとはいえ、この方法で配布できるケースは研究開発やPoCを目的とするアプリの場合に限られます。通常業務に使うリリースが見えてきた時点で、最新バージョンを正規の審査に提出することになります。

カスタムAppの審査を実質的に回避する方法は、このTestFligth内部テストを使う方法に限られます。これ以外に、カスタムAppの審査を免れる方法はありませんし、ADEP/InHouseのようなやりたい放題をカスタムAppに期待することは残念ながらできません。

ですので、ADEPの契約を持っていない企業が専用の業務用アプリ開発を行う場合、カスタムAppでの審査は原則必須で不可避と考えておいたほうが良いでしょう。審査を迂回する方法を考えるより、本当に審査を回避する必要があるのか？を今一度考え直すほうが賢明です。

そもそも、なぜ審査を回避したいのか？

企業や案件によって理由は種々様々ですが、代表的なよく聞く理由と、それが審査回避を目指す理由にはならないことについて幾つか書いてみようと思います。

アプリ配信を審査完了まで待ってられないから

先の投稿の通り審査には1-3日程度しか要しません。これはAppleも公式に述べていますので、例年末のクリスマス休暇に伴う審査受付停止時期にかぶらない限り通常は問題にならない筈です。

「万が一通らなかったら…？」

その場合は事前に申請しておくと良いです。本申請でなくても、TestFlight の外部テストでも良いでしょう。App Store Review ガイドラインに抵触していないかどうか Apple に事前チェックして貰うようなものです。

それでも万が一の時にどうすれば？…と気になる場合は、AppStore公開アプリと同様に緊急申請という仕組みがあることを知っておくと安心できるのではないでしょうか。

(どうしても大至急審査が必要な場合は使用できる。余程のことがない限り使ってはならず乱発は厳禁。ADP契約企業のみ申請可能)

以上をふまえても「やはり自社都合でいつでもリリースできる状態を担保したい、だから審査は嫌だ」というなら、まずアプリ開発の計画そのものや品質担保体制を考え直すことをお勧めします。

Appleが推奨されないAPIの使い方をしたいから

推奨されていないと分かっている場合は考え方を改めましょう。推奨されたAPIを使って実現できないかを考えるか、iOSアプリとして開発することを諦めたほうが良いです。

機密性の高い情報を扱うアプリだから

認証機構を実装して、審査用アカウントと審査用ダミーデータを用意して申請しましょう。

(審査用アカウント情報を提供する申請画面。アカウント情報以外にテストの手順を詳細に解説したり、レビューに使う添付ファイルを送ることも可能)

Appleに審査用アカウントでログインして貰った上で審査して貰えます。審査用アカウントでは機密性を除外したダミーデータしか参照されない仕組みにしておくと良いでしょう。

通常、どんなシステムでもテスト用のデータセットとテスト用アカウントを用意して関係者の間でレビューするものです。そのアカウント情報をAppleにそのまま伝えるだけで十分です。

最新バージョンではない自由なバージョンで配布したいから

ADEPによるInHouse配布と同様の自由度を求める場合によくある理由です。InHouseアプリの場合、いつでも任意のバージョンに戻すことができました。が、カスタムAppでは常に最新版が配布されます。AppStore公開アプリと同様、過去バージョンに戻すことはできません。

ただ、TestFlightの内部テスト→外部テストで本配布前に十分なテストを行うことができますし、また万が一の時には先に述べた緊急申請という手段もありますから、過去バージョンに戻せることを必須とする理由はない筈です。

それでもやはり心配であれば、TestFlightで複数バージョンを提供しましょう。有事の際は一時的にTestFlightから過去バージョンを使ってもらうのもアリです。

→ →
(TestFlightアプリからカスタムAppの過去バージョンから選択的にインストールする様子)

以上、カスタムAppの審査回避について考察しました。まとめると以下のとおりです。

• 原則、審査は必須。避ける方法はない
• 技術評価やPoC用途であれば TestFlight の内部テストで運用しうる
• 審査を避ける理由の幾つかには妥当性がないので審査は受け入れる

弊社所感ですが、悪意(非推奨APIを意図的に使う)や知識不足(推奨APIでできることを知らない)、計画不足(無理なスケジュール)や品質不足(テスト体制の不備)といったことがない限り、カスタムAppの審査を迂回したいと考える理由は余りありません。APIへの確かな理解で計画的なアプリ開発をしたいものですね。