特に ADEP の InHouse アプリから ADP のカスタムAppに移行する場合、これまで AppleID を必要としていなかった関係者にも必要になってくるため、登録方法をおさえておくのは良いことでしょう。

AppleIDは、AppleIDサイトから取得する方法しかないと思われがちですが、業務用iOSアプリの世界では以下の3種類の登録方法があります。(デスクトップPC/Macを使う前提)

• AppleID のサイトから登録する
• ADPのユーザ招待から登録する
• ABMから登録する

本稿では、1つ目AppleIDサイトからの登録について詳しく画面キャプチャ付きで解説します。スムーズに登録ができるよう注意点も記していますので、初めて登録する方だけでなく、新たに AppleID を社内整理しようとする方にも役立てて頂けるかと思います。

では順に見ていきましょう。以下が目次となります。

• 準備するものと注意点
• 詳細な登録手順

準備するものと注意点

以下のものを事前に用意しておく(決めておく)ことをお勧めします。

• 電話番号
• メールアドレス
• パスワード

それぞれについて注意事項を解説します。

電話番号

電話番号は、固定電話でも携帯電話でも構いません。携帯電話の場合には格安SIMでも問題ありませんが音声通話・SMSが使える必要があります。

業務用iOSの世界では至る所で AppleID でのサインインが必要です。SMSまたは音声通話で送られてくる6桁の確認コードを入力する2要素認証を常に求められます。

上記はSMSを指定した場合の2要素認証画面ですが、SMSと音声通話のどちらを主とするかは AppleID 登録時に決めることができます。また、一時的に音声通話で受け取りたい…といったような場合の認証時指定も可能です。(上図の「確認コードを受信していませんか？」のリンク)

固定電話を使う場合、SMS受信はできませんので基本的に音声一択です。音声通話でコードを受け取ることにした場合、Appleから電話がかかってきて音声で番号を教えてくれます。音声は日本語。2回コードを読み上げた後、通話は勝手に切れるので聞き逃さないよう注意する必要があります。

メールアドレス

AppleIDとして登録するメールアドレスを決めておきます。個人事業主の方を除いて所属会社から支給されたメールアドレスであるべきです。

後々ハマることを避けるためメールアドレスの@の前に + 記号は使わないようにして下さい。 例を挙げると tanaka+appleid@example.com といったメールアドレスはダメだということです。

主旨が異なるので本稿では詳しくは述べませんが、会社が Google Workspace の Gmail や Microsoft365 の Exchange Online 等を使っている場合、自分のメールアドレスのユーザ名部分に + を付加することで擬似的にメールアドレスを作ることができます。これを Plus Addressing と言いますが、AppleID のメールアドレスに使ってはいけません。

Plus Addressing をしたメールアドレスで登録した AppleID は ADP で招待をして貰えないからです。昔は可能でしたが、2024年現在は不可となっていますので注意して下さい。

(AppleIDに+記号が含まれているとエラーが発生してADPに招待できない。招待する側が困ることになる)

どうしてもメールアドレスが用意できない場合は、エイリアスを使うなど社内の管理者の方に相談しましょう。また ABM の管理対象AppleIDを作る方法もありますが、本稿主旨ではないため詳細は省略します。

パスワード

事前に決めておきましょう。AppleIDのパスワード仕様は、

• 8文字以上
• 英大文字と英小文字を含む
• 数字を含む

なのですが、必要最低限レベルだと以下のように登録時に警告が表示されます。

(条件を満たしているにも関わらず別のパスワードを指定するよう促される)

ここで気になって考え直すことになりますね。こうならないように、

• 12-16文字程度
• 英大文字小文字、数字、記号を全て含む
• 同じ文字や数字を連続させない
• 誕生日数字列や英単語は避ける

といった点を考慮して、あらかじめ複雑なパスワードを用意しておくと良いでしょう。

(安心して登録作業を進められる)

詳細な登録手順

さて、準備ができたところで実際の登録方法を画面キャプチャ付きで見ていきます。

(1) まず AppleID サイトをブラウザで開きます。URLは https://appleid.apple.com/。分かり易いですね。Macでなければならないとか、Safari でなければならないということはありません。Windowsも使えますしブラウザはEdgeでもokです。

(2) 画面右上の [AppleIDを作成] リンクをクリックします。

(3) 入力フォームが現れますので順に入力していきます。

各項目は以下の表を参考に入力して下さい。

(4) 最後にロボット防止の文字入力を求められます。判別しにくい場合は迷わず [新規コード] をクリックしましょう。音声を選ぶこともできます。

(5) 入力が一式終われば [次に進む] をクリックします。

(6) メールアドレス用の確認コードを入力するよう求められます。

登録したメールアドレスに以下のようなメールが届きますので、メール本文に書かれている数字をそのまま入力し [続ける] をクリックします。

(7) 続けて電話番号用の確認コードの入力を求められます。登録した電話番号にSMS/音声通話かどちらか選択した方式で確認コードが届きますので、そのまま入力します。

(ここで何度も入力をミスると一定時間次に進めなくなってしまう。確実に入力する)

(8) 入力後、以下のような画面に遷移します。

以上で AppleID 登録は完了です。お疲れ様でした。長い手順に見えますが、事前準備をしていればスムーズに登録ができた筈ですね。

なお、同じIPから大量のAppleID登録を試みようとすると、不正の可能性を疑われて登録できなくなる場合があります。読者がもしキッティング代行業者等で、オフィス内でまとめて50個や100個もAppleIDを連続取得しようとする場合は、1日10個程度に分けて少しずつ取得していくのが賢明です。(が、そもそも大量登録が必要ならABMの管理対象AppleIDが推奨されます)

ということで、3つあるAppleID登録方法のうち最もベーシックな AppleID 公式サイトから登録する方法を解説しました。AppleIDを新たに取る必要がある方の参考になれば幸いです。

(研修資料から。ADPでは特に理解すべきことが多くなり全体像をつかみにくい。ルールを作るのも大変)

特に、証明書や秘密鍵をどう管理したら良いか分からない、カスタムApp開発をどう統率したら良いか分からない等々、よく分からないのだ…という声が多いです。上図でいうと、App Store Connect にたどり着くまでの手前部分ですね。(あともう一つ言えば TestFlight の部分も)

