ADEPからADPへの移行(カスタムApp化)を進める企業や、新たに独自アプリを作る企業、またそうした企業を支援する関係者の方に役立てて頂けるかと思います。

自社従業員に使わせるアプリで、かつADPを前提としている点はご留意下さい。1枚ものの簡単なチャートになります。

画像貼り付けだと少し見にくいのでPDFも用意しました。以下にチャートの順に解説しますので、別ウィンドウでPDFを拡大しながら読み進めて頂くと良いと思います。

配信方法選定チャートの解説(1) : そもそも論

チャートは左上からスタートです。まず最初の判断は、

ここですね。まさかの「Webにしましょう」です。本サイトでもいくつか関連エントリを書いています。

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

弊社はiOSアプリと関わり始めて2025年6月時点で17年近く。その間、B2C/B2B/自社アプリ/受託アプリこれら全ての組み合わせを色々経験していますが「安易な自社アプリ開発はお勧めしない」が一貫したスタンスです。今も昔も業務用iOSアプリの真理だと思っています。

(10年以上前のセミナー資料。自社アプリを作るのは最終手段であると解説し続けてきた)

MDM/ABMを併用すれば、自社専用のアプリがなくてもWeb技術だけでiOS端末を十分に活用できます。なので、カスタムApp化を考える場合も新規アプリ開発をする場合も、まず真剣に「本当にWebではダメなのか？」を問うてみることをお勧めします。

2025年現在、業務用アプリの9割はWebで十分であるという感触を持っています。以下もご覧下さい。

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-
• WebクリップはSafariを削除していても使用できる(ようになった) -Webクリップとは何か(4)-

配信方法選定チャートの解説(2) : PoCや実験

Webが無理なら、次はTestFlightの活用を検討して下さい。

TestFlightの最大のメリットは審査関連の面倒臭さがないことです。ユーザが100人以下ならTestFlightの内部テスト、ユーザが100人より多く10000人以下なら外部テストが使えます。外部テストには審査が必要ですが、あってないようなものですし、バージョンを変えない限り無審査というハックもあります。

TestFlightのデメリットは主に以下2つ。

• 有効期間は90日
• AppleIDが必要

ただ前者は1,2ヶ月ごとに定期的にビルドを作ればほぼ解決です。後者は、ABMを使って全社員にAppleID(Manged AppleID)の供与が容易になっているため、昔に比べてハードルは下がってます。Managed AppleID については以下をご覧下さい。

• AppleIDの新規登録方法 2024年保存版 – ABMからの登録 –

従業員が多い場合は EntraID や GoogleWorkspace との連携も活用できますので、TestFlightのAppleID要件はデメリットにならないケースもあります。

配信方法選定チャートの解説(3) : 本番稼働でも審査回避

TestFlight が適切でない場合、AdHoc 配布を検討することをお勧めします。

繰り返しますが、業務用iOSで一番面倒でかつ運用に制約を与えるのは審査関連です。それを避けるためのWebであり、TestFlight であったわけですが、それらがダメなら次は AdHoc です。

AdHoc についての詳細は以下をご覧ください。

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

Apple Developer Program に明示的に端末識別子(UDID)を登録して稼働させる方法で、端末種別ごとに上限100台以下に抑えられるなら、ADEP の InHouse に近しい運用が可能です。

先に書いたTestFightの「AppleIDが必要」という条件は満たせないが、100台以下のPoCや実験アプリである場合でも有用です。

配信方法選定チャートの解説(4) : AppStoreからの配信

チャートもここまでくると、AppStoreからの本配信しか選択肢がありません。

AppStoreからの本配信にも種類があり、最初に検討すべき配信方法は「公開アプリ」です。我々が個人利用で App Store で見かけるようなアプリと同じ位置付けとなります。社名や関連名で検索した時にアプリの存在を知られても良い場合に採用できます。

公開アプリをまずお勧めするのは、他の選択肢である非公開アプリ(カスタムApp)と非表示アプリに比べて、実績のある開発会社が多くアプリ開発から配信までスムーズに進む可能性が高いからです。

非表示アプリなら追加の特別な審査が必要だったり、非公開アプリ(カスタムApp)ならABM/MDMの知識や運用体制も必要だったりと少々面倒臭くなります。

配信方法選定チャートの解説(5) : カスタムApp or 非表示アプリ

ここまでくるということは、Web技術では実現できず、まとまった端末数で本稼働させる必要があり、世間に知られたくないアプリです。この場合、どんな端末で動作させるのか？という視点で三択になります。

ひとことでカスタムAppといっても配信の仕方には2種類あり、インストールの仕方も変わります。どのような端末に配信するかに応じてどちらかを選ぶことになります。

• カスタムApp (管理対象ライセンス)
• カスタムApp (引き換えコード)

大半の場合(国内従業員向けの非公開アプリ)は、前者です。一方で以下に該当する場合は後者です。

• 端末を会社支給せず個人端末を業務に使わせるBYODスタイル
• MDMが導入できないケース

後者の引き換えコードを選んだ場合、業務用アプリが個人AppleIDに紐づいてインストールされる(つまり退社後も使われる可能性がある)点には注意して下さい。万が一に備えて認証機構を備えたアプリでなければ採用はできないでしょう。

また、日本企業としてABMの利用申請を行った場合、海外従業員のBYOD端末に対しては、カスタムAppの引き換えコードライセンスは使用できません。必然的に非表示アプリを選択することになります。

(研修資料より。AppStoreは国ごとに分かれており、カスタムAppの配信は国単位で閉じる必要がある)

あるいは、端末管理や運用体制まで調整して「国内法人で調達した端末に管理対象ライセンスでインストールして、海外従業員に当該端末を使わせる」という逃げ道を採用することもできます。

海外従業員への非公開業務用アプリの配布は、カスタムAppやライセンスの種類、ABM/MDMの十分な理解がないと難しいので余りお勧めしません。素直にWebアプリにしましょう(笑) というのは冗談で、非表示アプリか公開アプリにしてログイン機構を設けるのがベストです。

以上、ADP前提で自社従業員が使うアプリをどう配信するかの判定チャートを解説してきました。配信方法を決定する社内ルールを作る時の参考として頂ければと思います。もし「このアプリはどの配信方法が良いんだろう？」と気になる場合、こちらよりお問い合わせ下さい。

なお、本チャートは ADEP InHouse は考慮していません。ADEPは意外にもまだ使えている企業が多く、徐々に移行を強いられている印象ですが、まだ使えるなら使い続けるのが最善です。カスタムApp化を考える時に本ページのチャートを参考にして下さい。

また本チャートでは、従業員が使用するアプリを前提としました。もし「販売代理店に使って貰うアプリ」「ソリューションを販売した顧客企業の従業員が使うアプリ」のように自社従業員利用でない場合は少し異なるので注意して下さい。非従業員のケースはまた別の機会に紹介したいと思います。

今回もリアルとオンラインの併催となりました。自分は昨年同様に現地で登壇させて貰った次第です。

(2日目の会場朝一の様子)

コロナ禍を経て外出機運が高まっていたこともあってか、担当させて貰ったトークには20人程度の方に参加して頂きました。会場にも人は多く、どのトークも会場の席が埋まっていて盛況だったように思います。

(CC-BY-NC 4.0 / iOSDC2023の公式アルバムから。今回のトークは昨年以上にオフライン・オンラインでご覧頂いた)

