各端末で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の公式情報もありますので参考にして下さい。

ただやっぱりこの先は分からないということで、予め備えておきたいと考える企業様に、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契約更新ができなくなるかも知れない…その後(1)

本稿はその続き。ADEP契約更新ができなかった現場で見られた、InHouseアプリの興味深い現象についてシェアします。

ADEPの契約終了後91日目以降もInHouseアプリは起動する

以前にADEP契約を更新せず放置するとInHouseアプリはどうなるのかという投稿で、契約終了日から90日間しか起動させられず、91日目以降は起動できなくなると書きました。

これはApple の公式ドキュメントである Switching to the Apple Developer Program にも

Your software will continue to run for 90 days after expiration.

と明記されている通りです。

しかしながら、実のところADEP更新を拒否されて期限日から91日目以降でも、InHouseアプリは動き続けるようです。この現象は、弊社がInHouseからカスタムAppへの移行をご支援したケースで、複数台のiOS端末で確認ができました。具体的には、以下のような感じです。

こいつ、動くぞ！…ではないですが、動かなくなる筈のものが動いている状況が観測されました。

その時、InHouseアプリの期限関連の状態は…

技術的に考えると、InHouseアプリを起動できなくなる仕組みは2つあります。

• (A) Provisioning Profile の期限切れ
• (B) InHouse用証明書が失効する

前者(A)については以前に以下投稿で詳細を解説しました。

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

弊社が体験したケースでは、InHouseアプリの署名時に使った Provisioning Profile の期限は2023年。ADEP期限切れから90日経過したとしても、Provisioning Profile のことだけを考えれば起動して当然です。

一方後者の(B)は、Apple公式ドキュメントにもある証明書検証に絡むものです。InHouse用の証明書を誤ってrevokeすると一斉にアプリが起動しなくなるという、あの証明書失効状態になってしまう場合。ADEP終了日90日後にAppleが当該アカウントのInHouse用証明書を強制失効する可能性ですね。

弊社で遭遇した上記アプリの場合、当該InHouseアプリの署名時に使用していた証明書でOCSP(証明書有効性を確認するプロトコル)の手動問い合わせしたところ、Cert Status: good が返ってきてInHouse用証明書の失効は確認されませんでした。

(InHouse用の証明書と中間証明書を使って openssl ocsp コマンドで調べた様子。証明書が有効であることが分かる)

ADEP契約終了から91日以上経過しても、AppleがInHouse用の証明書を強制失効していない可能性があるということです。

生成・配布済みInHouseアプリの署名時に使った Provisioning Profile の期限が切れておらず((A)は到来していない)、かつ、それに紐づく証明書の有効期限も切れていない((B)にもなっていない)なら、起動し続けて当然でしょう。

ADEP契約が拒否された場合の身構え方

紹介した振る舞いを踏まえると、万が一ADEP契約が拒否された場合の身構え方が若干変わると考えます。あくまで弊社が経験した1ケースのみを根拠にしていますが、

• 基本的にADEP契約終了日から90日以内にカスタムApp移行等の対応を完了させるべき
• だが最悪、移行完了が間に合わなくても91日目以降も InHouse アプリは動き続けるかも知れない
• 本当のデッドラインは Provisioning Profile の期限日かも知れない

と捉えておくのもアリかもしれないと感じました。

「かも知れない」を期待して(?)、最大限アプリ起動可能期間を確保すべく、ADEP契約終了直前にInHouse用の更新版Provisioning Profileを生成しておくのは良いことでしょう。ADEPの更新が拒否されて91日以上が経過しても、上記(B)をAppleが行わない限り Provisioning Profile さえあれば何とかなるからです。(と言っても最大約1年間の延命可能性を得られるに過ぎない)

Xcodeでビルドや再署名することなく Provisioning Profile を単体配布する方法については、ADEPのInHouseアプリは1年に1回必ずビルド・再署名しなければならないのは本当か？の投稿を参考にして下さい。Provisioning Profile の単体配信による「延命」はこうした時に役立ちます。

ただ、(B)が実施されるとInHouseアプリが動かなくなるのは変わらないため、結局91日目以降はビクビクしながら業務アプリを使い続けることになってしまいます。余り健全とは言えませんから、やはり拒否されたなら1日も早くInHouseから脱却することが望ましいです。

本稿では、ADEP更新が拒否されたあと実際にInHouseアプリはどうなるのか、弊社が関係した事例を紹介しました。

