• AppleIDサイトから登録
• ADP/ADEPから招待して登録
• ABMで登録

前回の投稿では1つ目を解説しました。本稿では2つ目の方法について解説します。ADPやADEPに招待するメールアドレスが明らかな関係者に、「AppleIDを先に取っておいて下さいね〜」とわざわざ言わなくてもいい方法があります。

順に見てみましょう。以下目次です。

• ADP/ADEPからの登録が有用なケース
• ADP/ADEPへの招待とAppleIDを同時に済ませる手順
• おまけ : ADP/ADEPの管理画面は不安定かつコロコロ変わる

ADP/ADEPからの登録が有用なケース

業務用iOSアプリの開発では、ほぼ全ての関係者があらゆるシチュエーションで AppleID を必要とします。ザッとあげると以下の通り。

エンドユーザ視点でもデベロッパー視点でもどちらでも必須です。ADPのカスタムAppなら、エンドユーザやデベロッパーだけでなく、テストに参加するだけの関係者にも必要な場合があります。(ADEPのInHouseでアプリ開発運用しているなら、テストだけの関係者にはAppleIDは不要)

AppleID を持たずして業務用iOSアプリに関係することは不可能と言っても過言じゃありません。なので、アプリ開発プロジェクトが始まると普通は以下のように進めるわけです。

1. 関係者にはまず AppleID サイトから AppleID を登録して貰う
2. その後 ADP/ADEP で招待する

ただ最近は Apple もよく考えていて、1. をすっ飛ばしてもういきなり 2. だけで良いようにしてくれています。どういうことか。

ADP/ADEPへの招待とAppleIDを同時に済ませる手順

2024年現在、ADP/ADEPに招待されたメールアドレスが AppleID として未登録な場合、招待を受け取った側で同時に AppleID 登録までできる作りになっているのです。実際の挙動を見た方が早いので、以下に画面キャプチャ付きで紹介します。

登場人物が「招待する側」と「招待される側」と2人いることに注意して読み進めて下さい。まず招待する側です。

ADP/ADEPに招待する側

主にエンドユーザ企業が該当します。

自社ADP/ADEPのユーザとして、自社従業員や開発担当の委託先関係者を招待することになりますね。その際、相手がAppleIDの登録をしてるかどうか確認することも登録依頼もすることなく、もういきなり招待してしまうのです。

(1) App Store Connect にサインインして [ユーザとアクセス] の画面に移動します。

(ADEPでは App Store Connect 画面が無いので、Apple Developer のTOPから [ユーザ] をクリック)

(2) ユーザの一覧が表示されますので、[+] ボタンをクリックします。

(ADPの場合、誰かを招待するには Account Holder / Admin / App Manager のいずれかでなければならない)

(3) ダイアログが表示されますので、招待したい人(社内の同僚や、委託先の社外の人)の姓名・メールアドレスを入力します。

(誰が誰にどの役割と設定で招待すべきか？は本稿主旨ではないので省略)

(4) アクセス権を付与したいアプリを選択します。コンプライアンスの観点から必要最低限のアプリにしておくことが推奨されます。

(新しいアプリ開発プロジェクトが始まる時、関係者の招待より先にアプリの登録が必要になる事を意味する)

以上で招待作業は完了です。入力したメールアドレスには Apple から以下のようなメールが届くことになります。

このメール中のリンク「Accept invitation」から、ADP/ADEP の招待受託だけでなく AppleID の登録まで一度に完了するというわけです。招待される側の動きを見てみましょう。

ADP/ADEPに招待される側

上でも紹介した通り招待メールが届きますので、それを開くところからですね。

(1) 受信した招待メールのリンク「Accept invitation」をクリックします。

(2) クリックすると以下のような画面に遷移します。

招待側が入力した情報に基づき、姓名やメールアドレスはあらかじめ入力されています。その他の項目を以下の表を参考にして埋めていきます。

(3) ロボット防止の文字入力を求められますので入力し [次に進む] をクリックします。

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

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

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

(6) 入力後、以下のようにADEP/ADPの契約確認画面に遷移します。契約書を確認し、画面最下部にあるチェックボックスをONにして [同意する] をクリックします。

(AppleID公式サイトでの登録と異なるところ。AppleID登録が終われば即座にADP/ADEPの手続きに進む)

(7) 招待の受諾が完了し、以下のように Apple Developer サイトのTOP画面に遷移します。

(「今すぐ始めましょう」とあり登録が完了したことがうかがえる)

(8) 念のために「メンバーシップの詳細」をクリックして確認しておきます。画面がスクロールして以下のような表示になり、どの企業のADP/ADEPのメンバーになったのか、自分に割り当てられた役割は何なのか、を見ることができます。

(想定と異なっていれば招待してくれた担当者に問い合わせる必要がある)

以上で AppleID 登録と ADP/ADEP の招待受諾の作業が完了です。開発者なら Xcode で開発が始められるでしょうし、テスターなら TestFlight 内部テストに参加できるようになります。

なお既に AppleID に登録されている人を招待した場合は、招待される側の手順のみ変わり上記の (2)〜(5) が省略されます。

おまけ : ADP/ADEPの管理画面は不安定かつコロコロ変わる

ADP/ADEPで使うことのできる Apple Developer サイトや App Store Connect は実は結構不安定です。動作は安定してるとは言えず、不具合もままあります。ですので、以下のような表示になることがあると知っておくと慌てずにすみます。

上図は AppleID 登録時に情報を入力して [次へ進む] をクリックした直後のエラー表示例です。このような表示になっても、取り乱さず数分時間をあけてリトライしてみましょう。

また、動作が不安定なだけでなく、画面表示や遷移先などUI/UXがコロコロ変わる点も覚えておいて下さい。上記手順の (7) で最終的な遷移先を紹介しましたが以前は以下のような画面でした。

2024年現在、こんな画面はありません。社内マニュアル等が存在する場合、上図が掲載されていたりするかも知れませんが、表示が違うだけなので気にしないでおきましょう。上記手順 (8) の件を確認して間違いがなければokです。

以上、ADP/ADEP のユーザ招待から AppleID 登録も一緒に終わらせる方法を紹介しました。2024年現在、自社の ADP/ADEP に招待することが明らかな関係者に対しては本稿紹介の方法が便利です。