自分が担当したトークでは、まずADEPの歴史を振り返り、2023年がADPへの移行という過渡期にある現状をお伝えしました。あわせてADEPの契約が万が一更新できなかった場合の配布済みInHouseアプリの挙動についても、弊社調査をもとにご紹介しました。

(2020年台に入ってから徐々に厳しくなってきた)

ADEPはオワコンとただ煽るということはしたくなかったので、公式サイトの条件さえ満たしていれば暫くADEPも更新維持できるであろうという考えは強調しました。

ADEPからの主だった移行先はカスタムAppになるわけですが、カスタムApp化で実際にハマりそうなポイントを弊社経験を元に幾つかご紹介し、ADEP更新をリジェクトされてから動くのではなく、事前にカスタムAppを申請する直前までの手順演習もお勧めさせて貰った次第です。カスタムApp以外に、AdHoc配布や非表示Appに移行することも可能であり、どのようなシチュエーションで採用しうるのかも紹介できました。

今回のトークでお話した情報が、ADEPのInHouseアプリで運用中の多くの企業で円滑に移行できる一助となれば幸いです。

トーク後には、お聞き頂いた方々から、実際に直面している状況でしたとか参考になったなどのコメントを沢山頂きましたので、タイミング的にもテーマ的にも良かったのかなと思います。今回の資料はこちらからダウンロードして頂くことができますので、よろしければご覧下さい。

今回も現地に足を運んでいましたので、一参加者として色んなトークをお聞きして勉強させて貰いました。関係者の皆さん、お疲れ様でした。もし可能であれば次回もまた何かエンタープライズiOS関連のテーマでプロポーザルを提出させて頂こうかと思います。

AdHoc は、Appleの審査を回避して非公開に業務用iOSアプリを配布する方法の一つです。

従来、同要件に対しては InHouse を選択することが常でしたが、InHouse アプリを生成するのに必要な契約(ADEP)は新規契約が事実上不可となり(2020年頃)、近年は契約更新できない(2022年以降)ケースも散見され、状況が変化してきています。

この状況を鑑みると用途や制限を含め改めてAdHocを正しく理解しておくことは重要でしょう。ということで、本稿では AdHoc について紹介します。以下目次となります。

• 用語の定義
• AdHocの特徴
• AdHocアプリの起動端末制限の仕組み
• 端末数上限100台の数え方についての注意点
• AdHocアプリの配布方法

参考にできる投稿へのリンクも示していますので、併せてご覧下さい。

用語の定義

AdHocとは、Apple Developer サイトで取得した AdHoc 用 Provisioning Profile を使ってiOSアプリを署名生成することです。

(Apple Developer サイトで AdHoc 用の Provisioning Profile を作ろうとしているところ)

また、そのようにして署名・生成されたiOSアプリのことをAdHocアプリと呼び、AdHocアプリを iOS 端末にインストールする・させることをAdHoc配布と言います。

AdHocの特徴

特徴は以下のとおりです。

• Appleの審査が不要
• 特定のiOS端末にアプリをインストール可能
• インストール可能な端末数は100台まで
• ADPとADEPの両方で利用可能

TestFlight がまだ存在しなかった時代、AdHoc配布はAppleへの審査に提出する前の関係者テストに使われていましたが、今は公式テストツールとして TestFlight があります。

TestFligthは登場から10年以上も経っており、洗練されて使い易くなっています。ADP(Apple Developer Program)の契約があるならテストは原則 TestFlight 一択で、AdHoc をテスト用途に使うのは古いやり方です。では AdHoc は何のために使うのでしょうか。

テストの役割を TestFlight に譲った今の AdHoc は、Appleの審査に出したくない＆台数上限の制限を許容しうるアプリを社内や関係者に本配信する手法であると言えます。台数上限を許容できるなら、InHouseアプリと同様に非公開・非審査の業務用アプリ配信手段として利用できます。詳しくは以下をご覧下さい。

• AdHoc配布はテスト用途以外に使用できるのか

AdHocアプリの起動端末制限の仕組み

Apple Developer のサイトで AdHoc用の Provisioning Profile を作成する時、証明書とAppIDの選択に加えて、デバイスを選択する画面が現れます。

(AdHoc用のProvisioning Profile作成時にデバイスを選択している様子)

AdHoc 用の Provisioning Profile を使って生成された AdHoc アプリは、このデバイス一覧でチェックした端末でのみ起動できるアプリとなります。

(iOSアプリである ipa ファイルの構造と iOS がAdHocアプリを起動する仕組み)

iOSはAdHocアプリの ipa ファイル内に含まれる Provisioning Profile の中を見て、デバイス一覧に自分自身が含まれるかを確認します。含まれていればインストール成功ですし、なければインストールすらできません。

この際にデバイスの識別情報として使われるのが UDID です。このUDIDをあらかじめ Apple Developer サイトで登録しておき、Provisioning Profile 生成時に紐付けるわけです。

(Apple Developerの Devices の画面。ここからUDIDとデバイス名を登録していく)

AdHocアプリを動作させる端末候補の UDID は、あらかじめ収集しておかなければなりません。UDID の取得方法は以下が参考になる筈です。

• iPhoneやiPadのUDIDを調べる方法 全10種

アプリを動作させたいデバイスをあらかじめ選定する、AdHoc ではこれが前提となります。UDID の収集は煩わしいと考えられることがありますが、業務用の世界においては全く問題になりません。上記投稿の通り、業務用の世界では MDM の導入が基本でありMDMの機能により UDID の収集は容易だからです。

端末数上限100台の数え方についての注意点

Apple Developer のサイトでは UDID を100台しか登録できません。AdHoc 用の Provisioning Profile を作成する時に、その限られた100台から起動させたい端末を選ぶわけです。

ただこの100台という上限数には、注意点が2つあります。

1つは機種ごとの上限があるということ。Developer Program の契約配下で iPad / iPhone / AppleWatch / AppleTV の各機種毎に100台分のUDID登録が可能です。以前は機種に関係なく全機種まとめて合算の100台上限でしたが緩和されました。

もう1つの注意点は、台数カウントのされ方。分かり易さのために、ここでクイズをしてみましょう。Apple Developer のサイトで iPhone について以下の操作を行った場合、登録可能残数は何台になるでしょうか？

1. 10台分のUDIDを新規で登録する
2. 20台分のUDIDを追加で登録する
3. 5台分のUDIDを不要になったので削除する

10 + 20 – 5 = 25 なので、残り75台分のiPhoneが登録できる…わけではありません。答えは70台。間違い易いポイントなので要注意です。削除しても登録枠はすぐには回復しません。回復するのはADPやADEPの契約更新の時のみとなります。

(契約更新時のみ削除分が回復する)

これをデバイスのリセットと言います。ADPの画面には下図のように、リセットできる日が明記されています。この例でいうと2023年9月25日を迎えなければ、削除した分の枠は回復しないということです。

下手すると枠が空くまでに最大約1年待つことになる可能性があります。100台になったら不要なものを削除すれば良い…では運用がうまくいきません。UDID登録は計画的に行うことが必要です。最近のXcodeでは、油断してるとドンドン勝手にデバイスが登録されてしまって気がつけば上限…なんてことになりがちなことにも注意しましょう。

(Xcodeが勝手にデバイスを登録しようとしているダイアログ)