そこで本稿では、ガイドラインやルール作りでエンドユーザ企業側が特に意識すべきポイントについて紹介します。以下が目次となります。

• なぜ業務用iOSアプリ開発の管理は難しいのか
• 証明書周りの厳密な理解がなくても開発はできる
• エンドユーザ側で最低限の開発側理解が必要

今回は主に、エンドユーザ企業様向けの内容です。順に見ていきましょう。

なぜ業務用iOSアプリ開発の管理は難しいのか

よく分からない…という状況になりがちな理由はとても簡単です。セキュリティ的観点やコンプライアンス観点で管理・ルール化したいもの、つまり証明書や秘密鍵、Provisioning Profile といったものが「開発の世界」のものであることに起因しています。

(おなじみのADPの画面。開発会社だけが分かれば良い…わけではないのが難しい)

証明書等々は、エンドユーザ企業とAppleとのADP/ADEP契約に基づいて専用サイト Apple Developer で生成するものですが、エンドユーザ企業の担当者が普段CSRや証明書といったものに接することはまずありません。Apple 特有の用語も多数ありますし、しかも基本的に英語です。

(Apple Developer にはエンドユーザ側には馴染みのない言葉が沢山。しかも英語だらけ)

従って、開発部隊が社内にない限りは何が何やら理解できない場合が多く、エンドユーザ企業だけでルールやガイドラインを作るのは極めて困難です。

例えると分かり易いのですが、分からないものを管理するのはどう考えても無理筋ですよね。

製造業を営む企業が工場の製造ガイドラインを作れるのは、素材や材料や機材やライン、品質管理や周辺の法律、それらがなぜ必要でどう機能するかを分かっているからです。エンドユーザ社内にその知識があるから、分かるからこそ、ルール作り・管理・運用ができます。

(ガイドラインの策定も運用も分かるからこそできる。Generated by Midjourney)

では、業務用iOSアプリ開発の場合はどうか。社内で分からないなら「分かる」開発会社に一任すれば良いじゃないか、あるいは、既に取引ある開発会社のどこかにルールを提案して貰えば良い…という発想になります。

しかし悩ましいのは、開発会社側もこの証明書周りについて余り理解せずにアプリ開発ができてしまっている場合が多いということです。これが、業務用iOSアプリ開発のガイドライン作成や管理を難しくさせている原因です。

証明書周りの厳密な理解がなくても開発はできる

エンドユーザ企業の期待と裏腹に、秘密鍵・CSR・証明書・Provisioning Profile のそれぞれの役割や関係性を説明できる開発会社は多くない印象です。

例えば、秘密鍵と証明書がどこでどの瞬間に使用・参照されるのか、ADEP/ADPでどう違うか、Provisioning Profile と証明書の関係性、その種類と意味、秘密鍵は漏洩するとどんなリスクがあるのか、配布用 Provisioning Profile の更新が年1で絶対必要なADEPと違いADPではなぜ必須でないのか、InHouseの証明書失効でアプリが動かなくなるのにAppStore向けではそうならないのはなぜか…等々です。

ぶっちゃけ、これらの理解がなくてもiOSアプリは開発できてしまいます。開発環境のXcodeが自動で処理してくれるからですね。

(Automatically とあり自動化できていることが分かる。昔はこのような便利な仕組みは無かった)

iOSが日本に上陸した2008年当初は、これらを理解していなければ ipa ファイルの生成すらままなりませんでしたが、Xcodeの自動処理の進化により今は随分(開発者にとっては)良くなりました。しかしそのぶんブラックボックス化されている範囲が広くなってしまったのです。

(開発環境Xcodeの付属ツール Organizer でアプリの最終出力をするところ。最新版のXcode15でブラックボックス度合いが更に上がった)

しかし、エンドユーザが管理したい証明書やProvisioning Profileは、そのブラックボックスの中で使われるモノになります。それらを作るのはエンドユーザ企業自身のADEP/ADP契約であり、何をどう作りどう管理するかをルール化したいわけですよね。

我々は分からない、あなた方も余り分かってないというのか…、となりがちです。開発プロセスで自動化・隠蔽化されていっている手順の中で使われるモノをエンドユーザが作らなくてはいけないという非常に難しい関係性にあるのです。

(権限設定に関する公式ページ。複雑なうえに、項目の意味や影響範囲を(開発会社でも)理解するのが難しい)

開発会社側からすると「とりあえず納品(申請)するのに必要だから最高の権限を下さい。あとはおまかせあれ」となりがちです。理屈としては一理ありますよね。実装して納品(申請)するのが役割なのですから。

結果、「よく分からないし、強い権限があればとりあえず開発は回せるらしいし…」ということで、

• Admin か App Manager を付与
• Certificates、Identifiers & Profiles へのアクセスの権限チェックを一通りONにする
• すべてのアプリにアクセス権

と少々乱暴に進めてしまう事になりますし、実際そうされている場合が多いでしょう。それがエンドユーザ企業側で何を意味することになるのか…を考慮せずにですね。

(App Store Connect でのユーザ登録。管理せず、とにかく開発が進めば良いならこれでok)

エンドユーザ企業が中堅・中小企業様で、委託先はこの開発会社一社だけ、ここに全部任せているのだ、という関係性なら全く問題はありません。全てを一任し管理して貰えば良いのです。全権限を渡す…で一択です。

しかし、上場企業のように大きな組織で多数の業務用アプリがあり、複数部門が複数の外部委託先に発注して開発している、業務用だけでなく一般消費者向けアプリもある…といった規模感になると、問題が起こります。

例えば、

• 委託先の開発会社a社/b社/c社の関係者全員にAdminを付与しており、エンドユーザ企業視点では誰が何をしているかどんなリスクがあるのか分からない
• 各社でやり方が違って、発注元のエンドユーザ側A部門/B部門/C部門の各部門でテストや申請のやり方も違っていて社内統制が取れてない
• D部門が新たなアプリ開発をd社に発注しようとしたら、証明書が作れないとか、秘密鍵をくれとか、テスト端末が登録できないとか言われる。既存a社/b社/c社に聞いてもそれぞれ意見が違って一体どうすれば？

とかとかですね。