DMAとDSAは努力義務のような軽いものでは決してなく、EUの立派な法律であり、関係者全てに大きな影響を与えます。ややもすると対象はEU圏に限られるので特に関係ないと思いがちですが、2024年現在、日本を含む各国がDMA/DSAを模した法律を制定しようとしていることは念頭に置いておくべきです。

既に App Store Connect では両法の影響を受けた変化が見られており、EU圏外だからと無縁でいられるわけではありません。業務用iOSアプリ関係者もDMA/DSAをある程度理解しておくことは必要でしょう。

そこで、何回かに分けてDMA/DSAについてアプリ開発や運用の視点で書いてみたいと思います。本稿ではまずDMAとサイドローディング、国内の動きについて解説します。

• DMAとサイドローディング
• ADEPのInHouseアプリとは関係がない
• 日本でのサイドローディング

DMAとサイドローディング

EUは何かとルールメーカーになりたがりです。脱炭素やEVしかり、少し前にはUSBタイプC義務化もありました。ルール作りで外交や産業政策を優位に進めんとするのはEUのもはやお家芸。そんなEU圏の野心の矛先が、(事実上)非EU圏のIT企業郡に向けられたのがDMAです。

DMAは Digital Market Act の略で、EUの公式ページでは、

The Digital Markets Act is the EU’s law to make the markets in the digital sector fairer and more contestable.

と説明されています。日本語に無理やり訳すと「デジタル分野の市場をより公正で競争力のあるものにするためのEUの法律」となりますが、実は正式な名称があり「欧州議会および欧州理事会規則(EU) 2022/1925 」(英表記 : Regulation (EU) 2022/1925) と言います。原文はEU公式サイトのこちらで読むことができますので、興味ある方は見てみるといいでしょう。(EU圏言語のみで日本語の提供はありません)

DMAでは支配的地位にあるサービスを Core Platform Service、それを提供する事業者を Gatekeeper として数値基準に基づき指定することになっています。あわせて Gatekeeper と指定された事業者が守るべきルールが定められています。(事業者側はEUの委員会に反論可能)

(EU公式図。Apple が Gatekeeper と指定され、App Store が Core Platform Service とされていることが分かる)

Regulation (EU) 2022/1925 には色々と細かいことが書いてありますが、業務用iOSアプリに関係ありそうなことは Article 5-3 (第5条第3項) です。以下のような規定があります。

3. The gatekeeper shall not prevent business users from offering the same products or services to end users through third-party online intermediation services or through their own direct online sales channel at prices or conditions that are different from those offered through the online intermediation services of the gatekeeper.

補足を入れながら意訳すると

3. ゲートキーパー(Apple)は、自身のオンライン仲介サービス(AppStore)を通じて提供される価格または条件とは異なる価格または条件で、ビジネスユーザー(アプリ開発会社や個人開発者)が第三者のオンライン仲介サービスや自らのオンライン直接販売チャネルを通じて、エンドユーザーに同じ製品またはサービスを提供することを妨げてはならない。

ということ。

これが、各報道がサイドローディングと呼んでいるものの正体です。AppStore 以外の配信方法を提供しなさいという法律になっているというわけですね。もちろん、守らなければ罰金が課せられます。罰金は Regulation (EU) 2022/1925 の Article 30 (第30条) に以下のような規定があります。

1. In the non-compliance decision, the Commission may impose on a gatekeeper fines not exceeding 10 % of its total worldwide turnover in the preceding financial year where it finds that the gatekeeper, intentionally or negligently, fails to comply with:
(a) any of the obligations laid down in Articles 5, 6 and 7;

前述の第5条(Article 5)を意図的または怠慢で(intentionally or negligently) 守らないなら、ゲートキーパー(この場合はApple)は、世界総売上高(total worldwide turnover)の10%以下(not exceeding 10%)の罰金を課せられると読み解けます。更に同条第2項には、違反が繰り返されるようなら20%以下になるとも書いてあったりします。

(出典 : テレビ東京 日経ニュース プラス9 2024/4/24放送分)

各社報道でDMAの罰金は最大20%と表記されることがありますが、基本は10%以下で20%となるのは相当悪質なケースであることが原文を見ると分かります。Apple の2023年度決算総売上高は約3800億ドルですから、仮に10%であってもとんでもない金額になりますね。Apple にはDMAを理由にEU圏を捨てる選択肢はありませんし、これはもう従わざるを得ないわけです。

従来EUでは、独占的地位の乱用をする企業に対して事前的な規制法律ではなく個別事案への事後制裁という形態がとられてきました。WindowsへのMediaPlayer統合でMicrosoftへの制裁や、Android端末製造業者へのGoogle検索エンジンアプリ搭載強制でGoogleへの制裁 はよく知られた制裁例です。

(10年前のできごと。当時EUの矛先は Microsoft に向いていた)

しかし事後制裁には限界もデメリットもあります。立件のための調査に時間がかかってしまう(通常は数年単位)ほか、調査期間中はEU圏の個人や企業が不利益を被り続けてしまいます。これではいけない…とEUは事後制裁より事前規制を重視するようになり、その文脈でDMAは生まれました。

これはIT分野に限らず、金融やヘルスケア、環境や自動車業界でも同様です。個別事案が問題になってから審議するのではなく、あらかじめルールを決めて予防するわけですね。社則や校則と一緒です。

以上がざっくりとしたDMAとサイドローディングの紹介となります。

このDMAに関して何人かの方から「DMAで ADEPの InHouse アプリに何か影響はありますか？」という質問を頂いたことがあります。影響がありそうなら心の準備をしておきたい…という気持ちも分からなくはありません。では実際のところどうなのでしょうか。

ADEPのInHouseアプリとは関係がない

DMAに類する法律が日本でも制定されたら、ADEP(Apple Developer Enterprise Program)でのInHouseアプリに影響があるか？と質問を頂く事があります。

答えは、NOでしょう。

当然ですね。そもそもADEPは AppStore と無縁でいるためのものであり、直接的な影響がある筈もありませんから。ADEPとADPは独立している別物だということを過去の投稿でも紹介しました。ADEP契約下のユーザでは AppStore への入口である App Store Connect にすらアクセスできないのです。

(ADEPでサインインした Apple Developer のTOPページには、そもそも App Store Connect のメニューがない)