本サイトでは、「かも知れない」をベースに執筆することは極力避けていますが、多くの感心が寄せられていることとそもそも情報が限られていることを踏まえ、あえて投稿しました。弊社体験1例のみと、サンプルが少ない情報である点は強調しておきたいと思います。

そろそろ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の契約を拒否されたケースで見られた興味深い現象について記そうと思います。

InHouseアプリは年に1回ビルドまたは再署名が必要だ

と認識されているからなのですが、実はこの理解は誤りです。一定の条件を満たせば、InHouseアプリはビルドも再署名も不要であることは意外に知られていません。

誤った理解のまま本来不要な手間をかけているのは残念なことでしょう。本稿では、InHouseアプリの運用においてビルドも署名も不要とは一体どういうことなのか、解説したいと思います。

そもそも年に1回更新が必要なのはなぜか？

なぜ、InHouseアプリは年1で更新が必要になるのでしょうか？

それは、ADEPの Apple Developer で作成する InHouse の Provisioining Profile 期限が作成日を起点に有効期限を1年としているからです。これはアプリ関係者なら誰もが知っていることでしょう。

(Provisioning Profile をFinderのQuickLookで見た様子。1年の期限が切れた直後のもの)

ただ、Provisioining Profile の更新が必要であることは、ipa ファイルの更新が必要であることと同義ではありません。新たな .ipa ファイルが絶対毎年必要というわけではなく、アプリのロジックやリソースに変化がないのなら(Xcodeでのビルドが不要なら)、Provisioning Profile 単体の更新のみでokなのです。

ipaファイルとProvisioning Profileの関係を知る

Provisioning Profile 単体の更新だけで良い、この意味を理解するには ipa ファイルの中身を紐解く必要があります。

ipaファイルとは何でしょうか？

実は単なるzipファイルです。ipaファイルが、Windowsにおける.exeファイルに相当する実行バイナリだと誤解されていることが時々あるのですが、そうではありません。拡張子の .ipa を .zip に変更してからダブルクリックするとよく分かります。以下のように展開された中身を見ることができます。

(Windowsのexeに相当する実行ファイルは左下黒アイコン。Mach-Oというバイナリフォーマット)

PROVというアイコンで示される embedded.mobileprovision が Provisioning Profile そのものです。その他ファイルの詳細は解説しませんが、このような構造を持つzipアーカイブが、Xcodeの Organizer からエクスポートする時に作成されます。

(BundleID表示列の矢印アイコンをタップするとアーカイブ対象となったファイルの一覧が見れる)

つまり、署名時に、InHouse用の Provisioning Profile の名称は embedded.mobileprovision に変更され、コンパイルしたアプリ実行ファイルやその他ファイルと一緒にまとめてzip形式で固められ ipa ファイルとなります。これはInHouseに限らずAdHocでも同様です。

ipaファイルがiOS端末にインストールされると iOSは .ipa を展開し、中にある Provisioning Profile をファイルシステムの適切な位置に配置して検証します。また、アプリ起動の度にも参照されることとなります。

(Expiration Date という名称で期限が格納されている。security cms コマンド等で確認も可能)

Provisioning Profile 内にデータとして埋め込まれているこの有効期限が、アプリを起動しようとする時刻より前(つまり期限を過ぎている状態)だとアプリは起動に失敗します。上図の例は2023年8月16日が期限ですね。本稿執筆時は2022年ですから、期限は切れておらずアプリが起動し続けられることが分かります。

大切なのは、iOSは起動可能な有効期限チェックに際し、ipaファイルそのものを見ているのではなく Provisionig Profile を見ているという点です。ここは非常に重要ですので覚えておいて下さい。(厳密には Provisioning Profile 以外にOCSPサーバを使った証明書の有効性検証もされますが、ここでは解説しません→参考)

期限切れだけなら新しい Provisioning Profile のインストールのみで良い

アプリの起動期限チェックに使われているのは Provisioining Profile なのですから、期限延伸のみが目的なら Provisioning Proifile だけを更新すれば良いということになります。実際、MDMやApple Configuratorでは Provisioning Profile のみを単体でインストールする機能が備わっています。

Apple Configurator では、プロファイルの画面から Provisioning Profile も単体インストールができるようになっています。構成プロファイルだけではないのですね。もちろん、インストール済みの Provisionig Profile 一覧を見たり削除することも可能です。