外部委託する先が多数あるような大手企業においては、ルールを定めず開発会社に丸投げしているとアッという間にUDIDが枯渇します。特に ADP 契約下で TestFlight を使わずに AdHoc でテストを行う古いやり方をしていると、テストもまともにできない状況に陥りかねません。最悪、端末を融通しあうための調整といった無駄なテスト工数が増えます。テスト設計については以下の投稿も参考にして下さい。

• カスタムAppで顧客側の受け入れテスト(UAT)を実施する際の注意点

AdHocアプリの配布方法

AdHoc アプリは、Apple の審査を必要としませんので様々な方法で配布できます。以下の投稿を参照して、運用に都合の良い方法を選んで下さい。

• ipaファイルをiOS端末にインストールする方法 全8種

なお、自由に配布できるからと好き勝手に配布しまくって良いわけではありません。Developer Program の使用許諾契約書にきちんと配布可能範囲についての記載がありますので、確認しておきましょう。

(研修資料より。AdHocの配布可能範囲は厳密に定められている)

以下の投稿もご覧下さい。使用許諾契約書の弊社見解を示していますが、各社においては念のために自社法務部門の確認を行うことが推奨されます。

• AdHocアプリを社外ユーザに配布できるのか

本稿では、AdHocについて詳細を解説しました。特徴や制約をよく理解して有効活用して頂きたいと思います。

今回は、VR関係の事業を営まれている非上場企業様からの問い合わせとなります。カスタムAppを顧客企業に提供する時のテスト設計についてのご相談。実は、ケースとしては前回と似ているのですが「テスト」にフォーカスがあたった話になります。

(研修資料より。自社製品のカスタマイズバージョンをカスタムAppとして他社提供するパターン)

以下が目次です。順番に見ていきましょう。

• 質問 : カスタムAppにおいて顧客の受け入れテストはどう実施するのでしょうか？
• 回答 : TestFlight内部テストを使います
• 解説1 : カスタムAppの受け入れテストに「王道」はない
• 解説2 : ADPのAdHocを受け入れテストに使うのは悪手
• 解説3 : 本番用と異なる検証用の別アプリに存在意義はあるのか

質問 : カスタムAppにおいて顧客の受け入れテストはどう実施するのでしょうか？

Q. 当社はVR関連の自社ソリューション(アプリ)を開発・販売している企業です。個人向けにAppStore公開アプリの提供をする一方で、顧客企業に非公開のカスタマイズ版を開発し、当該顧客ADEP契約のInHouseで署名して提供してきました。

現在、顧客からADP(カスタムApp)への移行を依頼されており、あわせてテストの手順策定を求められていますが、カスタムAppでどのように顧客側の受け入れテスト(UAT : User Acceptance Test)を進めていくのかが分かりません。

ADEPの時はInHouse配布をすれば良かったので余り悩むことがなく、検証用アプリと本番用アプリを分けてビルド・配布して受け入れテストと実配布を行っていました。カスタムAppではどのように顧客の受け入れテストを設計すれば良いのでしょうか？

回答 : TestFlight内部テストを使います

A. 仰る通りADPではADEPのようにはいかないため、顧客の受け入れテスト(UAT)の要件に合ったテスト設計を適宜行う必要があります。具体的に回答するには、エンドユーザ企業様のテスト要件ヒアリングが必要です。が、今回それはできないとのことですので、残念ながら抽象的な回答となります。

カスタムAppでは、原則 TestFlight の内部テストを使います。ですので TestFlight をよく調査し、顧客要件にあったテストを設計して下さい。基本的には以上です。

調査用に設計のコツをキーワードでお知らせすると、内部グループをうまく使い分けること、ビルドのコンプライアンス設定方針を考えること、の2点でしょうか。

一点、テストの考え方について補足いたします。

検証用アプリと本番用アプリを分けるのは余り良い方法ではありません。時折見られる手法ですが、そもそも実行バイナリとして別物を使って動作確認するのは、本当に「検証」と言えるのでしょうか？

TestFlight は AppStore アプリのために用意されており、「同一バイナリ」をテスト用と本番用とに配信し分けて、真の「検証」と実稼働を共存できる仕組みになっています。カスタムApp は AppStore アプリですから、テストも TestFlight の考え方や仕様に合わせるのが最善です。

我流を通そうとすると必ずどこかで進めにくさや違和感・無駄が発生することになります。特別な事情がない限り原則アプリは1つとし、検証と本番の切り替えは実装側で吸収することをお勧めします。

解説1 : カスタムAppの受け入れテストに「王道」はない

テストをどう行うか？は、カスタムAppを開発・テスト・配布まで自社完結できないケースで必ずぶち当たる壁です。

ADEP(InHouse)では好きに配布すれば良かったので課題にならなかったのですが、ADP(カスタムApp)では Apple の用意するテストツールである TestFlight を使って、自社なりの、アプリなりの、「テスト設計」が必要になります。

(学習教材としてTestFlightの公式ドキュメントがある。これをよく読み実際に試すことが推奨される)

App Store Review ガイドラインのような指針は特に与えられていませんから、TestFlight を十分に理解した上で、個々事情を考慮したテストの段取りを作り上げないといけません。これを誤ると開発がうまく進まなかったり、開発体制をスケールさせにくくなったりします。

また TestFlight は App Store Connect と無縁ではいられません。App Store Connect の仕様変更に影響を受ける場合もありますので、「テスト手順を策定する」といったミッションは、意外に難しかったりします。

(WWDC2021の動画から。カスタムApp では App Store , App Store Connect, TestFlight の全てを理解する必要がある)

ソフトウェア開発全般に言える事ですが良いソフトウェアの影には必ず良いテスト設計が存在します。カスタムApp化には、エンドユーザ側にも開発会社側にも TestFlight の理解が必要不可欠です。

弊社では、カスタムApp移行を御支援する際に「この方法なら概ね大丈夫」というパターンをベースにして、企業ごとの要件で調整してご提案することが多いです。

解説2 : ADPのAdHocを受け入れテストに使うのは悪手

テストにAdHoc配布を使えば良いのでは？という意見も一部にはありますが、弊社では推奨していません。大手企業では特に、アプリの数やiOS端末の利用部門が増えてくると「詰んで」しまうからですね。どういうことか。

AdHoc配布では、配信先の端末数が100台までという上限があります。

特に大手企業あるあるですが、部門別に色んなアプリを作り、外部委託先が何社もあって、しかも多段の商流を組んでいて関係者が多い…なんて状況では、すぐ上限を振り切ります。開発会社が開発側のテスト用に勝手に大量登録してしまった…なんてケースもありますね。

そして、あるタイミングで突然「テスト用端末を追加できない」と報告があがり「詰む」ことになります。「どの端末を消すか調整しよう」と動いたところで残念ながら手遅れで、詰んだ状態はすぐには解消しません。削除した端末数分をすぐ追加登録できるわけではないからです。ADP契約の更新日まで待たなければなりません。

(リセット日とはADPの契約更新日。削除した端末個数分を新たな追加枠として使うにはリセット日を待つ必要がある)

将来、アプリの数も関係者も増えない、と断定できるなら TestFlight を使わず AdHoc をテスト用途に使うのもありかも知れません。

いつ上限を超えるかコントロールできず、開発側の勝手な登録を禁止することもできない AdHoc は、外部委託が基本の大手企業においては特にテスト用途には不向きです。むしろ、稼働台数が数十台程度という制約付きで InHouse 配布と同じ運用ができる配布手段と捉えたほうが良いでしょう。詳しく以下をご覧下さい。

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