こうしたことが起こらないように、また心配事を最小化できるように、正しい理解に基づいた「業務用iOSアプリの開発ガイドライン」的なものが必要になるでしょう。大きな企業であればあるほどです。

エンドユーザ側で最低限の開発側理解が必要

やはり、前述した「分からないものは管理できない」という基本原則をふまえて、自社の方針を決定するしかありません。選択肢を列挙すると以下のようになるでしょう。

• (A) 開発委託先が今後も一社のみの場合 → 全部丸投げして任せる
• (B) 開発委託先が複数社ある場合
  • (B)-1. 頑張って理解して管理する
  • (B)-2. 管理を諦める

(A)の場合は悩む必要はありません。Admin 権限を渡して全てを任せるのがお勧めです。

もし(B)の状況でガイドラインを作りたいのなら、まずは (B)-1 で進めてみることをお勧めします。その際エンドユーザ側だけで理解するのは基本的に無理がありますので、

• 自身がADPの契約をしている
• 自身のアプリも開発・公開した実績もある

の条件を満たす取引実績ある開発会社や個人の方に相談すると良いでしょう。ポイントは「他社に発注する場合でも破綻しないルール作りを手伝って欲しい」とお願いすることです。加えて、Xcode で配布用証明書や配布用 Provisioning Profile がどのように使われるのかなども教えてくれる開発会社なら、エンドユーザ側として管理イメージを描き易いのでより良いと思います。

(WWDC2021の動画より。開発側で必要になるものは2008年当初より随分変化してきた。そのあたりの知識も必要)

相談できる開発会社や個人がいない場合、Apple公式情報を参考に自力で頑張ることになります。Apple Developer サイトと App Store Connect のページに一通り目を通すのが良いでしょう。以下がリンクとなります。

• デベロッパアカウントヘルプ
• App Store Connect ヘルプ

それでもやはり難しい場合、残念ながら諦めるしかありません。やはり分からないものは管理できないからですね。

今回はエンドユーザ企業様向けに、ガイドライン策定やルール作りで大切な考え方について書いてみました。

色々御支援させて頂く中で感じるのは、ADPもADEPも社内でアプリを内製する体制を前提にした仕組みになっているように見えることです。業務用ソフトウェアを外部委託することが多い日本企業には、ピッタリハマりにくいです。つまり丸投げしにくい。委託の仕方も色々ですから、全企業で使える共通管理モデルなるものも作りにくいですしね。

では、Apple Japan の法人部門がガイドラインを作ってくれるかというと、残念ながらそれは難しいと言わざるを得ません。厳しいようですが、そうしたことは iOS 端末数の販売増には繋がらないからです。せいぜい上記で紹介した公式ページ情報を提示される程度でしょう。

ということもありますので、本サイトでは引き続き開発視点を盛り込んだ、エンドユーザ企業様向けの管理ノウハウも投稿していきたいと思っています。

自社で独自開発した業務用アプリのアイコン画像を入手できないことは稀なのですが、企業や案件によって事情は様々にあるようです。

• 開発側から高解像度の画像を貰えない、依頼しにくい
• .ipa ファイルはあるが開発会社や担当者と連絡が取れなくなってしまった
• インストール済みの端末はあるが .ipa ファイルが今手元にない

あるいは自社開発の業務用アプリではなく、AppStoreで公開されている既存アプリをABMとMDMを使って業務用に配布していて、そのアプリのアイコン画像がマニュアル用に欲しい場合もあります。

そこで本稿では、社内用マニュアルを作成される方に向けて、アイコン画像ファイルの入手方法を3つご紹介します。

• Apple Services Marketing Tools を使う
• cfgutil を使う
• ipaファイルから抽出する

Apple Services Marketing Tools を使う

もしその業務用アプリがAppStoreで公開されているアプリなら、Apple が公式に提供している App Store marketing Tools を使用するのが最良な選択です。なぜなら最も高解像度な 1024 x 1024 の画像を入手できるからです。

検索ボックスにアプリやデベロッパーの名称を入力すると下図のようにヒットしたアプリの一覧が現れます。

(appleで検索した結果。残念ながらアプリのID番号ではヒットしない)

目的のアプリをクリックするとアプリに関する様々な情報やリソースが列挙された画面に遷移します。このページ中程に下図のような「Appアイコン」というセクションがありますので、Download Artwork ボタンをクリックします。

これで、このアプリアイコンの画像を入手することができます。

ところで、アプリ開発者は AppStore に申請する際に 1024 x 1024 の高解像度画像を用意する必要があります。App Store Marketing Tools から入手できるのは、開発者が申請時に使うその画像(厳密には開発時にXcodeに登録する画像)の角を丸く切りとったもので、マニュアル等でも使い易い形になっています。

App Store Marketing Tools では、AppStoreに公開されているアプリでしか使えません。たとえ AppStore に登録されたアプリであっても、非公開アプリ(カスタムApp)の場合は検索しても出てきません。カスタムAppは企業側が非公開にしたいアプリですから、そのアイコンも入手できないのは当たり前ですね。

cfgutil を使う

もし、アプリがインストールされた端末が手元にあるなら、Apple Configurator に付属している cfgutil を使ってアプリ画像を抽出することができます。cfgutil については以下の投稿を参考にして下さい。

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

cfgutil はターミナル(いわゆる黒い画面)からコマンドラインで使いますので、難しそうに見えますがそうでもありません。以下の通り操作して下さい。

(1) 対象のアプリがインストールされたiOS端末をMacに接続し、ターミナルから cfgutil list コマンドを実行する。Macに接続されたiOS端末一覧が表示されるので、目的の端末の ECID をメモ

(2) 次に cfgutil get installedApps コマンドを実行し、目的のアプリの BundleID を調べてメモ。この時 (1) で取得した ECID を -e オプションに指定する

(3) 最後に cfgutil get-app-icon コマンドを実行し、目的のアイコン画像を抽出する。この時 (1) で取得した ECID を -e オプションに指定する

数秒待たされた後、cfgutil コマンドを実行したディレクトリ上に [BundleID].png というファイル名の画像が現れている筈です。

なお、取得できる画像の解像度は余り高くなくて 256 x 256 です。角丸処理はされていますが、グレー色の枠線のようなものもついています。少々使いにくいですが、無いよりはマシでしょう。