MDM でも同様に Provisionig Profile の単体配信に対応しています。以下は弊社でよく使う BizMobile Go! の画面ですが、構成プロファイルだけでなく Provisioning Profile も選択できることが分かります。

(BizMobile Go! ではプロビジョンと表記される。他にも様々なプロファイルを登録できる)

ちなみに、下図はMDMから、ある端末にインストールされた、ある InHouse アプリ用の Provisioning Profile 一覧を示したものです。これを見れば、Provisioning Profile 単体配信の意味を理解頂けるでしょう。

1行目は .ipa ファイルと一緒にOSに取り込まれたもので、2022年4月9日に期限が切れています。このままではアプリは動かない筈ですが、次年度の Provisioning Profile を作成し、MDMから単体で配信しました。それが2行目。期限は2023年2月8日となっています。

この状態でアプリをタップすると、2つ目の Provisioning Profile の期限まで見てくれて起動成功します。ラーメンの追い麺ではありませんが、端末に対してInHouseアプリ毎に「追い Provisioining Profile」を投入できるわけですね。

なお、Provisioning Profile の追いインストールには、Apple Configurator か MDM を使う必要があります。構成プロファイル(.mobileconfig)であれば、メール添付やSafariを使ったインストールも可能ですが Provisioning Profile では同じ手法が使えません。同じプロファイルというくくりであっても、配信可能手段が異なりますので注意して下さい。

Provisioining Profile 単体インストールをうまく使う

InHouse アプリの Provisioning Profile の期限が切れると、起動時に以下のようなエラーが表示されるようになります。

(寂寥感の漂う脱力メッセージ。もうちょっと良い表現は無かったのか…)

ここに、Apple Developer で作成＆ダウンロードしてきた Provisioning Profile をインストールすると起動するようになるわけです。.ipa ファイルを差し替える必要はありません。Xcode を立ち上げることすら不要なのです。

これは、エンドユーザ企業が開発会社の関与無く自社内でInHouseアプリの更新ができることを意味します。開発会社側からすると余計な労力を割く必要がなくなることを意味します。両者にとってハッピーですね。

(ロジックやリソースが変更されていないアプリの年次更新では、新たな.ipaファイルをエクスポートする必要はない)

運用している InHouse アプリの中に、長らく機能追加も不具合修正もせず Provisioning Profile の更新しかやっていないアプリがあるでしょうか？

もしそのようなアプリが存在していて毎年 .ipa ファイルを更新しているのなら、Provisioning Profile 単体の年次配信に切り替えることを検討して下さい。.ipa ファイルをわざわざ毎年用意して配信するより Provisioning Profile のみを配信するほうが圧倒的に楽だからです。ビルド・署名が不要ですから、古いXcodeやMac環境を更新のためだけに温存しておく必要もなくなります。

なお、アプリの不具合修正があるとか、アプリ内で使うライブラリの更新が必要など、Xcodeによるビルド(いわゆるコンパイルとリンク)が必要な場合は当然 .ipa ファイルでの更新が必要となりますので注意して下さい。

本稿では、InHouse アプリ運用労力の省力化テクニックとして Provisioning Profile の単体配信を紹介しました。運用が長期に及んでいるInHouseの業務用アプリほど、ビルド・署名が不要だったりします。ご利用のMDMサービスのMDMベンダーにも問い合わせるなどして一度検討してみると良いでしょう。

• Provisioning Profile
• 証明書
• ADEP (Apple Developer Enterprise Program)

の3つの期限を正しく意識して、更新を忘れないようにする必要があります。本稿では、この3つの期限を過ぎて更新をし忘れた場合に何が起こるかを解説します。順番にみていきましょう。

Provisioning Profile の更新を忘れたらどうなるか

最もよく知られている期限は、アプリのビルド・署名時に使う Provisioning Profile の期限です。更新をせずこの期限を過ぎると、当該の Provisioning Profile に紐づくアプリが起動できなくなります。

(InHouseアプリで Provisioning Profile の期限切れは最も避けるべき事態)

Provisioning Profile の期限が切れたからと言ってアプリが消えるわけではないため、HOME画面からはパッと見で分かりにくいのが難点です。アプリが起動直後に落ちるような挙動をしたり、上図のように「もう利用できません」という悲しいダイアログが表示されたりします。