弊社では、開発を外部委託している企業様のADPでは、AdHoc配布をテスト用途に使わないことを推奨しています。

解説3 : 本番用と異なる検証用の別アプリに存在意義はあるのか

今回のご相談では「検証用」アプリと「本番用」アプリとが別アプリだということでした。実は時々ありますが、弊社では余り推奨していません。

AppStore アプリにおいては、検証と本番をアプリ実体で分けるものではありません。Apple が用意する仕組みを読み解けば、Appleは検証と本番はアプリではなく配信ルートで分けるべき、と考えていることが分かります。

(WWDC2021の動画から。開発したアプリ(ipa)はテストならTestFlight、本番はAppStoreへ。行き先が異なるだけ)

同じアプリの用途違いでアプリの実体を複数作るべきではないのです。

• 検証用アプリと本番用アプリが別々に存在する
• 検証用配信ルートとしてTestFlightが、本番用配信ルートとしてAppStore+ABM+MDMが存在する

これをうまく使い分けられるでしょうか。検証用のアプリを本番用途の App Store → ABM → MDM と流す意味は何でしょう？ただでさえ複雑なカスタムApp配信に、自ら複雑さを加えることはないと考えます。

少し話は変わりますが、その昔、一般消費者向けの有償アプリの世界でも似たようなことがありました。「機能制限つきのFree版アプリ」と「フル機能の有償版アプリ」と、2つの別物アプリを開発会社は作り分けていたのです。弊社もやっていました。懐かしいですね。

(初期のAppStoreで弊社アプリを一覧した画面。フル機能の有償アプリ(右)と無償のLITE版(左)を別アプリで提供していた)

このような手法でアプリ数が無駄に増えることをAppleは良しとせず、1つのアプリで両役割を持たせられるよう In App Purchase (アプリ内課金) の仕組みを用意しました。それが2009年のこと。その後 AppStore からは、1つのアプリでFree版/有償版の2種類存在するケースは無くなっていきます。

実は業務用でも一緒です。特別な理由がない限りアプリは原則1つとし、実装で工夫をして同じアプリを用途ごとに使い分けられるようにするのをお勧めします。MDMからの本番用配信でのみアプリの特別な設定値を有効にする Managed App Configuration も活用できるでしょう。以下もご覧下さい。

• iOSDC JAPAN 2021で Managed App Configuration について講演します
• iOSDC2021で Managed App Configuration について講演しました -YouTubeで動画公開されました-

以上、カスタムAppにおけるユーザ受け入れテスト(UAT)についての質問＆回答と解説でした。

カスタムAppへの移行ではハマりどころが幾つかありますが、テストはその中でも比較的大きめのハマりどころです。App Store Connect、App Store、TestFlight に加え、ABM や MDM も理解していないと、業務用アプリのライフサイクル全体を設計できないからですね。関係者が多く、事前に手順書等を規定しなければならない大手企業の場合は結構大変です。

繰り返しになりますが、TestFlight をよく調査研究することが推奨されます。今後、カスタムAppの観点からのTestFlightについても解説していこうと思います。

Appleの審査を避けたい事情はアプリによって様々です。

そもそも審査の手続きが面倒だ、プライベートなAPIを使いたい、本来用途と異なるハック的なAPIの使い方をしている、AppStore Review Guidline に反した事をやりたい…などなど。B2Bの世界では、そもそも「ウチで使う業務アプリをなぜ審査されなくてはならない？」という感覚の方もいます。

理由はどうあれ業務用iOSアプリの世界では、Appleの審査を避けるなら InHouse(ADEP) 一択だ…と誤認されてきました。しかし実は、Appleが InHouse(ADEP) 以外にも審査回避手段を用意していることは意外に知られていません。InHouse(ADEP) が余りにも強力過ぎて(審査不要・無制限配布)、他の手段に目が向けられることがほとんど無かったからでしょう。

そこで本稿では、InHouse(ADEP) を含め、改めてアプリ審査を回避できる配布手段を整理してみたいと思います。当然ながらすべて公式に提供されているもの。まず以下に一覧を示します。

関連する投稿へのリンクも貼っていますので併せて参照して下さい。それでは順に見ていきましょう。

InHouse – ADEP (Apple Developer Enterprise Program)

審査回避手段として一択と誤認されているぐらいですから、真っ先に思いつくのがこちらでしょう。

詳細については以下をご覧下さい。

• ADEP (Apple Developer Enterprise Program) とは何か

しかしAppleは、2019,2020年頃から新規受付を事実上停止しています。また、2022年からその更新も審査制に変わりました。審査の結果、更新を認められなかった、つまり InHouse が使えなくなった企業も出始めています。詳しくは以下をご覧下さい。

• ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜
• そろそろADEP契約更新ができなくなるかも知れない…その後(1), (2)
• 実録！ADEPの更新を拒否されるまでの全て (1), (2), (3)

今後はどうなるか分かりませんが、長らく業務用iOSアプリの世界を見てきた弊社の見解は「新規受付の復活は考えにくいし、更新も徐々に厳しくなっていくと思われる」です。

ADEPの契約が既にできていて且つ2023年現在まだ更新ができている企業の場合、ADEPを使い続けるのが合理的な選択です。そうでない企業がApple審査を回避したいなら、後述の3つの選択肢から選ぶことになります。

AdHoc

ADP(Apple Developer Program)を契約して、その契約の配下で AdHoc 形式の配布を選択することにより Apple の審査を回避できます。(AdHocはADEPでも使えるが実質使い道がない)

(研修資料より)

AdHocはiOSアプリの歴史的経緯から、テスト用の配布手段と認識されていましたが実はそうではありません。ADP契約毎にデバイスごと100台までという上限に注意が必要ですが、本運用で使用しても実は問題ないのです。詳しくは以下をご覧下さい。

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

AdHoc 形式では1年に一回の Provisioning Profile 更新が必要となります。しかしAdHocもMDMからの配布が(多くの場合)使えることも考えれば、ADEPでのInHouseアプリ運用と大差ありません。InHouseアプリと全く同様に、Appleのアプリ審査を受けることなく端末にアプリをインストールできますので、開発しようとしている業務用アプリの配信端末数が100台以下なら、積極的に検討できる手段です。

TestFlight 内部テスト

TestFlight とは Apple が公式に提供しているテストツールです。元々はあるスタートアップが開発したものですが、買収に次ぐ買収で最終的に Apple が買い上げて洗練させ、公式テストツールとした経緯があります。

(歴史に興味があれば Wikipedia-TestFlight を参照(英語))

関係者の間で評価する場合に使う内部テストと、いわゆる公開ベータ版テストのように第三者の評価協力を募る場合に使う外部テストと2種類の仕組みが用意されています。App Store Connect からアプリをTestFlight向けに登録し、本審査前とは別のテスト用審査を受けることでテスト配信が可能となります。

(研修資料より。InHouseの経験しかない場合、TestFlightの使い方が一番の難所。研修ではテスト設計も解説している)

テストに参加するユーザはテスターと呼ばれ、テスター専用のTestFlight というアプリを介して AppStore 登録前のテストバージョンを受け取ってインストール・テスト・フィードバック送信が可能です。

(研修資料より)

この TestFlight を審査回避の手段として使うことができます。先に「本審査前に別のテスト用審査を受けると」と書きましたが、内部テスト用審査は事実上無審査だからです。アプリである ipa ファイルの正当性・妥当性のみチェックされます。

 → 