なおこの方法は前項の Apple Services Marketing Tools を使う方法と異なり、端末にインストールされたアプリであればどんなアプリでもアイコンの取得が可能です。AppStore公開アプリ、非表示App、カスタムApp、AdHoc・InHouse・Developmentの署名がされたアプリ、TestFlight配信アプリ…等々、どれでもokです。

アプリがインストールされた端末さえあれば使える方法ですので、アイコン画像が欲しいと思うアプリがAppStore公開アプリでなく、且つその .ipa ファイルを直接入手できないシチュエーションで有用な方法です。もし .ipa ファイルが入手できるなら、後述の方法がお勧めです。

ipaファイルから抽出する

.ipa ファイルとは何か という投稿で .ipa ファイルは単なる zip ファイルに過ぎず、展開すると様々なファイルが現れるという解説をしました。以下は代表的なものです。

この中の Assets.car というファイルから、アプリのアイコン画像を抜き出すことができることがあります。使えるツールは幾つかありますが、ここでは手っ取り早くて分かり易い Asset Catalog Tinkerer をご紹介します。以下のようなアイコンの Mac 専用ソフトです。

まず .ipa ファイルとは何かの手順にそって .ipa ファイルをzip展開して下さい。Payload フォルダ内にある Assets.cat ファイルを見つけ、Asset Catalog Tinkerer で開くと下図のように表示されます。

アプリ内で使われる画像(のうちXcodeに登録された画像)の一覧が表示されますので、この中からアプリアイコンの画像を探します。Finder上の任意箇所にドラッグ&ドロップするか、メニューから [File]→[Export Selected Images] をクリックすると画像ファイルとして抽出できます。1024 や artwork といったキーワードで検索すると見つけ易いです。

なお、Assets.cat から抽出する方法は Asset Catalog Tinkerer 以外にも acextract や iOS-Asset-Extractor などツールが幾つもありますので、確認してみて下さい。

以上、業務用アプリに関連してマニュアルを作成する方向けに、アプリアイコンを入手する方法について解説しました。マニュアル作りに役立てて貰えたらと思います。

• Apple Configurator
• TestFlight
• App Store Connect
• Apple Developer
• Apple Business Essentials

まだ日本でサービスが提供されていないので Apple Business Essentials は番外的ですが(日本提供も時間の問題と思われますが…)、残り4つは関係者であればインストールしておくことが推奨されます。

本稿では、中でも業務用iOSアプリ開発のエンジニアが日々チェックすべきアプリ Apple Developer について紹介します。

Apple Developer アプリの歴史

Apple Developer アプリは、Apple が主にエンジニアに向けて届けたい情報を発信するために提供している純正アプリです。AppStoreから無償でダウンロードできます。

(2023年3月現在、macOS用、tvOS用もある)

Apple Developer アプリの歴史を簡単に紹介します。

その昔、WWDCに現地参加するエンジニア向けの専用アプリ WWDC App なるものがありました。高額なWWDCチケット(約$1,600)を購入した開発者だけが使えるイベント用アプリで、限定的に配信されていました。

(WWDC 2014 の時の WWDC App の案内。実はAppleによる InHouse アプリだった)

これが2019年を機に、誰もがAppStoreからインストールできる Apple Developer に名称を変えます。昔は WWDC 参加者しか見れなかったセッション動画やPDF資料を、Appleが広く公開するよう方針転換した背景もあったものと思われます。

(2019年11月のニュース。この日から Apple Developer アプリとなった)

WWDCのコンテンツ以外にも開発者向けニュースやビデオ・資料も配信されるようになり、WWDCのためだけではない Apple とエンジニアを繋ぐアプリとなりました。それが2019年。

その後、UIの刷新やコンテンツ拡充が続き、エンタープライズ寄りの情報も多く配信されるようになり、今ではこのアプリ内で Apple Developer Program の新規契約・更新まで行えるようにまでなっています。

WWDC以外の豊富なコンテンツ

Apple Developer アプリには、前述した通りWWDC以外のコンテンツが豊富に揃ってます。WWDCで深堀りできなかった情報や新たな切り口でまとめたコンテンツを、動画(TechTalks)またはテキスト記事(Articles)の形式で結構頻繁に配信してくれています。

実はアプリのこの内容、Apple developer のサイトにも掲載されているものだったりします。

(AppleはWWDCの時期以外でも積極的に情報配信をしてくれている)

ですが、多くのエンジニアの方はこのサイトをWWDCの開催中や直後を除くと余り見ない…ってことになってしまっているのではないでしょうか？(かくいう筆者も豆にこのサイトをチェックするかというとそうでもありません)

また、アプリ内のBrowserタブも注目に値するコンテンツです。ここでは主に AppStore に関する最新情報を閲覧できます。

実はこれも、Apple Developer サイトのニュースフィードを取り込んでいるに過ぎませんが、これもまた業務用iOSアプリのエンジニアがチェックすべき情報です。今や業務用iOSアプリは、公開アプリ・非表示アプリ(Unlisted App)・非公開アプリ(カスタムApp)のいずれかにする必要があり、AppStoreと無関係ではいられないからですね。

(アプリ開発者がチェックしておくべきAppleからのニュース掲載サイト)

このように Apple Developer アプリはその名称の通り、Apple Developer サイトに随時掲載される情報をエンジニアがわざわざサイトを常時チェックしなくても、見逃さないよう集約して届けてくれるアプリとなってます。

開発者以外もインストールしておくことが推奨される

Apple Developer アプリでは、実は業務用の情報も豊富に配信されています。よって、エンドユーザ企業の担当者や、業務用iOSアプリを提案するSIerの担当者も Apple Developer アプリをインストールしておくと良いでしょう。

以下に Apple Developer アプリの Search タブで「enterprise」を検索した結果を紹介します。

WWDCの動画だけでなく、業務用の情報が数多く配信されていることが分かります。これらを閲覧・視聴しておくことで、より高度な業務用iOSアプリの開発やiOS端末の活用を実践できる筈ですね。

最近、個人的に興味深かったのは、業務用アプリの切り口でWWDC2022の発表をまとめ直した30分に及ぶTechTalkの動画 What’s new for enterprise developers です。

(iOS16.1から使えるようになった LiveActivities にも言及。エンタープライズの切り口でも最新情報が提供されている)