現場の端末を前にこの状況に遭遇した従業員が「Provisioning Profile の期限が切れた」と分かれば良いですが、通常それは期待できません。現場の混乱、管理部門への問い合わせ殺到は必至です。ですので Provisioning Profile の期限は、情シスはもちろんアプリを納品する開発会社やSIerも必ず意識しておきたい期限です。

Provisioning Profile の期限は、ADEPの画面で作成した時に表示されます。

また Provisioning Profile のファイルを macOS の Quicklook を使って見ることもできます。

(拡張子 .mobileprovision ファイルを選択状態にしてスペースキー)

Provisioning Profile ファイルの受け渡しが複数社間で発生する場合は、全ての受け取り手が期限を意識するようにして、二重三重の更新忘れ対策をしておくことをお勧めします。

(SpreadSheetで期限を管理。期限が迫れば段階的にSlack等にメッセージが届くようにするのもアイディアの一つ)

Provisioning Profile の更新忘れが怖い場合は、思い切って InHouse アプリの利用をやめ、カスタムAppに切り替えるのも一つの方法です。カスタムAppならAppStore公開アプリと同様に、一度インストールすれば原則起動しなくなることはないため、Provisioning Profile の更新作業から開放されます。

証明書の更新を忘れたらどうなるか

InHouseアプリのビルドや署名に必要な証明書にも期限があります。が、実は余り気にする必要はありません。証明書の有効期限は前述の Provisioning Profile の期限を超えることはないからです。

Provisioning Profile の有効期限は、その作成時に紐づける証明書の有効期限か Provisioning Profile 作成日時の1年後のいずれか短い方にされるため、Provisioning Profile より証明書が早く期限切れすることは仕様上ありません。

(Provisioning Profile の期限は証明書の期限を超えれない)

証明書にも一応期限はありますが、Provisioning Profile の期限を意識することが結果的に証明書期限を意識させることになりますので、Provisioinng Profile 期限をとにかく気にしておけば大丈夫です。

InHouseアプリ用の証明書については、有効期限が作成から3年であることのみ意識しておけば十分でしょう。

余談ですが、ときおり証明書とProvisioning Profileをセットで毎年作成しているSIerや開発会社の方がいますが、証明書の更新は3年に1度にすべきです。不要な証明書の作成は間違ったrevokeを誘発したり、外部ライブラリを使うアプリの再署名で正しくインストールできなくなる事態に陥るなど、トラブルの元ですので避けましょう。

ADEPの更新を忘れたらどうなるか

前述のProvisionProfileや証明書を作成するために必要なのがADEPの契約です。この契約にも有効期限が定められており、新規契約時・更新時から1年間です。

毎年¥37,800を支払って契約更新する必要があります。更新しなければ、ADEPの管理画面にサインインできなくなり、Provisioning Profileや証明書の作成や更新もできなくなります。

(期限切れまで1ヶ月を切ると更新を迫るwarningが表示される)

ADEPの契約更新の期限が切れると、期限終了から90日間の猶予期間を経たあと91日目からInHouseアプリが起動しなくなります。たとえ、ADEPの期限より未来の期限を持った Provisioning Profile で InHouse アプリをビルド・署名していたとしても…です。

詳しくは、Appleの公式情報や、ADEP契約を更新せず放置するとInHouseアプリはどうなるのかをご覧下さい。

ADEPの更新忘れに気がついたら「90日間も猶予があるなら後にしよう」と考えず、すぐに更新手続きを進めましょう。ADEPの更新がAppleに拒否される事例が出始めているからです。詳しくはそろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜の投稿をご覧下さい。

以上、InHouseアプリに絡む3つの期限(Provisioning Profile, 証明書, ADEP契約)が切れた時の影響について解説してきました。期限切れを理由にInHouseアプリが起動できなくなるのは

• Provisioning Profile の期限が切れた時
• ADEP の期限が切れて90日が過ぎた時

の2つの事態に至った時ということになります。これさえ避ければ大丈夫なのですが、何ごとにおいても期限切れギリギリに動き出すのは悪手です。期限切れの影響やアプリの配布環境を考慮して、更新スケジュールを定めておくようにしましょう。

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

上図はある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)

併せてご覧下さい。

一方でADEPを契約できている企業は、約4万円でADEP契約を年間更新すればInHouse配布のメリットを享受し続けることができます。

ですが、以下のような場合に InHouse アプリがどうなるかご存知でしょうか？

• ADEPの更新を忘れていた
• ADEPの更新をAppleから拒否された