(実際にTestFligth内部テストで配信されたアプリと起動後の画面。起動後にlabelしかなくても審査は通る。本審査ではありえない)

この特性を利用することで、事実上の無審査アプリ配布が可能となります。もし作ろうとしている業務用iOSアプリが、実験的開発や評価検証用のPoCである場合は、TestFlight の内部テストを使うことも選択肢に入るでしょう。

ただしPoC を抜けた本番運用のフェーズでは、TestFlight を使い続けることができないことに注意すべきです(TestFlightはテスト用途専用)。とりあえずアプリを作ってみたい評価用プロジェクト向きの手法といえます。

Webクリップ

意外に盲点で余り知られていない手法です。通常、開発会社側にMDMと構成プロファイルの理解がなければ思いつかないアイディアだからですね。(そして開発会社の多くは残念ながらそれらを使う機会がほとんどありません)

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-

WebのショートカットであるWebClipをMDMから配布すれば、事実上の審査不要・無制限配布可能なネイティブアプリ(擬似)を実現することができます。

(研修資料より)

特に iOS 16.4 で Web Push 通知に対応した点は注目に値します。ネイティブアプリを開発する理由として頻繁に上がってくる Push 通知が、JavaScript だけで実現できるようになったのです。もし iOS16.4 以降を前提にできるなら、

「Push 通知を使いたいならネイティブアプリ開発が必要」

という常識(?)は今や非常識となり、時代遅れな認識です。開発しようとする業務用iOSアプリが、

• 審査を回避したい事情があり、
• Push通知ぐらいしかネイティブアプリ開発する理由が無く、
• 端末の原則オンラインが担保できるなら、

WebClip + MDM の組み合わせ技は有力な選択肢になります。以下の投稿も合わせてご覧下さい。

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

読者がもしネイティブは無理だがモダンな Web システム開発は可能な開発会社だという場合、WebClip は顧客への提案に使える新たなツールとなります。「Web技術だけでインストールから起動からユーザ体験までほぼアプリっぽいことができますよ」と言えるのです。これを機会に MDM + WebClip のあわせ技を学習することをお勧めします。

以上、Appleの審査を回避する手段を4種類紹介しました。諸事情や諸条件によって採れる選択肢は変わってきますが、すべての選択肢を知っておくことは有用でしょう。本投稿が、読者の関わるアプリ開発プロジェクトの開発方針決定に役立てば幸いです。

(Xcodeから.ipaを生成する画面。種類を選び正しく署名ができれば生成に成功する)

本稿では、主要な方法からマイナーな方法まで、.ipa ファイルを端末にインストールする方法を全8種類ご紹介します。詳細を記した投稿へのリンクも載せていますので併せてご覧下さい。

まずは最初に一覧です。

以下で順に見ていきます。

MDM

業務用iOSアプリの .ipa ファイルを語る場合、真っ先にあがるのがMDMを使ったインストールです。端末を集中管理して、情シス部門等の管理部門側からアプリのインストールや削除をコントロールしたい場合に向いています。

(MDMに.ipaファイルを登録する画面。このあと端末を紐付けるとインストールされる)

MDMサービス上にアップロードした .ipa ファイルは、複数端末に一斉インストールすることができます。

厳密には、MDMから端末に .ipa ファイルのパス情報(マニフェスト)が送られ、iOS端末が当該 .ipa ファイルをダウンロード&インストールする流れとなります。MDMがipaファイルを直接送りつけるわけではないことに注意して下さい。

対象となる端末が監視モードの場合は、ユーザの手元端末操作が不要となり、強制的に .ipa ファイルをインストールさせることができます(サイレントインストール)。これはMDMを選択する大きなメリットの一つと言えるでしょう。MDMについては以下をご覧下さい。

• MDMとは何か 〜今さら聞けないMDMの基礎〜

またMDMサービスによっては、InHouse に限らず AdHoc の .ipa ファイルも登録できる場合があります。以下を参考にして下さい。

• MDMではInHouseアプリだけでなくAdHocアプリも配布できる

Apple Configurator (Mac)

MacとiOS端末を有線接続してインストールする方法です。端末を都度回収して保守するとか、管理部門やアプリ開発会社の担当者が現地に赴いてメンテする運用で向いています。

Apple Configurator は有線版MDMとでも言うべきMac用端末管理アプリケーションで、.ipaファイルのインストール以外にも色んな事ができます。残念ながらWindows用はありません。詳しくは以下を参考にして下さい。

• Apple Configurator とは

Apple Configurator は、大量の端末を集中管理するのには向いてませんが、Macに端末をUSBで繋いで .ipa ファイルをドラッグ&ドロップすれば即インストールを完了できるというお手軽さがあります。

.ipa ファイルのインストールを含む一連の定型作業を自動化できるブループリントという、気の利いた機能も備わっています。

(Apple Configurator の操作マクロのようなものを作り、端末に適用できる)

もし、Apple Configurator 以外の他のアプリケーションや社内システムとの連携などを含んだ自動化をしたい場合、後述の cfgutil がお勧めです。

MDM と Apple Configurator はどちらを使うべきか…と排他的に考えるものではなく、安定運用時はMDM、導入初期や検証・障害対応時は Apple Configurator、という合わせ技がお勧めです。

OTA

自社内Webサーバに .ipa ファイルを置き、iOS端末の Safari から URL アクセスしてインストールして貰う方法です。従業員等のユーザに端末から直接インストール操作をさせたいような運用に向いています。

(研修プログラムの資料から)

分かり易く表現すると、OTAの仕組みを使えば自社内でオレオレAppStoreを構築できます。Webサーバは自社に都合の良い形で構築することができ、Xcode が生成するマニフェストファイルと一緒に .ipa をアップロードするだけ…と手順は非常に簡単です。

OTAについては詳しくは以下の投稿を参考にして下さい。

• OTA(Over The Air)とは何か

MDMのように、自動再インストールや自動アップデートのような気の利いた管理系の仕組みは備えていません。それらの機能が必要な場合は、MDMの導入を検討して下さい。

Xcode (Mac)

余りないと思いますが、Apple Configurator はインストールがされていないが Xcode はインストールされているというMacから .ipa ファイルをインストールしたい場合に役立つ方法です。

Xcode内で使える Devices and Simulators から .ipa ファイルをインストールできます。

(Xcodeのメニューから [Window] → [Device and Settings] で表示される画面)

一覧からデバイスを選び、.ipa ファイルを INSATALLED APPS の欄にドラッグ&ドロップするだけです。AppID (Identifier)や詳細なバージョン番号が表示され、.ipa ファイルに関しては Apple Configurator より詳しい情報を得ることができます。

cfgutil (Mac)

Apple Configrator に付属しているコマンドラインツールを使う方法です。UIを触るまでもない場合や、自社内で自動化スクリプト等を開発していて、一連の自動化処理の中に .ipa インストール処理を組み込みたいような場合に有効です。

シェル操作やサーバ管理に慣れている方でないと使いこなせませんが、使いこなすと非常に便利です。cfgutil については以下をご覧下さい

• Apple Configurator 付属のコマンドラインツール cfgutil の使い方

AirDrop (Mac)

AirDrop は、Bluetooth で互いを認識・識別し、WiFi を使ってデータを送受信するmacOS / iOS に標準搭載されている無線データ転送技術です。この AirDrop を .ipa ファイルのインストールに利用することができます。