このように業務用iOS活用に関連する情報も多く配信されてきますので、「自分はコードは書かないから関係ない」と距離を置くのではなく、インストールして常にチェックするようにして下さい。Macを普段から使っているならmacOS版、AppleTVを持っているならtvOS版も使ってみると良いでしょう。

(macOS版のApple Developerアプリ。iOS版より目的とする情報にたどり着きやすい)

以上、業務用iOSアプリ関係者がインストールしておくべき Apple Developer アプリについて紹介しました。Apple の最新情報を漏れなく収集するため、普段からチェックしておかれることをお勧めします。

(Apple at Work のサイトでは管理端末として MacBook が映っていることが多い)

ということで本稿では、業務でiOS端末を導入することになった場合の管理業務用Macのお勧めチョイスと、その購入方法について紹介します。以下目次です。

• 全てのMacがiOS端末管理用途に十分すぎるスペック
• 価格と使い方で選ぶと選択肢は2つに絞り込める
• 中古のMacではダメなのか？
• Macを買わないという選択肢はあるのか？
• Macはどこで購入すべきか？

順に見ていきましょう。

全てのMacがiOS端末管理用途に十分すぎるスペック

ものすごく乱暴に書くと、2023年3月時点で Apple が公式に販売している Mac であればどんな Mac でも構いません。Mac のラインナップには、

• Mac Pro
• Mac Studio
• MacBook Pro
• MacBook Air
• Mac mini

等がありますが、いずれも端末管理の用途としては十分すぎるスペックを持っています。本サイトをご覧頂くと分かりますが、iOS端末管理用途で必要なことは、

1. MDMの操作
2. Apple Configurator の操作
3. 独自業務用アプリのビルドや再署名 (極めて稀)

ぐらいで、いずれを行うにもスペックが不足することはまずないからです。従って、スペックの心配はさておいて、価格と使い方の両軸で選択すると良いでしょう。

価格と使い方で選ぶと選択肢は2つに絞り込める

使い方とは、iOS端末管理の業務をどのように行うか…です。管理業務においてiOS端末とどのように向き合うことになるのかで選ぶべきMacが異なります。

また、前節で「今売ってるものならどんな Mac でも構いません」と書いた通りどれでも良いわけですから、価格が安いほうが良いにきまってます。というわけで、買うべき Mac は以下2通りに絞り込むことができます。

MacPro, Mac Studio, MacBook Pro は、驚くほど高額でかつ、iOS端末管理業務に使うにはオーバースペックにも程があるという水準なので、通常は選択肢には入りません。

それぞれの最低モデルの価格(税込)は2023年3月時点で以下の通りとなっています。

Apple 製CPU (Apple Silicon) の世代を選択できるようになっていますが、2023年春時点で最新のCPU(M2)にする必要はありません。Apple Silicon であるという時点で一世代前のM1であっても管理業務には超高スペックです。

(MacBook Air の購入でM1かM2かを選ぶ画面。M1でも十分高性能)

CPUを決めると次にメモリ/SSDの容量で選択肢が現れますが、いずれも変更不要です。デフォルトの最小スペックで十分です。

(いわゆるBTOができるが基本的には不要)

メモリを増設しないと Apple Configurator が快適に動作しない…なんてことはありませんので、安心して最低スペックのものを選んで下さい。また冒頭で書いた「3. 独自業務用アプリのビルドや再署名」の少し開発よりっぽい作業が必要な場合であっても十分です。

なお、価格優先で後者の Mac mini にする場合、いわゆるデスクトップ型なので、モニター・キーボード・マウスorトラックパッド等の周辺機器が必要になります。予備が社内にあるなら、それを使えば初期コストを安くできます。

(Mac mini は本体のみ。入出力装置は全て別途揃える必要がある)

iOS端末を導入後に、どのような管理業務体制となるかを考えて、ノート型にするかデスクトップ型にするかを決めましょう。BESTチョイスをあげてくれと言われれば、個人的にはノート型で最安価の M1 MacBook Air (¥134,800) です。

中古のMacではダメなのか？

ダメ…ではありませんが、オススメはしません。

Apple は Microsoft と違い、容赦なく旧ハードウェア・旧OSを切り捨てていく企業です。対応の遅い企業に配慮して InternetExplorer のサポート期間を何度も延命した Microsoft とは、根本的に思想が違う事を十分認識しておく必要があります。

Apple は古いものを使い続けることをよしとせず極力最新のものを使うことを要求します。公私ともに約20年Apple製品を使い続けている筆者の感覚的には、OSは2,3世代前まで、ハードウェアは5,6世代前までがサポート範囲です。

(2023年3月時点で最新のmacOSのサポート対象一覧。5,6年程度までがサポート範囲)

MicroSoft のほうが法人に優しい、Appleは厳しい…ということではありません。Apple が古いものを切り捨てるのはセキュリティの為です。購入したMacを長く使えるように、またセキュリティのために、管理業務用Macはなるべく新規に購入することをお勧めします。

中古Macを購入した場合には、以下のような困った事態になる可能性が高いことも覚えておくと良いでしょう。

• しばらくは中古Macで管理業務ができる
• ある年から新しいmacOSにアップデートできなくなる (最新OSの対象ハードウェアから除外される)
• 結果、新しいmacOSに対応した Apple Configuratorを使えない (Apple Configurator も古いOSを除外する)
• 結果、新しいiOS端末を適切に管理できなくなる (欲しい設定を含む構成プロファイルを作れない等)

数年前のモデルを中古で購入すれば、この状況に陥る年月が早く到来するということです。その点も考慮して本当に中古にするか検討して下さい。もし、導入しようとするiOS端末が2,3年の有期限的な用途だといった事情があるなら管理業務用Macは中古でも十分でしょう。

Macを買わないという選択肢はあるのか？

MDMでほぼ全ての管理業務を行うことができますので、Macを買わないという選択肢を完全には否定しません。有りといえば有りでしょう。

(ぶっちゃけMDMだけで管理業務はできる)

ただ Macを社内に置かないということは、管理業務でApple Configurator を使わないことを意味しますので、以下のような不自由を強いられることになります。

• 端末に流し込む構成プロファイルを作成しにくい
• 端末を監視モードに変更しにくい
• 端末をDEP(ADE)端末に変更しにくい