現在 InHouse で業務用アプリを配布している企業、また毎年InHouseアプリをビルドして配布している企業は、知っておく必要のある仕様です。本稿では、上記の場合にInHouseアプリがどう振る舞うのかについて解説します。

即座に動かなくなる訳ではないが…

通常、ADEP契約期限が切れる30日前に Apple から以下のようなメールが届きます。

同じメールが15日前・5日前にも届きます。いずれのメールにも

Renew your membership to keep your existing apps functioning…

と、既存の配布済みアプリを使い続けたいなら更新するようにという記載があります。最初のメールから1ヶ月の猶予、直前まで合計3回も届きますので、更新せず契約期限を過ぎてしまうことは極めて稀です。

あるとすれば、担当者がすっかり忘れていたとか、社内間や業者間の連携ミスで遅れるとか、法人カード期限切れで再発行に時間がかかるとか…等の理由でしょう。

万が一、更新ができなかったらどうなるのでしょうか？

心配はいりません。ADEP契約期限日が到来してしまっても、即座にInHouseアプリが起動できなくなるわけではないからです。猶予期間があって90日間です。

ADEP契約期限が切れても、90日間はInHouseアプリを使い続けられます。言い換えると、ADEP契約期限を過ぎて91日目以降はInHouseアプリが一斉に起動しなくなるということを意味します。

ここは誤解し易いポイントですが、ADEP契約を更新しない場合、Provisioning Profile の期限より90日制限のほうが優先される点に注意しましょう。

例えば、ADEP契約が2022年6月30日に切れてしまうとします。その1ヶ月前の2022年5月31日にProvisioning Profileを生成すると、期限は1年後の2023年5月31日である筈です。

しかしADEP契約を更新しない場合、期限は Provisioning Profile による2023年5月31日ではなく、ADEP契約終了日から90日後の2022年9月28日が期限になるということです。

Provisioning Profile の有効期限まで起動できるわけではありません。Appleの 公式ドキュメントでもADEPの期限切れについて以下のように書いています。

Your software will continue to run for 90 days after expiration.

(ADEP→ADP移行を解説する公式資料に90daysと明記されている)

以上、ADEP契約を更新せずに契約終了日を迎えた時のInHouseアプリの挙動を紹介しました。端的にまとめると、

InHouseアプリは即座に起動しなくなるのではなくADEP契約終了日以降90日間は起動し続けられる

ということです。万が一ADEP更新できずに契約終了日を過ぎてしまった場合は、必ず90日以内に手を打つようにしましょう。

業務用アプリを配布する方法は、全て列挙すると実に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種を解説しました。詳細についてはそれぞれ対応する投稿がありますので併せてご覧下さい。

(iPod touch で動いていたInHouseアプリ。iOS15アップデート直後に突然起動できない状態に…)

ダイアログには「AppをこのバージョンのiOSで動作させるには、デベロッパによるアップデートが必要です。」とありますが一体何をすれば良いのでしょうか。

本稿では、このような現象に遭遇した方を対象に原因と解決策について解説します。

現象の原因

よく知られているようにiOSアプリはビルド時に署名を行います。アプリの起動時には、iOSがその署名の妥当性を検証します。問題があればそのアプリは起動させて貰えません。例えば、provisioning profile の期限が切れて起動できなくなるのが分かり易い例ですね。

(冒頭のキャプチャとは別の iPad 専用アプリ。Provisioning Profile の期限が切れたわけではない)

今回問題にしているこの現象は、iOS15がよりセキュアな署名チェックを行うようになったことの影響で、署名が妥当でないと判断されるようになってしまったことに起因します。条件が厳しくなって、今まで大丈夫だったのに急に怒られるようになったというわけです。

実は、macOS Mojave(10.14) の頃からアプリの署名が新しい形式となっていて、さらに特別な Entitlement (許可情報) が含まれるようになりました。iOS15がそれらを厳密にチェックするようになったため、

• 新しい形式で署名されていない InHouse アプリ
• 新しい形式だが適切な Entitlement を含んだ署名になっていない InHouse アプリ

である場合に本現象が発生します。

毎年新しい環境でInHouseビルドして配布している環境では問題ない筈ですが、古い InHouse アプリを Provisioning Profile の単体配信で延命利用していたり、ずっと古い macOS や Xcode を使ってビルドしているInHouseアプリなどが該当します。

対応策

やるべきことは至って簡単で、

1. macOS Big Sur 以降でビルド or 再署名する
2. 生成した InHouse の ipa ファイルを配布する