Apple Configurator も Xcode もインストールしていないMacから、手元のiOS端末に .ipa ファイルをインストールしたい場合に向いています。追加のソフトウェアや、端末との有線接続も不要なので、最も手軽なインストール方法と言えます。

(OS標準の機能。サイドバーで AirDrop を選び、インストールしたいデバイスのアイコンに向けて .ipa ファイルをドラッグ&ドロップ)

上図のようにFinder のサイドバーからAirDropする方法と、.ipa ファイルを直接右クリックして AirDrop する方法とがあります。

詳しくは以下をご覧下さい。

• ADEPのInHouseなipaファイルをmacOS標準機能を使ってインストールする

Finder(Mac)

macOSに標準搭載されている Finder を使う方法です。Apple Configurator や Xcode など、管理系・開発系の macOS 用ソフトウェアを一切インストールしていない Mac で .ipa をインストールしたい場合に向いています。

(Macに有線接続したiPhoneをFinderで選択し、.ipaファイルを直接ドラッグ&ドロップ)

前記の AirDrop を使う方法と違い、無線ではなく有線になってしまう点には注意が必要です。

ただ、後述の Windows で iTunes を使って .ipa をインストールするのと同じようなことを Mac でやる方法なので、Mac を全く知らない方に案内するには最適かも知れません。

iTunes(Windows)

Windows 環境で使える唯一の方法です。前述の MDM も OTA もなく、Windows PC しかない環境で .ipa ファイルをインストールする場合に役に立ちます。

WindowsにUSBでiOS端末を接続し、iTunesのサイドバーのデバイス一覧に .ipa ファイルをドラッグ&ドロップするとインストールできます。

ただ、この方法はやむを得ず使う…程度の臨時的手法です。常用は推奨されず、前述のMDMやOTA、またはApple Configurator等のMacを使った運用体制を構築することをお勧めします。iOS端末を業務活用するなら Windows に縛られるべきではありません。

かつては、Apple Configurator の前身としてiPhone構成ユーティリティなるソフトウェアが Win/Mac の両方で提供されていました。WIndows でも iTunes を使わずに .ipa ファイルをインストールすることができて便利だったのですが、2023年現在、Windows用iPhone構成ユーティリティは公式には存在しないことになっています。ダウンロードできる野良サイトもありますが、弊社では利用を推奨していません。

以上、InHouse や AdHoc の .ipa ファイルを端末にインストールする方法を全8種類ご紹介しました。

業務用iOSアプリの運用現場では MDM と Apple Configurator、場合によってはOTA。この3つでほぼほぼ事足りますが、手段を一通り知っておくといざというときに役立ちます。是非頭の片隅にとどめておいて下さい。

• Apple Configuratorを使う
• OTAを使う

前者についてはApple Configurator とはの投稿を、後者についてはOTAとは何かの投稿をそれぞれ参考にして下さい。AdHocアプリはこのどちらかで配布することが多いと思いますが、実はMDMでも配布できることは余り知られていません。

本稿では、MDMを使ったAdHocアプリ配布について紹介します。

MDMにAdHocな .ipaファイルも登録できる

MDMに .ipa ファイルを登録して端末へ配布する、この文脈では通常 ADEPによるInHouseアプリを想定していることが多いです。業務用アプリといえば、ADEPでの InHouse な .ipa であることが大半だからですね。

しかし、MDMに登録される .ipa ファイルは、InHouse だろうが AdHoc だろうが中身に本質的な違いはなく、あると言えば Provisioning Profile 内の記述が一部異なる…ぐらいの差しかありません。(どう異なるかはまた別の投稿に記します)

MDMプロトコルのドキュメントにもその差を問題にしている記述は見当たらず、MDMサービスが .ipa ファイルの種類を識別する理由は特にありません。そういうわけで、MDM サービスによっては InHouse アプリと同じように AdHoc アプリの .ipa ファイルも登録できる場合があります。

(弊社がよく使うMDM BizMobile Go!のアプリ登録画面。InHouseを前提としているがAdHocの.ipaファイルも登録ができる)

.ipa ファイルを登録できればこっちのもの。InHouseと同様に、AdHocアプリをMDMで管理し配布することができるようになります。

AdHocなアプリをMDM配布できると何が嬉しいか

ADEPの契約ができている(更新できている)企業に、AdHocを使うメリットはありません。100台の台数制限が必要で、事前にUDIDを取得する必要があるAdHocをわざわざ使う理由はないからです。せっかくADEP契約があるのですから、台数無制限に配布可能なInHouseを使ったほうが良いです。

では、AdHocはどのような企業にメリットがあるのでしょうか。

1つには、ADEPからADPへの移行を余儀なくされたMDM利用企業です。MDMを使ってInHouseアプリを配布していた筈ですから、代わりにADPのAdHocを使うことで従来の運用を継続できます。

• (1) ADPで配布用証明書を取得し、AdHoc 用の Provisioning Profile を作成する
• (2) 当該 Provisioning Profile を使って署名する (従来のInHouseの代わりに)
• (3) (2)でできた.ipaファイルを、これまで通りMDMに登録し配信する

このように、署名時の Provisioning Profile (と対応する証明書・秘密鍵)を差し替えるだけで、従来と同じワークフローで運用できるわけです。

(ADEPの更新が拒否され期限切れした時の画面。こうなっても総悲観はまだ早い…かも知れない)

また更に、ADPで初めて Developer Program を契約する企業で業務用アプリを非公開かつ無審査で配布したい場合にも有用です。

現在ADP契約下でのアプリ配布では通常、AppStoreインフラを使う公開アプリ・非表示アプリ・非公開アプリ(カスタムApp)とすることを目指しますが AppStore を使う以上は Apple の審査を受ける必要があります。

しかし後述する制限が許容できるなら、AdHoc を使うことで Apple の審査を迂回できます。この際に、 MDM を使用すれば業務用アプリを遠隔で無審査に配布できますので非常に便利です。

このように、AdHocはADP契約を保有する企業にとって Apple の審査回避手段として機能します。

AdHocなアプリの注意点

何の制限もなければ、それはADEPのInHouseと同義になってしまいます。無論、AdHocがInHouseの完璧な代替になるはずもなく、以下の制限と制約があります。

• アプリ動作可能端末は100台まで
• UDIDを事前に登録する必要がある
• 用途は限られないが、配布可能対象は限られる
• AdHoc用の Provisioning Profile は1年に1回更新の必要がある

この条件に収まりうる業務用アプリなら、Appleの審査は不要でMDMから自由に配布ができるというわけです。3番目の項目については以下の投稿を参考にして下さい。

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

また4番目の項目については、 以下情報が参考になりますので併せてご覧下さい。

• ADEPのInHouseアプリは1年に1回必ずビルド・再署名しなければならないのは本当か？

Provisioning Profile の更新は InHouse も AdHoc も仕組みが一緒であり、InHouseがそうであるようにAdHocもロジックに変化が無いなら毎年ビルド・署名する必要はありません。MDMから単体でAdHoc用の Provisioning Profile を配布するだけでokです。

以上、AdHocをMDMで配布することについて紹介しました。Apple Configurator や OTA に加え第三の選択肢として、AdHoc + MDM での非公開アプリ運用も是非検討してみて下さい。

各端末でAppStoreからインストールして貰う方法以外に、MDMを使って遠隔から一斉にインストールする方法、Macを使ってApple Configurator で有線USB転送で地道にインストールする方法等々です。