InHouse のアプリが動かなくなることもありませんし(ipa内の Provisioning Profile と配布用証明書の検証ロジックからして技術的にありません)、ADEPの更新ができなくなるといったものでもありません。ADEPはDMAのフォーカス外です。DMAで規制対象とされる Core Platform Service に認定されたのは App Store であり、Apple Developer (Enterprise) Program ではありません。

ADEPのInHouseアプリを使っている企業は、今後も粛々と使い続けながら、将来ADEPが廃止される可能性に備えつつ、ADPに移行する文脈においてDMAを軽く意識する程度で大丈夫でしょう。

• そろそろADEP契約更新ができなくなるかも知れない ~カスタムAppへの移行を急ぐべき理由~

さて、ADEPはある意味でサイドローディングが可能な仕組みと言えなくもありません。AppStore を迂回してるわけですから。ここで想像力を豊かにして「ADEPを全企業が使えるようにしたらokじゃないか？そうか！ADEPが再び契約できるようになるのかも知れない！」と発想してみるのはどうでしょうか。

関係者にとってはパラダイスの再来であり理屈上も悪くないアイディアですが、残念ながらその方向性は無さそうです。以前の投稿で紹介した通りですね。

• ADEPはもう取得することができないと諦めたほうが良い理由

プライバシーや個人情報が脅かされる状況に業を煮やして Apple はADEPの門戸を閉じたという経緯があります。その扉が再び開かれることはないでしょう。

高いシェアを持つOSでソフトウェアの自由な配布が可能になると何が起こるか。Windows のマルウェアやウィルスの歴史を我々は知っている筈です。Appleにしてみれば、iOSを同じ無法状態にさせるわけにはいきません。Provisioning Profile を中心としたあのややこしい仕組みは、iOSを無法状態にさせないためにあるのです。ADEPは言うなればその仕組みの抜け道です。

配布し放題のADEPの開放は余りにも安直で危険過ぎ、DMAに対する解とはなりえません。また、ADEPはそもそもにして企業用であり、申し込みには法人であることを証するDUNS番号が必要です。

ADEPは、EU圏の(個人事業主ではない)個人開発者には適用できないため Regulation (EU) 2022/1925 の Article 5-3 (第5条第3項) を満たすには不十分である、という見方もできます。

既存も新規もADEPはDMAによって何も変わりません。実際、整備されているサイドローディングに関する開発者向けドキュメントには ADEP にも InHouse にも一切言及がありません。

とはいえ、将来ADPに移行することも視野にいれるとするなら、日本ではどうなるのか？はやっぱり気になりますし把握しておいた方が良い筈です。ということで、最後に国内動向を整理しておきましょう。

日本でのサイドローディング

報道の通りですが、2024年4月26日に「スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律案」が閣議決定されました。閣法として第213回国会に提出され、本国会で審議されることとなっています。

(参議院の議案情報ページにて、第213回国会の法律案一覧最下部、提出番号62で見ることができる)

公正取引委員会は同日、同法律案の閣議決定についてのページを公開しました。

このページの内容とリンクされたPDFを見れば、日本でサイドローディングの取り扱いがどうなりそうかを理解することができます。

が、端的に言えばDMAそのまんまです。細かな違いはありますが、ほぼ踏襲しています。例えば上記の公取委ページに概要が列挙されていて、その1つ目には、

公正取引委員会は、特定ソフトウェアを提供する事業者のうち、特定ソフトウェアの種類ごとに政令で定める一定規模以上の事業を行う者を規制対象事業者として指定する（指定を受けた事業者を「指定事業者」という。）

とあり、これはDMAにあった GateKeeper(規制対象事業者) とCore Platform Service (特定ソフトウェア) そのものです。

2つ目には、

特定ソフトウェアを巡る競争上の課題に対応するため、指定事業者に対して、一定の行為の禁止（禁止事項）や、一定の措置を講ずる義務付け（遵守事項）を定める。

とあり、これもDMAで見たような内容そのままです。何を禁止されているかは、同ページからリンクの貼られたPDFファイル (別紙2)法案概要(8枚) の p.3 に明記されていて、

(報道でよく引用されている図表。どこかで見た内容…)

最上段「アプリストア間の競争制限」の欄に「他の事業者がアプリストアを提供することを妨げてはならない。」とあります。根拠とする法律案は同ページのPDF (別添)法案及び理由 に見ることができます。法律案原文の第七条です。

縦書きで普通に読みにくいので、以下にポイントだけ抜粋しました。

第七条指定事業者（基本動作ソフトウェアに係る指定を受けたものに限る。）は、その指定に係る基本動作ソフトウェアに関し、次に掲げる行為を行ってはならない。
…(略)…
一 当該基本動作ソフトウェアを通じて提供されるアプリストアについて、次に掲げる行為を行うこと。
  イ 当該基本動作ソフトウェアを通じて提供されるアプリストアを当該指定事業者（その子会社等を含む。次号において同じ。）が提供するものに限定すること。
  ロ. イに掲げるもののほか、他の事業者が当該基本動作ソフトウェアを通じてアプリストアを提供し、又はスマートフォンの利用者が当該基本動作ソフトウェアを通じて他の事業者が提供するアプリストアを利用することを妨げること。

要するに、AppStoreだけにするのは禁止、自由を認めなさいと言っています。DMAのパクリか？というぐらいDMAの第5条第3項と酷似していますね。

ちなみにこの法律案はポッと出で突然に出てきたものではなく、内閣本部の政策会議体であるデジタル市場競争本部にて2019年から議論が重ねられてきたものです。

同会議体のデジタル市場競争会議ワーキンググループのページには5年間に渡る会議の議事録が全て公開されています。練りに練った力作というわけですね。実際、数十回も会議をやっています。

議論の変遷に興味のある方は、公開されている議事録を読んでみると良いでしょう。特にApple からヒアリングを行った2023年4月4日の議事録は、関係議員・国内識者と Apple との会話が見れて読み物として普通に面白いです

(議事録の随所にある非開示コメント。特にサイドローディングの詳細への言及が秘されている感じ)

またデジタル市場競争本部そのもの活動記録はこちらから参照できます。2022年には中間報告書を作成し、パブリックコメントの募集もしていました。これは各社で報じられたのでご存じの方も多いでしょう。

(弊社もパブリックコメントを提出した)

とまぁ日本は日本で関係者が色々頑張ってきたようですね。

