2023.10.16
Provisioning Profile は開発環境Macのどこに格納されているのか
以前の投稿で Provisioning Profile の確認方法について書きました。
(Provisioning Profile のファイルを Quick Look で見ている様子)
Provisioning Profile を理解するとiOSアプリ開発の全容を理解し易くなります。そして署名関係で問題がある時の原因特定もやり易くなります。とはいえ、Xcode の進化と共に署名関係の自動化がかなり進んだため、今では Provisioning Profile 単体をファイルとして認知することも随分少なくなりました。
本稿では、いざ何か調べようとした時に困らないよう、開発環境での Provisioning Profile の在りかと、コマンドラインを使った調査テクニックを紹介します。以下目次です。
場所だけ知りたいのだという方は、Provisioning Proffile の在り処 までジャンプして下さい。
Xcodeの機能強化で隠蔽化が進む
iOSが日本に上陸した2008年当初、Xcode も Apple Developer サイトも、今ほどには洗練されておらず、当時の開発関係者なら誰しもが一度は秘密鍵や証明書、Provisioning Profile に悩まされたことがあると思います。(今も悩まされているぞ😤という声も聞こえてきそうですが…)
ですが Apple は、Xcode8以降で署名関係の大きな機能強化を行ってきました。最も大きな強化ポイントが、Xcode と Apple Developer サイトの連携、そして Provisioning Profile のダウンロード機能の提供です。
(自分が所属するTeam の Provisioning Profile をダウンロードしている様子)
さらにプロジェクト設定で新たに Automatically managed signing の設定が追加され(そしてそれが推奨され)、Provisioning Profile や証明書の指定に悩まされることはほぼほぼなくなりました。
2021年には Xcode Organizer から ipa ファイル生成時の自動署名が可能となり、デバッグ用途のみならず配布用の再署名にも悩まなくてよくなっています。
(WWDC2021の動画より。署名をクラウドで行えるようになったが、使われていない案件がまだ多い印象)
またXcode9(2017年)からは Personal Team という概念が生まれ、ADP(Apple Developer Program)を未締結な個人開発者でも実機テストが可能になりました。実機転送にあたり Development 用の Provisioning Profile が必要ですが、これも開発者が意識する必要はなく Xcode が自動生成することになっています。
(ADP/ADEPの契約がなくても一定の制限付きながら実機での開発が可能になった)
以上のように Xcode は年々進化しており、署名がスムーズに進んでいる場合においては Provisioning Profile そのものをファイルとして目にすることは減ってきています。
Xcodeの進化の歴史を詳しく知りたい方は以下リンクが参考になるでしょう。
Provisioning Proffile の在り処
前置きが長くなりましたが、ここでようやく本稿の結論です。何か問題がある場合は Provisioning Profile を直接調べることが有効ですが、その Provisioning Profile は開発環境 Mac 内の
~/Library/MobileDevice/Provisioning Profiles
に全て格納されています。
(当該のフォルダをFinderでひらいた様子)
Provisioning Profile には自身を一意に識別できるようUUIDが割り当てられています。そのUUIDをファイル名とした命名規則で一式保存されているというわけですね。
Xcodeの設定画面から [Download Manual Profiles] をクリックした時や、Personal Team でビルドを行った瞬間等に、このフォルダ配下に然るべき Provisioning Profile が格納されます。
長年、色んなアプリ開発をしてきたMacOS端末であれば、以下のコマンドで相当数の Provisioning Profile の存在を確認できる筈です。是非見てみて下さい。
% find ~/Library/MobileDevice/Provisioning\ Profiles -type f -name "*.mobileprovision" /Users/user/Library/MobileDevice/Provisioning Profiles/d687b238-c65f-4a32-8647-080ca488946c.mobileprovision /Users/user/Library/MobileDevice/Provisioning Profiles/b3224ef2-1476-40a9-a141-4fae1c8da443.mobileprovision ...(略)...
1行目の find がコマンド。2行目以降は出力です。署名関係で何か問題があって、Provisioning Profile を確認したいと思ったらこのフォルダを眺めてみましょう。ただ、UUID で探すというのもなかなかヘビーです。UUIDではなく、アプリや署名の種類等に応じて Provisioning Profile を特定する必要がありますよね。
Provisioning Profile の調査テクニック
署名関係の問題が発生したら Provisioning Profile の中身を見るのが一番…と言ってもまずは特定が必要になります。どのように特定すれば良いでしょうか。
そんな時は、簡単なスクリプトを書くかターミナルでコマンドラインを駆使すると良いでしょう。問題のあるアプリの BundleID が XXXXX だとして、該当する Provisioning Profile を洗い出す場合、以下のようなワンライナーとなります。
% find ~/Library/MobileDevice/Provisioning\ Profiles \
-type f
-name "*.mobileprovision" -newermt "2023-10-01" \
-exec sh -c ' \
security cms -D -i "$1" | \
plutil -extract "Entitlements.application-identifier" raw - -o - | \
grep -q "XXXXX" && \
echo "${1##*/}" \
' _ {} \;
63133a1e-2971-4512-94f5-02cd4526487e.mobileprovision
680d33a6-adbe-4b46-a428-4b160983b9a3.mobileprovision
...(略)...
BudnleID が XXXXX のアプリの Provisioning Profile を調べている様子です。下2行と以下略の部分が出力内容ですね。Provisioning Profile のあるフォルダ配下を、newermtオプションを使って更新日付で絞り込み(2023/10/1より新しい)、対象ファイルの中身を抽出して(security cms)、BundleID文字列を抜き出し(plutil)て絞り込んでいます。
Team名称(キー名:TeamName) や TeamID(キー名:TeamIdentifier)、Xcode による自動生成(キー名:IsXcodeManaged) 等をキーにして絞り込むこともできるでしょう。
もし Provisioning Profile が多すぎて混乱する場合は、一度当該フォルダ配下を別ディスクに退避してから調査を進めるのも有用な手段です。
% mkdir -p ~/provisions && mv ~/Library/MobileDevice/Provisioning\ Profiles/*.mobileprovision ~/provisions
(ADP/ADEPにDeveloper以上の役割と適切な権限が付与されていれば、通常は削除しても再取得可能で困らない)
特定ができれば、security cms コマンドで Provisioning Profile の中身のみを標準出力して閲覧します。less コマンドにパイプして中身を眺めたり、
% security cms -D -i 63133a1e-2971-4512-94f5-02cd4526487e.mobileprovision | less
テキストファイルにリダイレクトして、
% security cms -D -i 63133a1e-2971-4512-94f5-02cd4526487e.mobileprovision > ~/provisions/63133a1e-2971-4512-94f5-02cd4526487e.plist
使い慣れたエディタで検索しながら見るのもお勧めです。
以上、Provisioning Profile の在り処と調査テクニック、Xcodeによる自動生成について紹介しました。いざ Provisioning Profile を確認しなければならなくなった時の参考として頂ければと思います。