(アプリを端末まで届ける方法は様々)

本稿では、まだ本サイトで過去に紹介できていない、OTA(Over The Air)という方法について紹介します(上図赤枠)。OTAを使うと、InHouseやAdHocのアプリ(.ipaファイル)を社内のイントラネットに置いて、ユーザにSafari経由でアプリインストールする手段を提供することができます。

OTAが使えるアプリの種類

OTAは、AppStore向けの申請用ビルドを除く InHouse / AdHoc / Development の方式で使うことができます。

(Xcode の Organizer から Distribution を行うときの画面。上図はInHouseを選んでいるところ)

もちろんそれぞれの署名に最適な秘密鍵や Provisioning Profile がビルド環境にインストールされていなければなりませんが、署名して .ipa ファイルさえ生成できれば、OTAからのインストール用に使うことができます。

OTAの特徴と動き

OTAは、オレオレAppStoreを社内に構築できるようなものと考えると分かり易いでしょう。ipa ファイルを一定のルールで社内サーバに配置しさえすれば、ユーザは自分の端末で社内サーバにアクセスするけでアプリをインストールできるからです。

ユーザからは具体的にはこんな感じに見えます。

 → 
(インストール用のページで専用ボタンをタップするとインストールされる。成功するとHOME画面にアプリが現れる)

ユーザは指定のURLにSafariでアクセスしてボタン(リンク)タップするだけです。まさにオレオレAppStore、これを自社内サーバに好きなように構築できる技術がOTAというわけです。

注意しなければならないのは、OTAを使ったからと言ってどんなアプリも任意端末にインストールできるわけではない点です。OTAによるインストール可否は、サーバに設置する .ipa ファイルがどんな Provisioning Profile で署名されたかに依存します。

(AdHocの場合、OTAインストールを試みても端末側のUDIDが未登録なら失敗する。タップしても起動しない)

InHouse の Provisioning Profile ならその .ipa ファイルは無制限に任意の端末にインストールができる一方で、AdHoc の Provisioning Profile で署名された .ipa ファイルの場合はあらかじめ登録されたUDIDを持った端末にしかインストールできません。

OTAに必要なもの

OTAは、任意のWebサーバに .ipaファイルを置いて、ユーザにSafari経由でアプリをインストールして貰う方法です。これを機能させるために必要なものが幾つかあります。

• (A) Webサーバ
• (B) マニフェストファイル
• (C) HTMLファイル + α

これらが以下のような構成で機能するようになります。

(研修プログラムの資料から。サーバを用意し、署名生成した.ipaを含む必要なファイルをアップロードする)

順に見ていきましょう。

(A) Webサーバ

有効な証明書が設置された https 応答可能なWebサーバが必要となります。それ以外の条件はありません。Apache, NGiNX, IIS…どんなWebサーバでも構いませんし、AWS上か自社データセンター内か等インフラが何かは全く関係がありません。

• https (443/TCP) の応答
• 有効な証明書

Webサーバ側に必要なのはこの2点です。オレオレ証明書で https 応答するようにした場合、OTAによるアプリインストールは失敗しますので注意が必要です。

(B) マニフェストファイル

アプリの情報が記載されたplist形式のXMLファイルです。昨今のXcodeでは、.ipaファイルの生成時に一緒に作ってくれる機能が備わっています。

OrganizerからDistributionする時に形式を選んだ後、下図のように「Include manifest for over-the-air installation」のチェックをONにして [Next] をクリックします。

(一番下のチェックボックス。デフォルトではOFFになっている)

次に、マニフェストファイルに必要な .ipa ファイルの設置予定場所を示すURLや、アプリを示す画像ファイルのURLを指定します。

(生成されるマニフェストは単なるXMLファイルなので、後から手動で編集する前提で適当な指定をしてもok)

[Next]をクリックし署名に成功すると、XcodeのOrganizerは以下のようなファイル一式を出力してくれます。

この中の manifest.plist というファイルがマニフェストファイルです。左下の .ipa ファイルは言わずもがなiOSアプリですね。それ以外のファイルは署名時の情報が記載されたもので、OTAには不要です。

なおマニフェストファイル作成時に指定したURLのうち、Display Image URL と Full Size Image URL が示す画像ファイルはサーバ上に実在しなくても問題ありません。

(C) HTMLファイル+α

実際にユーザが Safari からアクセスすることになるhtmlファイルです。htmlの記述方法に特に制約はなく、OTAに関するルールは、

• アプリインストール用のボタンを <a> タグで作成
• href属性に特別なURLスキーマでマニフェストに関する記述

という点のみです。必要最低限のhtmlを記述すると以下のようになります。

見慣れた https:// で始まる表記ではなく、itms-services:// という特殊表記(スキーマ)であることに注意が必要です。マニフェストURLの部分を、URLエンコードしたマニフェストへのURL文字列に置き換えます。

それ以外は自由です。上記のような最小構成のhtmlが1ファイルでもokですし、CSSやjsを駆使してリッチなページにしても良いでしょう。あるいは、PHPやDBを使って社内独自のOTAシステムを構築しても構いません。(弊社では独自OTAシステムを開発していました)

OTAでインストールされるまで

ここまで紹介してきたことをふまえ、OTAでアプリがインストールされるまでの流れを整理します。OTA環境のWebサーバは構築されている前提です。

• (1) Xcode の Organizer からマニフェストファイル付きで .ipa を生成する
• (2) OTA環境に、(B)のマニフェストファイルと .ipa ファイルをアップロードする
• (3) OTA環境に、(C)のHTML+αをアップロードする
• (4) (3)のHTMLを指し示すURLをユーザに伝える
• (5) ユーザはSafariで(4)のURLを開きリンクタップでインストールする

運用フェーズではこれをひたすら繰り返す格好になります。OTAでインストールされたアプリのアップデートは自動で行われませんので、この (1)〜(5) をアップデートの度に実施する必要があります。

OTA環境のWebサーバを作るのが難しい場合

何らかの事情でOTA環境用のWebサーバを用意するのが難しい場合、OTA環境を提供してくれるSaaS型のサービスを契約することを検討しても良いでしょう。

国産であれば deploygate が有名です。

(2012年にミクシィの新事業として同社内に誕生。2015年に事業部門ごとスピンアウトした)

海外製だと diawi もよく知られています。

(手軽にipaファイルをアップロード・共有できる)

なお弊社は両サービス共に使用したことも提案した経験もありません。この他にもあるかも知れませんので「OTA」でググってみるのも良いでしょう。ただ、OTA用のWebサーバは上述の通り条件が非常に少ないため、可能であればやはり自社構築するか、既存のhttps対応済み社内サーバを間借りするのがお勧めです。

以上、OTA(Over The Air)によるアプリのインストールについて紹介しました。更に細かな情報についてはAppleの公式情報もありますので参考にして下さい。

ADEPからADPへと誘導しているAppleの言い分は「ADEPでの台数無制限な無審査配布はもう許さないけど、ADPのAdHocなら100台限定で審査なしの配布ができるよ」ということです。

上限があっても無審査で配布できるのが都合が良い場合もあることでしょう。ただ、AdHoc配布を活用する場合に注意しておきたいのが配布可能範囲。ADEPのInHouseと同様に自社従業員だけなのでしょうか、社外の人に配布するのはどうでしょうか？

本稿では、前回投稿に続きADPの契約書を読み解いて「ADPでのAdHoc配布は誰に行えるのか？」について紹介します。