…で、出てきた結論がDMAのほぼマネ？と感じるのは、さすがEUといったところ。元が洗練されているのです。自分たちが世界標準になりたいEUの目論見どおりですね。日本の法律案に若干異なる点があるとすれば、罰金を国内売上20%(再発なら30%)としている点でしょうか。(別添)法案及び理由 の第十九条に記載がありますので興味ある方は見てみて下さい。

さて、この日本版DMAとも言える本法律案は今後どうなっていくのでしょうか？

本稿を執筆しているのはまさに第213回国会の会期中。本国会でこの法律案がこのまま可決されると、今後は上記公取委ページに記載のスケジュールで進みます。

2　施行期日
公布の日から起算して１年６月を超えない範囲内において政令で定める日（ただし、一部の規定を除く。）。

可決から公布までの一般的な日数を勘案して、施行は遅くとも約1年半後。おおよそ2025年末頃には日本でもサイドローディングが可能な状態になっていることでしょう。

以上、サイドローディングとDMA、そして最新の国内の動きも解説してきました。第213回国会審議に注目しておきたいものです。成立したなら(するでしょうが)、2025年末を見据えて情報収集と体制整備に取り組んでいきましょう。

次に気になるのは、「ではサイドローディングは誰でもできるのか？」「ADEPのInHouseとも違った方法で、どのように App Store 迂回して業務用iOSアプリを配信することになるのか？」とかとかですね。これについては、DMA関連で公開されたApple公式ドキュメントから読み解けることがある程度ありますので、また別の投稿で紹介したいと思います。

色んなケースがありますが、極めて稀ながら実際に遭遇するとインパクトが大きくなるのが、オフライン想定の動画視聴アプリです。具体例をあげると、従業員教育用の動画を内包する業務用アプリや、ネット環境の無い専用施設に配備するサイネージアプリ等で該当する可能性があります。

そうしたアプリがなぜカスタムAppへの移行で問題に直面にするのか、解説します。

• カスタムAppではipaファイルのサイズ上限がある
• 4GB超えの InHouse アプリは実装にも運用にもインパクト大
• 万が一の時の回避策

カスタムAppではipaファイルのサイズ上限がある

App Store Connect にアップロードする ipa ファイルは上限が4GBという制約があります。昔は2GBでしたが、2015年に緩和されて4GBになりました。

(4GBになることを伝える2015年2月のApple公式リリース)

InHouseアプリとして作っている ipa ファイルの場合、5GBでも10GBでも問題がなく上限を気にする必要はありません。4GB上限はiOSのファイルシステム上の制約なのではなく、単に App Store Connect のルールに過ぎないからです。(4GB上限をファイルシステムと結びつけるのは 32bit CPU時代の話)

さて、別の投稿で解説している通りカスタムAppは非公開の App Store アプリです。App Store Connect に ipa ファイルを登録・申請するという意味では公開アプリと何ら変わりありません。業務用だからという特別ルールや例外対応は期待できませんし、InHouseでは5GBでやっていた…と言った事情も考慮されません。

通常InHouseアプリからのカスタムApp化は、

1. ADPで専用のAppIDを作る (証明書等も必要に応じて用意)
2. XcodeでカスタムApp用のターゲットを作ってビルドし直す
3. 2で生成したカスタムApp版ipaを App Store Connect にアップロードして申請する

という流れになります。よほど変なことをしていない限り審査が少し心配なぐらいで、実装が大きく変わったり運用フローに影響を及ぼすことは余りありません。開発現場視点ではぶっちゃけ、ビルドし直しと申請が必要になるだけです。

ですが、4GBを超える ipa ファイルのままカスタムApp化をしようとすると一筋縄ではいきません。いざ申請というフェーズで、こうなります。

(ファイルが大き過ぎると怒られているメール。申請することすらできない)

上限を超えたアプリは App Store Connect に受け付けて貰えません。

ギリギリ収まるように工夫できれば当面は凌げますが、恐らく4GBを超えるべくして超えているアプリでしょうから、一時的な問題先送りに過ぎないでしょう。コンテンツが増えて将来また4GBの壁に悩まされる筈です。ではどうすれば良いのでしょうか？

4GB超えの InHouse アプリは実装にも運用にも影響大

残念ながら、作り変えるしかありません。小手先の技ではなく、コンテンツが幾ら大きくなろうともアプリサイズが大きくならない構造に転換する必要があります。

実装だけでなく、運用やインフラ、場合によっては周辺機器類までに影響が及ぶことも考えられます。まずアプリ本体は単なるビュワーとして位置づけ、大きなサイズのファイル(動画や大量のPDF等)はアプリに内蔵せずサーバに置いて、アプリ起動時にそれらをダウンロードするようにします。

この構成ならアプリ本体が4GBを超える事はまず考えられませんから、コンテンツが幾ら大きくても大丈夫…ということになります。インフラ面では専用サーバが必要になります。場合によってはコンテンツ管理システムを構築しなければならないでしょう。テスト用・本番用と2系統が必要かも知れません。

インフラやシステムの構築が大変な場合、On-Demand Resources という仕組みの活用は選択肢の一つです。On-Demand Resources はアプリサイズを小さくする為にAppleが用意してくれているデータ分離機構です。業務用iOSアプリはiOS専用であることが多いからこそ採用しうる対応策ですね。

(大きな画像・動画やデータをアプリから分離して扱える仕組みがある)

また、端末配備や運用のルールも見直しが必要になります。特にネット環境のない現場に端末を展開する場合は、事前に誰がどのようにデータをダウンロードしておくのか、有事にも備えた慎重な運用フロー再設計が必要です。

いずれにしても、既に4GB上限を超えている InHouse アプリはカスタムApp化の作業工数が予想以上に大きくなる可能性を見越しておくべきでしょう。いざADEPの契約が更新できない…となった場合、この対応を90日間で行えるか？ってことです。

• ADEP契約を更新せず放置するとInHouseアプリはどうなるのか

計画と実装・テストと現場展開を90日で完了するのは実際問題、不可能な場合が多いです。既に4GBを超える InHouse アプリは前もって動いておかれることをお勧めします。

万が一の時の回避策

万が一、カスタムApp化が間に合わなかった場合は、ADP配下のAdHoc配布を行うことで当面を乗り切ることができるかも知れません。

(AppHoc 配布は App Store Connect に関係がない。ADEPでの InHouse を代替する手段として使える )