特に、後ろ2つの監視モードとDEP(ADE)は昨今の業務用端末では MUST な設定ですので、正直 Apple Configurator を全く使わない運用は厳しいものがあると考えます。以下も参考にして下さい。

• iOSの監視モードとは何か (Supervised Mode)
• DEP(Device Enrollment Program)とは何か
• SDE, ADP, DEP, ABM, ADE…名称がコロコロ変わる端末登録の歴史

有事の際のサポートスピードや、柔軟な対応ができるかどうかに影響を与えますので、Mac無しでのiOS端末管理業務は余りお勧めしません。円滑な管理業務はメーカ標準・メーカ推奨で揃えてこそです。また、Apple Configurator に触れることで、管理業務スキルが身につくという一面も忘れてはなりません。

結論はこうです。

iOS端末管理業務に十分精通している人が「ウチならMDMだけで十分だ」と判断できる場合を除き、iOS端末導入で初めてApple製品を導入する企業は、管理業務用のMacを必ず購入すべきです。

Macはどこで購入すべきか？

色々と選択肢が考えられますが、自社に都合の良いスタイルを選ぶと良いでしょう。以下に主だった選択肢を列挙します。

• (A) 家電量販店で購入する
• (B) Apple Store Online で購入する
• (C) Apple Store (リアル店舗) で購入する
• (D) Apple正規販売代理店(Apple VAR) に発注する
• (E) 自社専用の Apple Store Online を用意して貰って購入する

会社のルール上、現金やカード決済が難しく、買掛けの請求書払いしかできないなら (D) か (E) です。もしこちらのページに普段IT関連機器調達先としている企業があるなら、そこに依頼するのが一番手っ取り早いでしょう。

Apple と直接やりとりがしたい場合は (B) か (C) か (E) です。(C) のリアル店舗なら、各店舗に法人部門の方がいますので、店内スタッフの方に法人として購入したい旨を伝えると対応してくれます。場合によっては (E) を用意してくれたりもしますので尋ねてみると良いでしょう。ちなみに弊社は (E) です。

(弊社専用に用意して貰った Apple Store Online。ヘッダ部分に「for FEEDTAILOR INC.」と弊社名が明記されている)

また、購入ではなくリースという手段もあります。

が、一般のリース会社からのMac調達は需要と供給のバランスから高額過ぎるため推奨されません。唯一オススメできるのは、Apple Financial Service の利用です。車の残価設定付きリースのApple製品版と言えるサービスですね。

(再販価値の高いApple製品だからこそできる残価設定付きリース)

条件が厳し目ですが、国内であれば Too さんが窓口になりますのでこちらを参考に問い合わせてみると良いでしょう。

以上、管理業務用のお勧めMacについての紹介でした。iOS端末を初めて業務に導入する場合は、Macの同時購入が強く推奨されます。参考にして頂ければと思います。

(XcodeのOrganizer。どれを選んで進んでも出力されるのはipaファイル)

ipa ファイルを生成することはアプリの「開発」の終着点です。しかし同時に、アプリ「配布」(または「配備」)の世界のスタート地点でもあります。

(業務用iOSアプリの研修資料より。ipaは境界線にあるファイル)

開発(development)の世界と、配備(deployment)の世界を繋げる .ipa ファイルについて詳細を理解しておくことは、業務用iOSアプリに関係する全ての人にとって良いことでしょう。そこで、本稿では ipa ファイルを紐解き、解説します。

ipa ファイルは単なる zip ファイルである

ipa ファイルは特別なフォーマットのファイルと思われがちですが、実は単なる zip ファイルです。「アプリ」に必要なファイルを1つのフォルダに集めてzip化し拡張子を .ipa にしただけのもの、それがiOSアプリの実態です。ipa が iOS Package Archive の略であることからも分かります。

(Finder で ipa ファイルの詳細を見ると iOS Package Archive とある。zip 形式で固めた archive に過ぎない)

実際、ipa ファイルの拡張子を zip に変更してから unzip (展開)すると中身を見ることができます。以下は macOS のFinderで、あるアプリの .ipa ファイルを展開して見ている様子です。

(Windows の Explorer でも拡張子を変更してダブルクリックすれば同じものを見れる)

Macのターミナルで見るともっと分かり易いでしょうか。

(直接unzipして、Payload 配下の中身をlsで見ている様子)

中身を明らかにしたこの .ipa ファイルは、iOS上では以下のような、画面中央にラベルが1つあるだけの超シンプルなアプリです。

(iOSDC Japan 2022 のトークで Single App Mode の解説に使ったサンプルアプリ)

.ipaファイルの中身は、アプリが複雑であればあるほど肥大化していきます。UIや見た目、振る舞いが一通り実装されたアプリでは .ipa ファイルは以下のようになり、ファイルもフォルダも多くなります。

(Xcodeでプロジェクトにファイルとして追加したファイルがそのまま含まれる)

アプリによって内容はかなり異なりますが、.ipaファイルの中に共通して含まれる要素を抜き出すと、代表的なものは以下であることが分かります。

上記以外には、アプリの実装によって特別に追加されるファイルもあります。

例えば、ショートカット用の実装を含むアプリでは専用のファイルが含まれますし、(業務用アプリでは余りないと思いますが)StoreKitを使っている場合は、アプリ内課金アイテムの情報が記載されたファイルも含まれます。

ipa の中身を差し替えたり追加削除することはできない

zipファイルとして展開できるのなら、中身のデータを変更または差し替えてから、再びzip圧縮して拡張子を .ipa に戻したファイルは、iOSアプリとしてインストールできるのでしょうか？

残念ながら、できません。

.ipaファイルの中身を見るとアプリ内で使う画像やPDFファイル、そしてアプリアイコンの画像も含まれていますので、差し替えたくなる気持ちはわからなくもないです。ただ、アプリとしてまとめられていた中身を分解して変更したり差し替える行為は、立派な「改ざん」です。

iOSは、これを検出する仕組みを持っており、.ipaファイルに含まれる

• 実行バイナリ (アプリ名そのままのファイル。Mach-O形式)
• _CodeSignature

がその検出を可能とするデータを内包しています。具体的には、実行バイナリ中の署名機構に含まれる署名データ(前者)、そして署名時に計算される全ファイルのハッシュ値を収めたファイル(後者)、この2つで改ざん有無をチェックするようになっています。