契約書では AdHoc の配布範囲について一条項割いている

Apple Developer のサイトにはADPの契約書が公開されています。PDF形式で誰でもダウンロードすることができます。

(日英の両方で提供されているがオリジナルの英文契約書に目を通すことが推奨される)

この利用許諾契約の 7.3 Distribution on Registered Devices (Ad Hoc Distribution) にAdHocでの配布可能範囲について詳細が記されています。以下に同条項の最初の一文を引用します。

7.3 Distribution on Registered Devices (Ad Hoc Distribution)
You may also distribute Your Applications for iOS, watchOS, iPadOS, and tvOS to individuals within Your company, organization, educational institution, group, or who are otherwise affiliated with You for use on a limited number of Registered Devices (as specified in the Program web portal), if Your Application has been digitally signed using Your Apple Certificate as described in this Agreement.

同条項の最初に配布対象が列挙されていますね。英文を分解して読み解くと、AdHoc アプリを distribute(配布)できる対象は Your (ADP契約主体の)、

• company (会社)
• organization (組織)
• educational institution (教育機関)
• group (グループ)

の individuals within (内部の個人)、または

• who are otherwise affiliated with You

であると明記されています。列挙された前者4項は明らかにADP契約主体に所属する従業員やスタッフを指していると解釈できますが、後者は少し広い範囲で解釈ができそうです。affiliated with をどう解釈するか、これによって配布可能先が変わってきそうですね。

affiliated with を読み解く

affiliated を英和辞典(ジーニアス英和辞典)で調べると以下のように定義されています。

[形] 提携関係にある；系列の、付属の、加盟した

また著名な英英辞典(Collins コウビルド 英英辞典)によると affiliated は以下のように解説されています。

[ADJECTIVE] If an organization is affiliated with another larger organization, it is officially connected with the larger organization or is a member of it.

また利用許諾契約書の日本語版7.3の対応箇所では以下のように記されています。

本契約の規定に従い、デベロッパは、iOS、watchOS、iPadOS、およびtvOS向けのデベロッパのアプリケーション を、デベロッパの社内、デベロッパの組織内、教育機関内、グループ内の個人、またはデベロッパと提携関係にある者に 対して、限定数量の登録デバイス(プログラムウェブポータルで指定)で使用するために配布することができるものとし ます。

この3つの情報から弊社では who are otherwise affiliated with You を、ADP主体のグループ企業や資本関係を有する企業、または販売契約等に基づく販売網構成企業と解釈しています。

これが狭すぎる解釈か広すぎる解釈かは企業によって見解が分かれるかも知れません。間違いなく言えるのは不特定な第三者は含まれないということです。なお、7.3条の続く文章にはこんな記載もあります。

You also agree to be solely responsible for determining which individuals within Your company, organization, educational institution or affiliated group should have access to and use of Your Applications and Registered Devices, and for managing such Registered Devices.

意訳すると、誰が配布先に該当するのかの判断は自己責任ですよ、というわけです。

以上、AdHoc配布が可能な範囲について言及しているADP利用許諾書の7.3条を紹介しました。

ザックリとは、身内や関係者と言えるのならAdHoc配布先としても良いのではないか、という気もします。ただ安易に判断せず、AdHoc配布を実際に行おうとするエンドユーザ企業それぞれが契約書をよく読んで判断すべきでしょう。本稿が読み解く参考になれば幸いです。

(業務用iOSアプリ開発支援プログラムの資料より)

配布可能な端末数に上限があり、しかも対象端末のUDIDを事前に調べる必要があって非常に面倒ですが、iOSアプリ黎明期(2010年頃まで)には関係者にテストして貰う手段としてよく活用されました。

それが理由かどうか分かりませんが、時折、AdHocはテスト目的の配布に限られると理解されていることがある印象です。本稿では、実際のところどうなのか、契約書やAppleの公式ページから読み解いてみたいと思います。

契約書ではどのように記されているのか

ADPもADEPも Apple Developer 内の専用ページに使用許諾契約が公開されています。

(ADPやADEPの契約をしていなくても契約書の全文は誰でも見ることができる)

プログラム使用許諾契約の欄の一番上がADPの契約書です。契約を確認する(英語)のリンクから原文PDFをダウンロードすることができます。2022年12月現在、2022年6月のWWDCの時期に更新されたバージョンが最新となっています。

このPDFを「Ad Hoc」で検索すると5件ほどヒットします。言及されているのは以下のページ。原文PDFを見ながらご覧下さい。

できることなら原文(英語)を読むべきですが、日本語版も用意されていますので読み解く参考にすると良いでしょう。日本語ではAdHocが「特別配布」と訳されています。

契約書を実際に読むと分かりますが、実はどこにもAdHoc配布がテストに限定されるべきという主旨の記述はありません。どちらかというと、テスト用途の配布についてはTestFlightが受け持つ記述になっています。
 

Appleはどんな場合に使えると言っているのか

業務用アプリの配布形式について Apple の考え方を知るのに役立つのが ADEP の公式ページです。このページの末尾で、アプリのタイプ毎に、どんな配信方法が使用できるのか教えてくれます。

(業務用アプリのユースケースには大きく3種類ある)

業務用アプリには、このように3つの選択肢が用意されていますが、それぞれどんなことが書いているか見てみましょう。AdHocについての言及はあるでしょうか。

一般向けのApp

一般消費者向けアプリとして公開することを目指す場合。こんなふうに記述されています。

AdHoc配信が採用できることが分かりますね。テスト用途であることの注意書きもありません。

特定の顧客むけのカスタムApp

いわゆる自社アプリのカスタマイズバージョンを他社に提供する場合です。

ここにもAdHoc配信が使えるという記述があり、テスト用途の縛りを感じさせる記述は見られません

自分の組織内で使用する独自App

ADEPのInHouseアプリが担ってきた位置づけのアプリです。

ここでもAdHoc配信が使えると書かれています。前後の文章を見てもやはりテスト用途に限るものでもなさそうです。

結論

AdHoc配布がテスト用途以外でも使えるのかどうか、契約書やAppleのサイトの情報を紹介しましたが、どのように結論づけることができるでしょうか。

現時点での弊社見解ですが、Appleとの契約書に用途を限定した記載が明記されていないため、またADEPに変わる配信手段を案内するページにも特段用途制約の記述が見られないため、AdHoc配布をテスト用途に限る必要はなく、その不便(UDID登録済み端末に限り100台上限)を許容できるなら、Appleの審査を避けることのできるアプリ配布手段として採用できると言って良さそうです。

この見解を踏まえてですが、ADP契約をしている弊社顧客の中には、

• 100台に満たない規模で使用する業務用アプリを AdHoc 配布で運用
• 数百台規模に配布する業務アプリはカスタムApp配信で運用

というあわせ技を採用頂いている企業様もいらっしゃいます。ADEPを持たない企業が「全業務アプリをAppleの審査にかけなければならない…」わけではなく、制約はあるものの審査なしの非公開配布ができるということですね。

以上、AdHoc配布するアプリの用途について紹介しました。ただ繰り返しますが弊社見解ですので、AdHoc配布を利用される各社におかれては、念の為に契約書を法務部門にて精査をされることをお勧めします。

また、社外の端末・ユーザにAdHoc配布しても良いのかどうかは、用途とは別次元の問題になってきますので注意して下さい。これについては次の投稿で解説したいと思います。