2022.9.5
ADEPのInHouseアプリは1年に1回必ずビルド・再署名しなければならないのは本当か？
InHouseアプリは毎年必ずリビルド・再署名・再配信する、という運用をしている開発会社やエンドユーザ企業が少なくないようです。
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ベンダーにも問い合わせるなどして一度検討してみると良いでしょう。