(後者のファイル。実体はXML(plist)で全ファイルのハッシュ値が列挙されている)

興味のある方は、以下のAppleの公式ドキュメントが参考になりますので一読すると良いでしょう。

• TN3126: Inside Code Signing: Hashes
• About Code Signing

ということで、 .ipa ファイルの中身を何か変えたい場合は、実行バイナリ以外のリソースファイルであったとしてもXcodeからビルド or 署名を行う必要がありますので注意して下さい。

ipa の中身のデータは抜き取られる可能性がある

.ipa ファイルの構造を理解すると、業務用iOSアプリケーションではアプリ内に生のデータを含めることに神経質にならなければならないことがよく分かります。.ipa ファイルが入手されてしまうと内部データを容易に抜き取られるからです。

InHouse や AdHoc で業務用アプリを配布している場合は特に注意が必要です。メール添付での誤送信やOTA環境が誰でもアクセス可能になっている等に起因して.ipa ファイルが第三者に入手されると、大事なデータをそのまま抜き取られる可能性があります。

AppStoreの公開アプリや非表示アプリでも同様です。昨今は直接 .ipa ファイルを取得する手段は公にはありませんが、アプリをインストールしたiOS端末から .ipa ファイルとして取り出すことは比較的容易です。(特別なソフトウェアを使えば。入手も容易)

この種の心配はどこまでいってもキリがありませんのでトレードオフですが、ipa ファイルが単なる zip ファイルであることはネット上に多く情報発信されており周知の事実であることは認識しておきましょう。

(ググると幾らでも情報がでてくる。上図は「ipa 中身」で検索した結果)

従って、機密性の高い情報はXcodeのプロジェクトにそのままファイルとして登録するのではなく、

• アプリ起動後にサーバと暗号化された通信(https等)を行って取得する
• アプリ内にファイルを含めるなら特別な暗号化を施す

等の対策をしておくのが良いでしょう。

以上、.ipa ファイルの中身を紹介しました。本稿で紹介した .ipa ファイルに共通して含まれるファイルは、それぞれに技術的に面白いトピックがありますので、また別の投稿で解説してみたいと思います。

初日のキーノートでは、LockScreen刷新を含む多数のiOS16の新機能、ほぼデスクトップOS化したiPadOS16に加え、M2チップ搭載のMacBook Proなどハード的な進化も発表されました。

例年WWDCのキーノートではエンタープライズ向け機能が紹介されることはなく目立ちませんが、今回も着実な進化を遂げていました。本稿ではエンタープライズiOS関係者が、特に見ておいたほうが良いWWDC2022のセッションを3つ紹介します。

What’s new in managing Apple devices

(エンタープライズ系のセッションではお馴染みの Graham と Nadia)

最近のWWDCでは必ずエンタープライズ系の新機能をザックリ全て紹介するセッションが用意されています。2022年も同様で、本セッションは全ての関係者がチェックしておくべきでしょう。

しれっと手短に紹介された幾つかの機能が3つ印象に残りました。

まず、Apple Configurator for iPhone の新機能。iOS16からは iPhone 用の Apple Configurator を使ってDEP(ADE)端末化することができるようになります。Macとの有線接続必須だった従来に比べ劇的な作業効率向上が期待できます。

(iPhoneでかざすだけでABMに登録される)

2つ目は、MDMでのeSIM対応。ソフトウェア化されたSIMだからこそ実現できることですね。CelullarモデルのiPhoneを電源ONしてWiFiに繋ぐだけで電話回線まで有効にする…ってことが実現できます。Kittingが更に楽になります。

(キャリアとMDMが連携してeSIMを配信できるようになる)

3つ目は、ドキュメント。MDMや構成プロファイルに関する仕様が GitHub に公開されました。

仕様書という書面ではなく、YAMLで記述されていてプログラムが解釈できるようになっているのが特徴。開発部門を内部に持つ企業はMDM運用の手間を削減できる独自ツール開発ができそうです。

Discover Sign in with Apple at Work & School

ABMでは Managed AppleID という、組織が管理するAppleIDを作れます。その Managed AppleID がiOS16で Sign In With Apple (SIWA) に対応します。業務用アプリ開発会社は特に視聴すべきセッションです。

Managed AppleID は AzureAD と Google Workspace のアカウント連携に対応済みですから、SIWA対応の業務用アプリは独自のアカウント機構を持たずとも2要素認証機能を持つことができることを意味します。

(AppleIDをアカウントとして使えるSIWA。iOS15までは Managed AppleID では使えなかった)

iOSのみを対象とする業務用アプリを新規開発する場合、独自のアカウント機構は持たずSIWAの対応だけにする選択肢が検討に値することになります。

Explore Apple Business Essentials

Apple 公式のMDMである Apple Business Essentials についての紹介です。昨年発表され月額課金型のSaaSであり、ABMにビルトインされています。その詳細の紹介セッション。

ADEPによるInHouseアプリ開発ができなくなる未来が確定している中、業務用iOSアプリに関わる関係者は MDM を中心とする Deployment の知識が今後求められます。Apple 公式の MDMを知っておくことも重要ですので、本セッションはしておきたいセッションです。

(MDMとABMは基本的にセットで必要になるので、ABMに統合されたMDMであることは最大の強み)

Apple Business Essentials は2022年現在、米国の中小企業のみが契約できます。が、過去にVPP(Volume Purchase Program) や DEP(Device Enrollment Program。現在はADEと称する) がそうであったように、日本でも使えるようになるのは時間の問題でしょう。