ただ機種ごとに100台の上限があることと、動作させる端末のUDIDが必要なことには留意する必要があります。以下の投稿も参考にして下さい。

• AdHocとは何か

InHouse版が100台を超える端末で使われている場合、優先されるべき100端末にだけAdHoc配布し、カスタムApp化を急がずゆっくり対応するという方針も良いでしょう。また既存の業務用アプリで代替したり、いっそのことiOSアプリをやめてWebにする等のウルトラCな手段を検討することも考えられます。

以上、カスタムApp化する際に大きな壁にぶち当たってしまうケースを1つご紹介しました。該当する場合は是非早めに手を打つようにして下さい。

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

(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関連のテーマでプロポーザルを提出させて頂こうかと思います。

(研修資料から。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 端末数の販売増には繋がらないからです。せいぜい上記で紹介した公式ページ情報を提示される程度でしょう。

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

• そろそろADEP契約更新ができなくなるかも知れない…その後(1)
• そろそろADEP契約更新ができなくなるかも知れない…その後(2)

本稿はその続きとなりまして、2023年に新たに観測された動きを共有したいと思います。以下が目次です。

• 更新審査も2回目に突入
• InHouseアプリはADEP契約終了後から余命90日
• 今後、どうなるのか
• では、どうすべきか

それでは順に見ていきましょう。

更新審査も2回目に突入

2022年からADEP更新の審査が始まりましたので、2023年後半にもなるとADEP更新審査が2回目という企業様も増えてきて「2回目の更新も無事に終わった」という声をお聞きするようになりました。

弊社見解ですが、ADEP公式ページに記載のある条件を満たし続けてさえいれば、当面の間は更新し続けられるのではないかと思います。

(ADEPに適うかどうかの条件は公式ページに列挙されている。更新不可となる可能性はこちらの投稿を参照)

従業員が100人以上を擁する実在企業であり、ADEPを自社従業員の業務用アプリにのみ使用している。これを胸を張って言える状態なら余り恐れる事はなさそうです。毎年ドキドキはしますけどね。この状況をふまえてどう動くかには企業の性格が出ます。大きくは、

• (A) ADEP更新が拒否されたらその時に動こう
• (B) 万が一に備えて今のうちに体制を整えておこう

に二分され、Aがまだまだ多い印象ではあるものの、Bのスタンスの企業様からご相談が増え始めている状況です。備えあれば憂いなしということですね。

InHouseアプリはADEP契約終了後から余命90日

さて。以前の投稿そろそろADEP契約更新ができなくなるかも知れない…その後(2)で、こんなことを書いていました。

実のところADEP更新を拒否されて期限日から91日目以降でも、InHouseアプリは動き続けるようです。

2022年の検証では、公式ドキュメントに明記されている配布済みInHouseアプリの起動猶予期間90日間が経過してもアプリは動き続け、結果的に Provisioning Profile の有効期限まで起動することができました。もちろん追加のインストールも可能。

(iOSDC2023のトーク資料より)

つまり、ADEP契約終了日の前日に Provisiojning Profile を更新すれば、最長1年の移行猶予期間を確保できると見込めたわけです。

ですが、2023年に新たな挙動が観測されました。非情にも(?)ADEP契約終了日から90日後、「もう配布用証明書を無効化したので、InHouseアプリは以後使えなくなりますよ」という主旨のメールが届いたのです。

Appleの公式ドキュメントによると、iOSはInHouse配布のアプリ起動に際し、その配布用証明書の有効性を3日〜7日の周期で確認しています。ADEP契約終了から90日後に Apple が強制的に証明書をRevokeするため、起動時チェックで証明書の失効確認→起動不可…となってしまうわけですね。

インストール時にも証明書チェックはされますから、MDM だろうが Apple Configurator だろうが OTA だろうが、手段に関係なくインストールも失敗します。

現場では次々とInHouse配布アプリが動かなくなっていく状況になりますので、InHouseアプリの生殺与奪をAppleが完全に握っていることを象徴する挙動と言えるでしょう。ちょっと怖いですよね

今後、どうなるのか

以下にADEP(iDEP)の歴史を図示してみました。

(iOSDC2023のトーク資料より)

2020年代に入ってからは、ADEPは随分と追い込まれてきた気がします。新規は事実上NGとなり(2020)、更新の審査も加わり(2022)、90日の有効期限も発動するようになりました(2023)。

さらに、余り知られていませんが、Appleが特別な個人(例えばWWDC参加者)や企業(例えば提携パートナー)に過去に提供してきたアプリも実はApple名義のInHouseアプリで、それらも公開アプリや非表示Appに変わってきた例があります。Apple 自身も ADEP(InHouse) は不要だと態度で示しているのですよね。

そんなADEP(InHouse)にどんな未来が待ち受けているでしょうか？もちろん、Appleのみぞ知る…ですが、上記の状況を踏まえると、

• ADEPの取得が以前のようにまた容易になる
• ADEPの更新審査が以前のように不要となる

という未来の可能性は限りなく低いと考えられます。とはいえ、じゃぁ来年(2024年)以降にADEP更新できない企業が続出する…という可能性も低そうです。永遠ではないが今すぐなくなるわけでもなさそうだけど毎年少しドキっとする、といったところでしょうか。

では、どうすべきか

状況を総合的に見ると、ADEPの未来は明るくはないと考えます。

もう覚悟を決めて移行してしまって、ADP(カスタムApp)での自社業務用アプリ運用ノウハウを早期に構築されるのをお勧めしたいところです。無くなることはありませんから、InHouseよりも安住の地です。これを機に社内の業務用アプリの開発・運用体制を一斉に整理するというのもアリかも知れません。

InHouseのような自由は享受できませんが、メリットもあります。

(iOSDC2023のトーク資料より)

万が一ADEP契約が更新できない！となってからの移行期間は決して長くありません。90日間+αの期間で、

• App Store と App Store Connect を学び開発の進め方を変え
• TestFlight について学びテストのやり方を変えて
• ABMとMDMを整備して配信も完了させ
• 従業員の教育も終わらせられるか

…ということに思い巡らされても良いと思います。

ということで、ADEP(InHouse)を今も利用している、特に関係者が多い大手企業様におかれては、Sustanableな業務用アプリ運用のために次の一手の検討をお勧めします。いざその時が来た時のインパクトを認識されてる企業様であるほど、もう動きはじめておられる印象です。

以上、ADEPのその後について記しました。最後に、ADEPの更新や審査落ちに関する一連の投稿のリンクを以下に列挙しますので参考にして頂ければと思います。

• ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由
• そろそろADEP契約更新ができなくなるかも知れない 〜カスタムAppへの移行を急ぐべき理由〜
• そろそろADEP契約更新ができなくなるかも知れない…その後(1)
• そろそろADEP契約更新ができなくなるかも知れない…その後(2)
• ADEP契約を更新せず放置するとInHouseアプリはどうなるのか

また新たな動きがあれば追加で投稿しようと思います。

今年もまた登壇させて頂くことになりました。2020年から毎年講演させて頂いています。毎年6月頃にプロポーザルを提出するのですが、今年も採択頂きまして実に4年連続となりますね。運営の皆様、いつも採択頂きありがとうございます。

さて今年お話するテーマは今が旬の(?)カスタムApp化について。9月2日16:15から20分のトークを予定しています。昨年同様に今年も現地登壇です。

従来は、業務用の非公開アプリといえばADEPのInHouse配布一択だった(と思われていたというのが正しい)のですが、今、その状況が変わる過渡期にあります。2019,20年頃にはADEPの新規契約は事実上停止され、2022年には更新の審査が始まってrejectされるケースも出始めました。

(ADEPの画面。期限が切れるまでに継続を申し出てAppleの審査に合格しなければならない)

ADEPの InHouse 配布は徐々に外堀を埋められてきています。2023年にも少し動きがあり、このままADEPを使い続けるのが果たして健全なのか？と全ての InHouse 配布利用企業が問うても良いぐらいの状況になってるように感じます。

なるべく早くカスタムAppに移行するほうが良いのでは…が個人的な見解です。今回は無事にADEP更新ができたけど来年は怖いので…と既に動きだしている企業もありますね。

そうした状況をふまえ、今回のトークでは2023年に弊社が観測できたADEPの動きを紹介し、カスタムAppに移行していく際のベストプラクティス、メリット・デメリット、ハマりどころ、余り知られていない別の移行先についてご紹介する予定です。

(トーク用資料から。ADEPという「楽園」から出ていくことが神たるAppleの思し召し…という状況と言えなくもない)

ホントは20分では話しきれない程の内容があるのですが、今 InHouse 配布しているアプリに関わっておられるエンジニアの方に概要だけでも知って頂きたいと思ってます。少しでも多くの InHouse アプリが時間的&気持ち的な余裕をもって将来に備える一助となれれば良いかなと。

ということで、iOSDC Japan 2023 でのトークのお知らせでした。公式サイトには既にタイムテーブルも公開されていて、どんなトークがあるのかを見ることができます。非常に興味深いテーマばかりですので、有償イベントにはなりますが是非参加を検討してみて下さい。

そんな無償解決したお問い合わせストックの中から、シェアするのが有用と思われるものを紹介するケーススタディ企画を始めることにしました。具体的な課題や背景・ストーリーがあるほうがより分かり易い場合もあるからです。

記念すべき(?)第一回目は、古いInHouseアプリをカスタムApp化したいというご相談です。実際にはメールやビデオ会議で数回に分けてやりとりしていますが、本稿では、質問→回答、とシンプルな構成で書いてます。また、その後に解説も記しています。

• 質問 : 7,8年前のアプリをカスタムApp化したいのですが？
• 回答 : 作り直したほうが早いです。開発体制も再考の余地ありです
• 解説1 : 自社アプリのカスタマイズ版を他社提供する方法
• 解説2 : App Store アプリの開発経験を持った外注先を選ぶ

それでは質問からいってみましょう。

質問 : 7,8年前のアプリをカスタムApp化したいのですが？

Q. 当社はシステム開発事業を行っている上場企業です。7,8年前に、社内のある事業で作ったB2B向けの業務アプリを顧客のADEP(InHouse)を使って提供していたことがあります。アプリは諸般事情で提供をやめたのですが、ここに来て当該のアプリを復活させることになりました。

貴サイトを見て、業務用アプリはカスタムApp化が必要なことを知って取り組み始めたところです。開発には外部の開発会社を使っていますが、Xcodeでうまくビルドできないと言われてて進捗は良くありません。deprecated というエラーや警告が多発したり、SDK が見つからないと言われたりして、ipa ファイルが生成できないとのことです。どう進めていけば良いでしょうか？

回答 : 作り直したほうが早いです。開発体制も再考の余地ありです

A. deprecated や SDK が見つからない等の警告やエラーは、廃止されたAPIを使っていたり古いSDKを参照するソースコードで発生します。代替の実装を行う必要がありますが、軽微で済むものからインパクトの大きなものまで様々です。

App Store への申請が伴うアプリ開発では、deprecated となるAPI情報をチェックし、SDK も新しくして、継続的かつ計画的にiOS エコシステムの進化に追随していく必要があります。

(deprecated の例。上図はUIKit)

App Store と無関係でいられたADEP(InHouse)の場合は Xcode や iOS SDK を自社都合や顧客都合で固定できていたため、deprecated を意識することは余り無かったかも知れません。良い意味でも悪い意味でもやりたい放題だったというわけです。

7,8年もの間に蓄積したiOSアプリとしての「遅れ」を、ツギハギや小手先の調整で取り戻すのは困難な作業になると思われますし、実装の見直しが広範囲に及ぶ可能性も高いと推測します。残念ながら、御社は「カスタムApp を考える以前の状態」と言えるでしょう。

(Swiftの登場は2014年ですっかり定着。Android版の同時開発でもない限り昨今はSwiftがスタンダード)

当該アプリのソースコードは Objective-C のようですが、最新のXcodeを使ってSwift言語で今風に作り直す方針を推奨します。昨今ではそのほうが外注先開発会社の選択肢も増えます。また今後のビジネス持続性も考えて、App Store 向けアプリの経験がある開発会社を選ぶほうが良いでしょう。

既存ソースについて補足すると、全部捨てることが常に正解だとは限りません。基本的に捨てる方針としながら、一部流用できるビジネスロジックがある場合は Objective-C のまま当該部分を抜き出して再利用するのが賢明でしょう。とはいえ Swift と Objective-C を混在させるデメリットもありますので、そのあたりも含めて相談できる開発会社を探されると良いと思います。

解説1 : 自社アプリのカスタマイズ版を他社提供する方法

ここからは相談内容に関連する解説となります。さて、今回のご相談のように、

• 自社で開発したソースコードをビルドして
• 他社のADEP(InHouse)契約配下の証明書・秘密鍵・Provisioning Profileで署名する

というやり方は、自社開発の業務用iOSアプリを他社販売する時に行われてきました。しかし、ADEPが使えない(使えなくなっていくと思われる)今、今後はこの方式は使えない(使えない前提でビジネスを組み直さなければならない)と考えるべきです。

カスタムAppでは、

• 販売先企業毎にそれぞれアプリを作る
• 自社 ADP にカスタムAppとして個別に申請
• App Store Connect 上の配信設定で販売先企業の組織IDと組織名を指定
• 販売先企業にはABM+MDMの導入必須であることを説明

を行う必要があります。

(研修資料より。提供先企業がMDM+ABMを持っている前提でカスタマイズ版を他社向けABMに放り込む)

このことから分かるのは、業務用自社開発iOSアプリを他社提供するメーカ企業がADEP(InHouse)からの移行を目指す場合、メーカ企業自身にもABMとMDMの理解が必要になるということです。これらの理解なく、事業を営むのは今後難しくなっていくでしょう。該当する企業におかれは、以下を参照のうえ準備することをお勧めします。

• MDMとは何か 〜今さら聞けないMDMの基礎〜
• ABM(Apple Business Manager)とは何か

解説2 : App Store アプリの開発経験を持った外注先を選ぶ

本サイトで度々強調していることですがカスタムApp は App Store アプリです。そして App Store アプリには、ADEPの InHouse アプリと全く異なる、複雑で沢山のノウハウが求められます。

(App Store Connect は豊富な機能を備える。カスタムAppで必要なのは一部だけだが、それでも知るべきことは膨大)

ADEP では触れる事のなかった App Store Connect の基礎理解は必須であり、アプリ審査に関係するワークフローや審査結果に対するオペレーションも押さえる必要があります。テストの仕方もそもそも変わります(TestFlightを使用)し、前述の deprecated の対応も常に必要です。

ADEPとは比較にならない知識と経験が必要になるわけです。ipa ファイルを作って、審査もなく、本番・テストの区別なく自由にバラまけたInHouse配布のADEP時代とは全く違う世界だと認識しなければなりません。ADEPからEが取れた程度…と安易に考えてはいけません。

(アプリの詳細画面。たった1つのアプリでも、多くのタブと多数のメニュー、そして膨大な入力項目がある)

また、カスタムApp化で大きな課題になるのがiOS の API の進化に追随しなければならないという点です。

iOSは進化とともに古いAPIが使えなくなります。App Store アプリでは、この廃止予定のAPIを使っているとそもそも申請を受け付けてくれませんので、代替の実装に置き換えることをしばしば行います。

(iOS Release Noteから。上図は iOS16で UIKitの一部関数が廃止されることを示している)

開発者視点でiOS最新情報を確認できる iOS Release Note のページをチェックし、対応し続けられる開発体制かどうかは非常に重要です。App Store アプリの開発経験のない企業の場合、そもそもそういったことに慣れていない可能性があります。

「現場の iOS 端末で動けば良い」

この発想ではダメで、今後はアプリ審査に耐えうるクオリティの実装が必要です。では審査に耐えうるクオリティとは一体？…そうしたことに知見を持って対応できる、業務アプリの持続可能性を高める体制作りが必要になるのです。

そのために、App Store アプリの経験のある企業に発注する、または内製するなら経験者を雇うのは良い選択でしょう。それが適わないなら、最低限、その知見や経験を持った企業や個人に技術支援を依頼することをお勧めします。

今回はケーススタディ企画の第一弾ということで古いInHouseアプリをカスタムAppに移行したいというご相談への回答および関連解説をお届けました。他にも学びのある無償相談は沢山ありますので、また紹介したいと思います。

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種類紹介しました。諸事情や諸条件によって採れる選択肢は変わってきますが、すべての選択肢を知っておくことは有用でしょう。本投稿が、読者の関わるアプリ開発プロジェクトの開発方針決定に役立てば幸いです。

• 実録！ADEPの更新を拒否されるまでの全て (1)
• 実録！ADEPの更新を拒否されるまでの全て (2)

検索エンジンでいきなりこのページに到達された方はまず (1) (2) をご覧下さい。本稿は (2) の続きで、ADEP更新申請の3,4ページ目の質問と回答例を示し、最後に申請結果も紹介します。

• Page3 : Code Sharing and Security
• Page4 : App Testing
• 更新申請の審査結果
• ADEP更新拒否のその後

Page3 : Code Sharing and Security

3ページ目は、他のページと違って選択肢によって設問が増減し、最小5問、最大7問と幅があります。少しややこしい(特殊な)ことをやっているとより多くの説明が求められます。順に見ていきましょう。

Do you re-sign compiled apps from other developers to use within your organization? (他の開発者がビルドしたアプリを受け取って自社利用のために再署名していますか？)

iOSアプリの署名の仕組みを理解していなければ、この設問の意味は理解に苦しむと思います。多くの企業では No になる筈です。iOSアプリの署名については以下の投稿を参考にして下さい。

• iOSアプリの署名とDeveloper Programの関係

通常は、ユーザ企業自身のADEP契約配下で証明書やProvisioning Profileを作成し、それを使ってXcodeで署名した InHouse の .ipa ファイルをユーザ企業内で配布します。自社開発でも外注する場合でも基本はこのスタイルです。

が、実は .ipa ファイルは、「再署名」することでアプリの名義を変更することができるのです。

• (1) 外注先の開発企業には、その企業の ADEP や ADP 契約の証明書・Provisioning Profile を使って署名した .ipa ファイル(外注先名義)を納品して貰う
• (2) 受け取ったユーザ企業側で自社のADEP契約の証明書やProvisioning Profileを使って署名をし直した .ipa ファイル(ユーザ企業名義)を生成する
• (3) 結果、InHouse アプリとなるのでそれを社内で配布する

これが「再署名」です。ADEPのユーザアカウントに外注先の人を入れたくない、作るのが現実的でないぐらいに外注先が多い…といった場合に使われる手法です。

このような運用をしている場合、この設問には Yes と応える必要があります。そして、Yes を選ぶと現れる下図の追加入力欄に詳細を記述しなければなりません。

具体的な手順を書くと良いでしょう。弊社は該当しませんので No を選びました。

Do you act as an app development contractor for other organizations? (他組織のアプリ開発請負者として活動していますか？)

次ですね。こちらの設問も多くの場合は No になる筈です。もし自社でADEP契約をしていながら、他社アプリの受託開発をしている場合は Yes を選択して下さい。以下のような追加入力欄が現れます。

Describe your process for giving completed apps and source code to other organizations. とある通り、ipa とソースコードの納品方法について記述しましょう。

弊社の場合、過去には該当していました(ADEPを自社で持ちながら他社ADEP向けアプリを受託開発)が、今回のADEP更新時点で全てのお客様にカスタムApp(ADP)へ移行して頂いてましたので No と回答しました。

What mechanisms have you put in place to ensure your apps can only be installed by your employees and permitted users? (従業員や許可されたユーザだけがインストールできるようにするどんな仕組みを用意していますか？)

用意しているものの詳細を書きましょう。弊社は、MDMを使っていること、限られたユーザだけがMDMアクセスできること、を強調して上図のように書きました。

Who has access to the sign in credentials of the Account Holder and Enterprise App Distribution Certificates? (Account Holder とInHouseアプリ用配布証明書にアクセス権限を持っているのは誰ですか？)

Account Holder のアクセス権限をどう扱っているか書きます。また Enterprise App Distribution Certificates は、ここでは配布用(Distribution)の証明書を発行できる権限を持っている人の事を指していると考えられます。

Apple公式ドキュメントプログラムにおける役割によると「配布用証明書の作成と無効化」という権限があり、それを Account Holder 以外の Admin や App Manager にも付与できることが示されています。

(配布用証明書はADEPを特別たらしめている要(かなめ)。作成権限を持てるユーザは限られている)

もし Admin や App Manager のアカウントユーザをADEP配下で作成しているなら、それらのアカウントユーザの扱いについても記述しておきましょう。

How do you monitor and control access to your Enterprise App Distribution Certificates? (InHouseアプリ用配布証明書へのアクセスをどのように管理・制御していますか？)

ここでいう Enterprise App Distribution Certificates は InHouse 用の証明書、つまり.p12 ファイルです。厳密に言うと Certificates は .p12 ファイルの中に含まれるAppleにより署名された公開鍵のことを指していますが、.p12 ファイルをどう管理しているか問われていると考えて良いでしょう。

ADEPでの InHouse 用 .p12 ファイルは、業務用iOSアプリ開発における最重要ファイルです。開発担当者に渡す際にはアクセスコントロール可能な仕組みを使って厳密に扱う必要があるものです。普段どのように扱っているかを書きましょう。

Page4 : App Testing

4ページ目ではテストについてや、ADEPの応用的利活用について問われます。ADEP での InHouse アプリを特別な用途で使っていない限り英文記述はありません。

Do you use program resources to test apps before publishing them on the App Store? (ADEPをAppStoreでの公開前テストに使っていますか？)

審査無く無制限にアプリを配布できるのがADEPの特徴でした。その特徴を、自社内の業務用アプリのためではなく、AppStore 公開アプリや他社からの受託開発アプリの開発で社内テストに活用している場合があります。

実際に便利ですし、弊社も昔はそうしていました。テスト用途で InHouse を使用しているならこの設問は Yes です。弊社では既にTestFlightに移行していましたので No としました。

Which of the following uses of the program are necessary for your organization? (あなたの組織でADEPが必要な理由となっているのは以下のうちどの用途ですか？)

即時配信(Immediate distribution)、複数バージョンの共存(Availability of multiple app versions)、App testing outside of TestFlight(TestFlight外のアプリテスト) から該当する利用方法があればチェックを入れます。いずれも ADEP の InHouse 活用テクニックです。

3つの意味が分からない場合はチェック不要です。また、3つの選択肢以外の用途で使っている場合は Other にチェックを入れて詳細を記述しましょう。弊社の場合は、本サイトでの検証用に使っていることを書きました。(ここでアピールすれば通るかも知れないという実験)

以上の項目で最後です。お疲れさまでした。確認画面を経て最終の Submit をすると、受理されてADEP更新の申請手続きは完了となります。直後に Account Holder に以下のようなメールが届きます。

(5営業日以内とあるが、これ以上かかる場合もある模様)

更新申請の審査結果

メールでは5営業日以内とされていましたが、弊社の場合は申請の翌日に Apple から連絡がありました。結果は reject(拒否) です。

メールには、従業員100人以上の組織というADEPの契約条件を満たさないため更新は認めないと。まさに予想通りでした。これは最も分かり易い reject(拒否) 理由でしょう。

ADEPの期限日情報や、その日から90日でInHouseアプリが起動しなくなることも記載されています。その他は、ADEP期限の90日前や30日前に届いていたメールと一緒ですね。カスタムApp移行を始めとする next action の紹介文です。

reject された後、ADEP の画面は以下のようになります。

そして、実際に期限日が到来すると以下のような画面に変わります。期限日前の上図と異なり、証明書や Provisioning Profile の編集リンクが消えていることが分かります。

以前に別の投稿で紹介した通りですが、このrejectをもって「InHouseアプリが突然使えなくなるタイムリミット」に向けたカウントダウンが始まります。残り90日というわけですね。

ただ、90日後よりも前に配布済み InHouse アプリの署名に使われていた Provisioning Profile の期限切れ日が到来するなら、その日がタイムリミットになる点は注意して下さい。詳しくは以下投稿を参照して下さい。

– ADEP契約を更新せず放置するとInHouseアプリはどうなるのか

ADEP更新拒否のその後

ADEPの更新を reject されて1ヶ月すると、Apple から残り60日ですというメールが届きます。

このメールが届いた60日後には InHouse アプリは動かなくなる筈です。…が、実際にはそうならなかった例もありますので以下も参照して下さい。

• そろそろADEP契約更新ができなくなるかも知れない…その後(2)

この90日後の挙動については、改めて検証したいと思っています。結果はまたこの投稿に追記するか、別の投稿にまとめたいと思います。

ということで、ADEPの更新申請について詳細を書いてきました。ADEP更新申請に直面された方のお役に立てたら幸いです。