の2ステップで解決できます。

少し余談になりますが、こんな時に MDM が導入されていない現場では大変です。2.の配布を管理側のオペレーションで遠隔一発更新というわけにはいかないからですね。このようなケースでもスピーディな対応ができるように、やはりMDMは導入必須です。まだの企業は是非導入を検討して下さい。

iOS15アップデート前に確認する方法

まだ iOS14 以下で InHouse アプリを使っている場合、事前に本現象が発生するのかしないのか確認しておくことをお勧めします。

iOS15のリリース(2021/9/21)から90日間はアップデートを抑制できますが、本記事執筆時点(2021/12/13)で期限は残り1週間しかありません。2021/12/21以降は、iOSアップデート抑制の設定を配信していても各端末でiOS15へアップデートできるようになります。(参考 : iOSのアップデートができないように抑制する方法 〜前編〜)

現場が勝手に iOS15 にアップデートし始めてしまう前に、本現象に遭遇するのかを調べておきましょう。iOS15環境がなくても InHouse アプリの ipa ファイルさえあれば、以下の手順で確認することができます。

(1) まず InHouse の ipa ファイルを解凍します。 (.ipa は実質 zip 形式のアーカイブファイル)

% unzip myApp.ipa
Archive:  myApp.ipa
   creating: Payload/
   creating: Payload/myApp.app/
   creating: Payload/myApp.app/_CodeSignature/
  inflating: Payload/myApp.app/_CodeSignature/CodeResources
...(略)...

(2) Payload というディレクトリが生成され、中に [アプリ名].app というディレクトリが現れます。(Finder上ではファイルのように見える)

% ls -l Payload
total 0
drwxr-xr-x@ 43 oishi  staff  1376 12 11 19:16 myApp.app/

(3) このパスに対して codesign コマンドを以下のように実行します。

% codesign -dvvvvv Payload/myApp.app
Executable=/path/to/ipa/Payload/myApp.app/myApp
Identifier=jp.feedtailor.myApp.inhouse
Format=app bundle with Mach-O thin (arm64)
...(略)...
Executable Segment base=0
Executable Segment limit=688128
Executable Segment flags=0x1
Page size=4096
    -5=f79bb5d986cfbb60b019f8e4be46a537ae2dcdfc15c9ca56303a45e8ab8bba37
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=17891e74b11e06c57310a39c05558d7a0fdeb5c1fc5bb82d8dd76f2d0b22994c
    -2=da7932525b77ccade37b4ac72b436eae3a06271b4e75ee7858527518b317440a
CDHash=fb91e7653ec272ead220a38713a09c95455d43fe
Signature size=4755
Authority=iPhone Distribution: feedtailor Inc.
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Dec 11, 2021 19:16:28
...(略)...

表示された署名情報の中で、-7 という項目が存在していなかったり(上の例。-2から-5までは存在する)、-7 が存在していても 0000〜 となっている場合は再署名が必要です。mac OS BigSur 環境での再署名が推奨されます。逆に以下のように -7 の項目が存在している場合は、再度署名が不要で本現象には遭遇しないと判断できます。

Page size=4096
    -7=6f44c7b43a6b0f20a8126100b905005e4a527bedeb321e598c56c443e394d667
    -6=0000000000000000000000000000000000000000000000000000000000000000
    -5=f79bb5d986cfbb60b019f8e4be46a537ae2dcdfc15c9ca56303a45e8ab8bba37
    -4=0000000000000000000000000000000000000000000000000000000000000000
    -3=17891e74b11e06c57310a39c05558d7a0fdeb5c1fc5bb82d8dd76f2d0b22994c
    -2=da7932525b77ccade37b4ac72b436eae3a06271b4e75ee7858527518b317440a

本件の詳細は Apple も公式ドキュメントで解説してくれています。Using the Latest Code Signature Format のページを併せてご覧下さい。

ということで、InHouseアプリがiOS15で突然動作しなくなる現象の原因と対応策について紹介しました。

ちなみに AppStore アプリや TestFlight 配信されるアプリでは発生しません。AppStoreから各ユーザ端末に配信される前に Apple 側で適切に再署名されるからです。このことを考えてもやはり、ADEPによるInHouseアプリ運用から早く脱却し、AppStore公開アプリかカスタムAppの運用にした方が良いことが分かりますね。(参考 : ADEPはもう取得することができないと諦めたほうが良い理由)