以上、エンタープライズiOS関連のWWDC2022セッション3選をご紹介しました。他にも、セキュリティ関係で Discover Managed Device Attestation のセッション、MDM関連では [Adopt declarative device management](https://developer.apple.com/videos/play/wwdc2022/10046/) 等のセッションもありますので、興味ある方はあわせて視聴してみると良いでしょう。

(黎明期に見られるエンタープライズ機能の進化を紹介する2015年実施の弊社セミナー資料)

今でもメジャー・マイナーのアップデートに関わらず、エンタープライズ機能はアップデートの度に追加・修正され何かしら進化し続けています。その進化の全貌をみる方法はこれまでありませんでした。AppleのプレスリリースやApple Developer 登録者に送られてくる案内、WWDCの各セッションから断片的に知るしか無かったのです。

ご承知のとおり、リリース前の最新iOSを試す方法は色々と用意されています。

• 開発者として Apple Developer Program に参加する
• ユーザとして Apple Beta Software Program に参加する
• 情シス担当者として AppleSeed for IT に参加する

が、業務用iOS端末やアプリの運用観点では期待する網羅的な情報は得られません。業務用iOSに関わるものとしては、iOSがアップデートの度に エンタープライズ機能の何が変わったのか を一覧で知りたいわけです。

という前ふりで、実はありますよ、というのが本稿です。ご紹介したいのが以下のページ。

(更新履歴が事細かにアップデートの度に追記されていく)

まさに求めているページタイトルですね。エンタープライズ機能の何が変わったかを確実に知りたい場合は、このページをブックマークしておき、定期チェックしておくと良いでしょう。

実はiOS14の頃から、Appleはエンタープライズ機能に特化したバージョン毎の更新情報ページを設けるようになりました。現在はiOS14,15,16の業務用機能の各アップデートの詳細を一覧で見ることができます。(iOS13以前はありません)

• iOS 16 のエンタープライズ向けの新機能
• iOS 15 のエンタープライズ向けの新機能
• iOS 14 のエンタープライズ向けの新機能

眺めるだけで、不具合修正が思ったより結構あったり、構成プロファイルで制限できる機能がちょいちょい追加されている様子を見れて興味深いです。新しい発見も多い筈ですので是非一度目を通してみて下さい。

ちなみにこれらを集約したリンク集のようなページは提供されていませんので、新しいメジャーバージョンがリリースされる度に「iOS XX のエンタープライズ向けの新機能」と XX にバージョン番号を入れてググられるのが良いでしょう。

なお、一般消費者向けの情報も含むアップデート情報は昔からあります。メジャーバージョン毎に専用ページが用意されていますので、参考までに以下に一覧しておきます。(iOS4以前はありません)

• iOS 16 のアップデートについて
• iOS 15 のアップデートについて
• iOS 14 のアップデートについて
• iOS 13 のアップデートについて
• iOS 12 のアップデートについて
• iOS 11 のアップデートについて
• iOS 10 のアップデートについて
• iOS 9 のアップデートについて
• iOS 8 のアップデートについて
• iOS 7 のアップデートについて
• iOS 6 のアップデートについて
• iOS 5 のアップデートについて

また、アプリ開発者であれば各バージョンの Release Notes も参考になるでしょう。Apple はここ最近ドキュメントの整備を進めており非常に見易くなっていますのでお勧めです。開発・実装の観点で変更点を俯瞰できます。

(Apple Developer Program の契約が無くても誰でも見れる。ただしiOS12以降のみ)

ということで、本稿ではエンタープライズ向けの新機能を網羅的に見る方法について紹介しました。業務用iOSアプリに関係する方は常にチェックしておくようにしましょう。

おかげさまで業界関係各位の間で参考資料として当サイトの投稿をシェア頂いたり、エンタープライズiOSについて学ぶ入り口として推奨して頂ける例も出てきました。

https://t.co/BxpGju9vrt

iOS カスタムAppの一番わかりやすいまとめ。

— 佐藤伸彦 (@syobon_san) December 20, 2021

そのほか、初めてお会いした方に「あのサイトの…」とおっしゃって頂くことも増えてきています。日頃のご愛顧に御礼申し上げます。

さて今年最後となる本投稿では、この1年で最も読まれた投稿の紹介と、来年の方針を記したいと思います。

2021年で最も読まれた記事

年始の12ヶ月間PV数上位5つの投稿を以下に示します。

• (1) ABM(Apple Business Manager)とは何か
• (2) MDMとは何か 〜今さら聞けないMDMの基礎〜
• (3) ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由
• (4) Apple Configurator2 とは
• (5) ADEP (Apple Developer Enterprise Program) とは何か

基本的な用語解説の投稿にPVが集中しており、まだまだ業務用端末の管理方法や配備方法についての情報が求められていることが分かります。

特に1番目のABM(Apple Business Manager)とは何かのPV数は本サイト全体を見ても突出しており、まだABMを導入できていない企業、ABMを使いこなせていない企業が相当数いらっしゃることが推測されます。まだまだ情報発信が必要だなと感じます。

本サイトでの記事投稿を含めて、昨年/一昨年でiOSDCに登壇したような形式も出来ることなら継続し、来年も色んな形で多くの方にエンタープライズiOSの情報をお届けしたいと思っています。

2022年のサイト方針

本年同様、用語や機能の解説投稿を行っていくつもりです。週1ペースで書けば年内でネタは尽きると考えていましたが、全くそんなことはありませんでした。それだけエンタープライズiOSの世界は奥深いということでしょう。

そもそもABMやMDMの深堀りは十分にできていませんし、Guuided Access や Single App Mode には言及すらできていません。これらを含め、他の用語や機能についても順次解説していく予定です。

加えて、来年は新しい試みも考えています。

もう少し現場の課題解決に貢献できればという考えから、どんなテーマの解説が欲しいかリクエストを受け付けたり、質問と回答を投稿する前提で「こんな場合は何を使えば良い？」といった質問も受け付けてみようと思っています。

(WWDC2020の講演では実顧客を想定して解説したが、具体的で分かり易かったとの声が多く頂いた)

こういうことがしたいならこれをこう使う…のような逆引き集ができると良いですね。折を見て受付フォームなどを設置してご案内したいと思います。

また、体系的にエンタープライズiOSを理解できるコンテンツの開発も予定しています。実は問い合わせを頂く際に「アプリ開発は分かるけど業務用アプリの配布方法がよくわからないので一通り教えて欲しい」という声は意外に多かったりします。

現在、そんな声にお応えするための方法や手段を検討しています。どんな形になるか未定ですが開発時間確保のため2022年は投稿頻度が落ちる見込みです。(本年比50%程度?)

以上、2021年のPV数ベスト5投稿の紹介と、来年の方針について書きました。2022年もエンタープライズiOS研究所サイトをよろしくお願い致します。

(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はもう取得することができないと諦めたほうが良い理由)