(研修資料より)

カスタムAppの開発シーンでは、主に内部テストを使います。

一方で外部テストは、動作確認だけお願いしたいなぁというライトな関係者、つまり開発会社やエンドユーザ企業のアプリ担当者ではないけどテストだけは…という場合に活用できます。(一般消費者向けアプリではベータテスターを募集して使って貰う…的な用途に使用しますね)

この外部テスト、AppleIDとして登録されたメールアドレスさえあればokなため超お手軽で便利なのですが、余り知られていないちょっとした罠があります。本稿はそんな外部テストの罠について紹介します。順に見ていきましょう。

• Xcodeリリース版以外でビルドしたipaは配布できない
• 外部テストの「壁」を意識する

Xcodeリリース版以外でビルドしたipaは配布できない

開発現場によっては、毎年9月頃に発生するかも知れない現象が以下のようなものです。外部グループのテスターに向けてTestFlight配信しようとする時に表示されるエラーです。

(ADEPからカスタムAppに移行して、少し慣れてきた頃に発生するかも知れない)

自動配信をONにしていないテストグループにはアプリのTestFlightタブから明示的にTestFlight向け配信操作を行いますが、登録されているビルド(ipa)がベータ版Xcodeで生成されていた場合、配信先に外部グループを指定できません。上図のようなエラーが出てしまいます。

ipaの中にはXcodeのビルド情報が含まれているため、その情報で判断しているものと思われます。ベータ版に限らずリリース候補版(RC版)でも同じです。リリース版のXcodeでビルドされていない限り、外部テスト配布はできません。

上図のようなエラーが表示されたら、リリース版のXcodeに切り替えてビルドし直して再度アップロードしましょう。最新のXcodeを使っていこうという姿勢は基本的に推奨されるべきものですが、不特定多数(上限1万人)に配布するにはまだ気が早いということなのだと思います。

(リリース版が出るまで待つか、待てないなら前バージョンのリリース版Xcodeを使う)

外部テストの「壁」を意識する

Appleには、不特定多数に無制限にアプリを配布されたくないという強い意思があります。

App Store を原則必須としていることも、証明書やプロビジョニングプロファイル等のややこしい仕組みを強いていることも全部そのためです。自由なアプリ開発と配布を許容した為にセキュリティインシデントを多発させてきたWindowsとは対照的です。

TestFlightの外部テストは上限が10000ユーザで、受け取り手に必要なのはAppleIDだけなので、不特定多数にアプリ配布するのに結構近いと言えなくもありません。なので、悪用されないよう、外部テストには何かと制限や制約がついて回ります。本稿で紹介した制限も含めて例えば、

• 内部テストを実施していない状態で外部テストはできない
• ベータ版/RC版のXcodeでビルドしたipaファイルは配布できない
• (本審査ほど厳しくはないが)一応審査がある

等々ですね。

(外部テストの配信をする画面。「審査へ提出」とある)

小規模な業務用アプリであればTestFlight外部テストを使うこともないかも知れませんが、内部テストのように自由にはいかないことを意識しておくと良いでしょう。

以上、Xcodeベータ版/RC版を使用している時の注意事項を紹介しました。何かの参考になれば幸いです。

このような表示を受けて本ページにたどり着いた方もいらっしゃるかも知れません。まずは、警告の意味や背景について知っておくことをお勧めします。最初に前編の投稿をご覧下さい。

後編の本稿では、DSA(デジタルサービス法)のコンプライアンス要件の入力方法について画面キャプチャつきで1つ1つ紹介していきます。(法人を前提にしており、個人開発者の方は想定していません)

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

• 準備
• 手続き
• アプリごとの個別設定について

準備

スムーズに要件入力の作業を終わらせるため、以下をあらかじめ確認・用意しておくことをお勧めします。

1. EU圏向けアプリ配信をどうするかの意思決定
2. 履歴事項全部証明書をPDF化したもの
3. 履歴事項全部証明書の記載情報がDUNS情報と一致しているかの確認
4. 有効な電話番号とメールアドレス

順に解説します。

1. EU圏向けアプリ配信をどうするかの意思決定

あらかじめ会社としてEU圏向けにアプリをどう扱うか決定しておく必要があります。手続き最初のステップで以下選択を迫られるからです。

トレーダーとはDSAの法律原文で使われている用語で、それに該当するかどうかを尋ねられています。読者がエンドユーザ企業なら自社がトレーダーなのか、あるいは読者が顧客のために管理支援をしているようなSIer企業ならお客様がトレーダーなのか、を宣言することになります。

自社やお客様はトレーダーなのか？そうでないのか？…厳密な意味を解する必要があるでしょう。前回の投稿でもDSA原文を紹介しましたが、その第3条に定義が書いてあります。

‘trader’ means any natural person, or any legal person irrespective of whether it is privately or publicly owned, who is acting, including through any person acting in his or her name or on his or her behalf, for purposes relating to his or her trade, business, craft or profession;

ざっくり意訳すると、個人か法人であり、自己の名において、自己の事業に関連する目的で行動するものです。どうでしょうか？DSAはEU圏を対象とする文脈ですから、EU圏は全くやらない…という企業でない限りはトレーダーに該当すると解釈するのが無難でしょう。

Appleの公式文書にも「トレーダーに該当するかの判断」というセクションがありますので参考にして下さい。また、上で引用したDSAの第3条を自社としてどのように解釈するか、自社法務部門に判断を仰ぐのも良いと思います。

一方で、EU圏向けアプリ配信の予定が無いならノントレーダーを選んで作業完了です。お疲れさまでした。以降の準備も手続きも全く不要です。

…ですが、将来どうなるかは分かりませんので、法人はトレーダー登録しておくのが良いと思います。EU圏に向けてやっぱりアプリの配信をしたい…となるかも知れませんしね。

またトレーダーとして登録しておけば、「特定アプリだけノントレーダーとして申告する」といったアプリ単位の制御も可能です(後述)ので、ひとまずはトレーダーとして登録するのがお勧めです。

2. 履歴事項全部証明書をPDF化したもの

1.でトレーダーを選択する場合、自社を証明する書面の提出が必要です。国内法人は履歴事項全部証明書が良いでしょう。

書面提出はAppleが勝手に決めていることではなく、DSAの第30条第1項で求められているものです。法律で決まっているのですから、EU圏にアプリ配信する以上は従わなくてはなりません。

ということで、履歴事項全部証明書のPDFを用意して下さい。特に明記は無いですが、法人の各種手続に沿って直近3ヶ月以内のものが良いと思います。未取得なら法務局で取得するところからですね。

最近は法務局も頑張っていてオンライン申請もできます。これを機に活用されると良いでしょう。

3. 履歴事項全部証明書の記載情報がDUNS情報と一致しているかの確認

手続きの途中で所在地や電話番号、メールアドレスを申告する画面が現れます。が、所在地情報はD-U-N-Sに登録されている情報に基づき自動で入力される上に、このDSAの要件入力画面では変更ができません。

(所在地情報だけ変更できない。入力できるのは電話番号とメールアドレスのみ)

この画面から提供する情報と2.の書類情報をAppleに突合して貰うわけですから、D-U-N-Sの所在地情報と2.の書類情報が異なってたらNGです。

ADPの契約をした以降で本社移転している場合、D-U-N-Sの情報が古い可能性があります。事前に登記上の情報と、D-U-N-S番号に紐付く情報が一致しているか確認することをお勧めします。昔は東京商工リサーチのサイトで調べるのが当たり前でしたが、今は Apple が公式に専用ページを用意してくれています。

ページ内の「D-U-N-S番号が付与されていないかを確認」のリンク先から調べることができます。ただ、ADPのユーザとしてサインインしなくてはならないことに注意して下さい。

履歴事項全部証明書の所在地と異なっていれば、まず最初にDUNS側の情報を変更するところから始めます。D-U-N-S番号に紐付いた情報の変更はAppleのサイトからはできませんので、東京商工リサーチのサイトから申し込むことになります。自社D-U-N-S情報修正という専用のページから申し込みましょう。

(当然、自社のD-U-N-S番号はあらかじめ調べておく必要がある)

4. 有効な電話番号とメールアドレス

前回投稿でも紹介しましたが、DSAではトレーダーは連絡先を登録する必要があります。着信可能な電話番号と、メール送信可能なメールアドレスを用意しておいて下さい。

DSAによりEU圏のAppStoreの自社アプリのページで公開されることになります。また後述するコンプライアンス要件の入力では、電話番号とメールアドレスが有効かどうかの確認もされます。適当な番号やメールアドレスはNGです。

手続き

準備が終われば、画面の指示に従って進めていくだけです。以下、トレーダーを選択する前提で手順を紹介します。

(1) App Store Connect の画面に表示されているバナーから「詳しく見る」をクリックします。

(2) 「ビジネス」のページに遷移します。自社名をクリックします。通常は一つです。

(3) 遷移先でも同じような文章が表示されていますので、その末尾にある「コンプライアンス要件を満たす」リンクをクリックします。

(4) トレーダーかそうでないかを選ぶよう促されますので「DSAに基づくトレーダーです」を選択します。

(5) 連絡先情報の入力画面が現れます。前述の通り、所在地情報はD-U-N-S番号に紐付く情報から自動入力されるため変更できません。電話番号とメールアドレスを入力し「次へ」をクリックします。

(6) まずメールの真正性(正しいかどうか)の確認が行われます。

AppleID を新規に作成する時と一緒ですね。(5)で入力したメールアドレスに以下のようなメールが届きますので、メール文中の番号をそのまま入力します。

(7) 続いて電話番号の真正性の確認が行われます。

(5)で入力した電話番号に対してショートメッセージが送られてきます。法人の場合は固定電話の番号を入力しているでしょうから受け取りようがありません。ので、「Dont’s get verification code?」のリンクをクリックします。

Call Me を選ぶと電話をかけてもらえます。音声でコードを教えて貰えますのでそれを入力します。

(8) 次は確認書類です。提出資料の言語を選ぶ必要があります。「日本語」を選んで「次へ」をクリックします。

(9) 書類のアップロード画面が現れます。

先の準備で用意していた履歴事項全部証明書のPDFファイルを登録します。ファイル名に日本語が含まれていても問題ありません。

(10) 確認画面が現れます。内容に間違いないことをチェックして「確認」ボタンをクリックします。

(11) 以下のような受付メールが Accoun Holder の方のメールアドレスに届いている筈ですので一応確認しておきましょう。

(DSA用に(5)で入力したメールアドレスに届くのではないことに注意)

Apple側の確認が完了すれば以下のようなメールが同じく Account Holder の方に届きます。

以上でコンプライアンス要件の入力手続きは完了です。お疲れさまでした。

アプリごとの個別設定について

準備の項で、トレーダー登録後はアプリごとにトレーダーなのかそうでないかを指定できると書きました。Appleの公式ページにも以下の通り明記されています。

配信するアプリごとにトレーダーのステータスをオフにしたり、指定したりすることができます。

App Store Connect の各アプリの詳細画面で [一般]→[アプリ情報] のページにある [App Store の規制と許可]→[デジタルサービス法] の項目から変更が可能です。

「編集」のリンクをクリックすると、上述のコンプライアンス要件の入力手続きの時とほぼ同じダイアログが現れます。

前述の手順を進めていれば、デフォルトでトレーダーアプリとなります。が、ノントレーダーの扱いにもできます。

法人情報を公開したくないアプリではノントレーダーアプリを選択すると良いのですが、一つでもトレーダーアプリがあれば結局は公開情報にたどり着かれるでしょうから、あまり使い道はないかも知れませんね。

無理やり使い道を捻り出すとすれば、非表示アプリだけトレーダーアプリにするとか、App Store Connect に登録するアプリが非公開のカスタムAppに限られるケースで全部ノントレーダーにするとか…でしょうか。

以上、2回にわたりデジタルサービス(DSA)法について解説してきました。何のために必要か、あらかじめ何が必要か、が分かっていれば怖くもありませんし大した手間でもありません。前編も参考にしてサクッと手続きを済ませてしまいましょう。

(突然現れた今までにない警告文)

「…お客様がトレーダーであるかどうかをお知らせいただく必要があります。EUのデジタルサービス法により…」と記載されています。初めてみる文言で普通は戸惑いますね。

従来、この手の警告表示は、リンクをクリックして何も考えず「同意」「はい」を連打するだけで問題なかったのですが(厳密には問題ありますが…)、今回は全くもって様子が異なります。見慣れぬ警告表示に「EUの事だし、ウチは日本法人だから関係ない」と放置するスタンスでもこれまでは問題ありませんでした。

が、2024年8月15日に本件について公式な追加情報が出ました。

(大事な情報が度々配信されるのでこちらを参考に最新情報をチェックする体制作りを推奨)

記述されている通りですね。EU向けとはいえ何やら制限がかかるようですし、普段使う App Store Connect 上にずっと警告表示が残るのも気になりますし、そろそろ手続きを進めておいたほうが良さそうです。

そこでデジタルサービス法について2回に分けて解説しようと思います。

前編である本稿は、法律原文を読み解きながらアプリ開発の文脈でデジタルサービス法を解説します。背景とか主旨を理解しておいた方が良いからです。そして後編では、DSA関連の手続きの進め方を画面キャプチャつきで紹介します。企業によっては App Store Connect 上の手続きだけでは完了しない場合もあります。

ではまず前編を順に見ていきましょう。

• DMAとDSA
• DSAをザックリ読み解く
• DSAの第30条・第31条の読み解き

DMAとDSA

今回の件をもし「また見慣れぬ警告文が出ているなぁ。意味も分からないしAppleがまた面倒な事を強いてきたぞ」等と思われていたとしたら、残念ながらデジタル市場の昨今の動きに理解が浅いと言わざるをえません。関係者として正しく理解しておきたいものです。

2020年頃から、EUはビッグテック企業による「支配」に対して、EU圏内の企業や個人を守るため(という名目の)法律制定と施行に動いてきました。主なものが以下の2つ。

前者のDMAについては以下の投稿でも紹介していますのでご覧下さい。

• EUのDMA/DSAが業務用iOSアプリに及ぼす影響についての考察(1) -DMAとサイドローディング-

後者が今回主題のデジタルサービス法です。略してDSA。DMAと一文字違いですが役割は全く異なります。DMAがEU圏アプリ開発者の便益向上を図る法律で自由競争促進が目的なのに対して、DSAはEU圏一般消費者の安全安心の確保を図った法律です。向いてる先が違うのですね。

我々アプリ開発側視点で見ると、DMAは選択肢が増えるという意味でメリットですが、DSAは誤解を恐れずに言えば手続きが増える面倒なものです。

まぁ Apple はDMAもDSAもどっちも面倒ですけど(笑) 冷静に見れば Apple も可哀想な立場なのですよね。EUに狙い撃ちで標的にされ、後だしジャンケンで法律を作られ、それに従わなければ数十・数百億円レベルの罰金を取るといきなり言われるのですから。

何もApple 擁護というわけではないですが、EUに穿った見方をしてあえて書けば、この種のEUによる罰金収入は実はEU予算の中で無視できないウェイトを占めていることは広く知られるべき事かも知れません。

(DMAで標的にされた企業とサービス。EUはこれら企業をゲートキーパーと呼んでいる。詳しくはこちらの投稿を参照)

繰り返しになりますが、DSAはEU圏の一般消費者を向いた法律です。我々アプリ開発側もまた、AppStoreを介して一般消費者と向き合ってますから巻き込まれて手続きが必要だということです。業務用アプリだとしても、App Store Connect を使う以上は従わなくてはなりません。

DSAをまずザックリ捉える

DSA は端的に言うと「EU圏でデジタル商品(つまりアプリ)の販売を仲介するなら、ユーザが販売者(つまりアプリ開発者)にコンタクトできるよう透明性を確保しなさい」というものです。DSAはEU圏の立派な法律であり、施行は 2024年2月17日です。

なのでAppleは、翌月早々3月に App Store Connect の対応を済ませ、販売者(つまり我々アプリ開発会社や個人)に登録処理をするよう警告表示を出し始めたというわけですね。

DSAは正式名称を「デジタルサービスの単一市場および指令2000/31/ECの改正に関する2022年10月19日付欧州議会および理事会規則（EU）2022/2065」と言います。EU公式サイトにその法律原文が公開されていますので、よければリンク先から見てみて下さい。英語とEU圏の各言語のみです。

また、DSAの概要やポイントを解説する専用Webサイト The Digital Services Act package もEU公式サイト配下に用意されています。

ただ分量がかなり多いので読み解くのは至難の業。そこでAppleはデベロッパー向けに専用ドキュメントを用意してくれています。日本語での解説もあってかなり親切です。

この公式ドキュメントを見ると、DSAの第30条・第31条がキーになっていることが分かります。

デジタルサービス法 (DSA) 第 30 条および第 31 条の要件により、Apple は、欧州連合 (EU) の App Store でアプリを配信するすべてのトレーダーについて、連絡先情報を確認した上で公開することが義務付けられています。

アプリ開発に関係する者として、せめてキーとなるポイントだけでもDSAの詳細を少し深掘りするのは良いことでしょう。せっかくですから余り深くなり過ぎない程度にDSAの第30,31条を読み解いてみます。

DSAの第30条・第31条の読み解き

少し見ると分かりますが、Apple も我々アプリ開発側も盛大に巻き込まれる法律になっています。まず原文の第30条 第1項(Article 30-1)を見てみます。

1.   Providers of online platforms allowing consumers to conclude distance contracts with traders shall ensure that traders can only use those online platforms to promote messages on or to offer products or services to consumers located in the Union if, prior to the use of their services for those purposes, they have obtained the following information, where applicable to the trader:

(a) the name, address, telephone number and email address of the trader;
…(略)…

ザックリと日本語訳にするとこうなります。

オンラインプラットフォーム(AppStore)のプロバイダー(Apple)は、トレーダー(アプリ開発者)がEU圏消費者に製品やサービスを提供するよりも前に、彼ら(アプリ開発者)について以下の情報を取得しておかなければなりません。

(a) トレーダー(アプリ開発者)名称、住所、電話番号、メールアドレス

Appleはアプリ開発会社/者の情報を取得しなさいよって書いてありますね。さらに、DSAの第31条 第1項には以下のような一文もあります。

In particular, the provider concerned shall ensure that its online interface enables traders to provide information on the name, address, telephone number and email address of the economic operator, as defined in Article 3, point (13), of Regulation (EU) 2019/1020 and other Union law.

日本語にすると以下です。

オンラインのインターフェース(App Store Connect)でトレーダー(アプリ開発者)が名前、住所、電話番号、メールアドレスを提供できるようにしなければならない

どんな情報を得なければならないか細かく定められていて、オンライン手続きができることまで要求しています。EUはイチイチ細かいですね。

また DSAの第30条 第7項には以下のように記述があります。

7. The provider of the online platform allowing consumers to conclude distance contracts with traders shall make the information referred to in paragraph 1, points (a), (d) and (e) available on its online platform to the recipients of the service in a clear, easily accessible and comprehensible manner. That information shall be available at least on the online platform’s online interface where the information on the product or service is presented.

日本語訳にすると以下の通り。

オンラインプラットフォーム(AppStore)のプロバイダー(Apple)は、第1項の (a),(d),(e) をサービスを受ける者(ユーザ)が明確かつアクセス可能な形で、製品(アプリ)が掲載されているところと同じインターフェース上で提供されなければならない。

デベロッパーにオンラインで App Store Connect で登録させた情報を、一般消費者に見えるように App Store 上でアプリと同じ箇所に表示しなさいと言ってます。

結果、公式ドキュメントにあるようにEU圏では以下のようなイメージで表示されることとなります。

最後に、第30条 第2項も見ておきましょう。同項の後半に以下の一文があります。

As regards traders that are already using the services of providers of online platforms allowing consumers to conclude distance contracts with traders for the purposes referred to in paragraph 1 on 17 February 2024, the providers shall make best efforts to obtain the information listed from the traders concerned within 12 months. Where the traders concerned fail to provide the information within that period, the providers shall suspend the provision of their services to those traders until they have provided all information.

だいぶ長くなってきたので省略しますが、ここは期限についての言及です。施行日の2024年2月17日から12ヶ月以内に情報収集すること、それができないデベロッパーのアプリは提供を停止させるべしと書いてます。

ではここでもう一度、冒頭のキャプチャを見てみましょう。赤枠を追加しました。

前記の第30条 第2項に記載の「17 February 2024 …(略)… within 12 months.」という記述と完全に一致しますね。

以上、ザックリとDSAの概要と、ポイントである第30条と第31条を読み解いてきました。

どうでしょうか？Apple が主体的に何かデベロッパーに面倒を強いようとしているのではなく、EUの命令に淡々と(渋々と?)従って、法律通りにやっているに過ぎないということが理解できるかと思います。

Apple も巻き込まれてるんだ、とちょっと同情の気持ちで見てあげると、苛立ちやモヤモヤも少しは軽減されるのではないでしょうか。後編では、App Store Connect 上でDSA関連の手続きをどう進めるか具体的に解説します。

• 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 に招待することが明らかな関係者に対しては本稿紹介の方法が便利です。

• コンテンツ視聴型の業務アプリをカスタムApp化する時に注意すべきこと -ipaのサイズ上限-

ですが、実際のところ4GBを超えるアプリを App Store Connect にアップロードしようとするとどうなるのでしょうか。アップロードそのものができないのか、はたまた…。このあたりの挙動に関する情報は Apple も公にしていませんし、ネット上の情報を見かけることもありません。

そこで本稿では、アプリ上限4GB制限について、弊社が実際に検証し調査した結果をご紹介します。アプリ上限制限に引っかかりそうな InHouse アプリをカスタムAppに移行する時の参考として下さい。

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

• App Store Connect にアップロードはできる
• 4GB上限の正確なバイト数は？何のサイズを判定している？
• サイズ上限は4GBだけではない

App Store Connect にアップロードはできる

実は 4GB を超えたアプリであっても App Store Connect にアップロードは可能です。

(App Store Connect に ipa をアップロードする専用ツール Transporter)

上図は実際に4GBを超えるipaファイルをアップロードしている様子です。画面上にアプリサイズが表示されるわけではないので微妙なキャプチャではありますが…。

アップロードしたipaファイルは「ビルド」として App Store Connect にアプリと紐づく形で登録され、各アプリ毎に用意された TestFligth タブで下図のように確認することができます。

(過去にバージョン1.0として2回ipaファイルをアップロードして TestFlight に飛ばしている。3回目で4GB以上をトライ)

登録したてのipaファイル(ビルド)は、App Store Connect のシステムによって診断されます。上図の「処理中」とはまさに診断を受けている最中を意味します。ただこれはいわゆる「審査」ではありません。ipaファイルとして最低限の要件を満たしているかを App Store Connect が(ある程度)自動チェックする審査前の関門です。

このチェックが完了すると、通常は黄色バッジ付きで「提出準備完了」や「コンプライアンスがありません」という表示になります。ですが、ipaファイルが4GB上限を超えている場合、以下のような赤色バッジの表示になります。

もう少し分かり易く書いてくれてもいいのでは…と思いますが、なんにせよ無効だというわけです。この状態では TestFlight に飛ばすこともできませんし、もちろん申請もできません。サイズを小さくして出直してこいってなもんです。

この結果はメールでも教えてくれます。

4GBを超えているからダメだって書いてありますね。メール文中のリンク先には、アプリサイズを小さくするために使える技術も紹介されています。このメールが届いたら、4GB上限に対応すべくアプリのサイズを小さくする必要があります。

ここまでで、4GB上限を超えてしまっているアプリは App Store Connect にはアップロードできるが TestFlight にも申請にも使えない無効状態となる、という挙動を紹介しました。

4GB上限の正確なバイト数は？何のサイズを判定している？

ところで、アプリのサイズ上限は4GBということですが、4GBとは一体何バイトのことだと思われますか？

• (A) 1024を基底に計算する → 4 x 1024x 1024 x 1024 = 4,294,967,296バイト
• (B) 1000を基底に計算する → 4 x 1000x 1000 x 1000 = 4,000,000,000バイト

(A) ではないか？と考える方が多いと推測します(筆者もそうでした)が、実は正解は後者です。弊社検証で (A) (B) のバイト数を境に複数回調査したところ、(A)以上のサイズのアプリはもちろん、(A)以下(B)以上のサイズのアプリも無効になり、(B)以下のみが受け付けられました。

1024が基底ではなく1000基底のGB表記なのですね。いわゆる国際単位系(SI系)です。1024を基底とするIEC単位系(IEC 60027)ではないようです。まぁ厳密に書いているとすれば、もし(A)なら 4GiB というように、IEC的にギガを2文字表記する筈ですからそりゃそうか…ということでしかないのですが。

さて上限4GBの厳密なサイズは分かりました。では「何の」サイズが 4GB を超えるとダメなのでしょうか？やはりipaファイルでしょうか？

下図は生成された ipa ファイルが 4,000,000,000 バイトをわずかに超えている例を示していますが、このipaファイルで上限にひっかかるでしょうか？

答えはNOです。

実は上限判定は ipa ファイルのサイズに対してではありません。厳密には ipa ファイルをzip展開した中に含まれる .app のサイズとなります。過去にipaファイルとは何かという投稿で、ipaファイルは実は単なるzipファイルであり、展開すると中身が見れるという紹介をしました。

(sampleというアプリのipaをzipに変えて展開した様子。Payload 配下に .app がある)

階層的には上図のようになっていて、4GB上限でチェックされるのは sample.app というファイル(正確にはこれもまたフォルダでありバンドルと呼ばれる)のサイズです。これが4,000,000,000バイト未満ならokということです。ipa ファイルとして4GBを超えていても中の.appが4GB未満なら問題ないのですね。

サイズ上限は4GBだけではない

ついでに紹介すると、実はサイズ上限がもう一つあります。

.app の中に含まれている実行ファイル。これもサイズ上限があり、500MBを超えてはいけません。公式ドキュメントにも明記されています。

.app の上限4GBに比べるとかなりシビアに思うかも知れませんが、この500MBというのはコンパイルされてできるMach-O実行バイナリそのものの上限です。よっぽどのことがない限り超えることはない筈なので、さほど心配する必要はないでしょう。

以上、カスタムApp化する時に問題となりうるiOSアプリの4GB上限について詳しく解説しました。通常は該当するケースはほぼほぼ無いと思います。が、万が一、大容量ファイルを内蔵するアプリに関係しているという方は、先の投稿も合わせて意識するようにしてみて下さい。

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

そうしたアプリがなぜカスタム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つご紹介しました。該当する場合は是非早めに手を打つようにして下さい。

「TestFlightでのテスト後にいざ申請となった段階でビルドが選択できないんです。なぜでしょう？」

というもの。2024年4月29日以降、Xcode15以上を使うことが当たり前になり、恐らく同様の悩みを抱える現場が多くなると思われます。ので、本稿では、その理由と解決策について解説しようと思います。結論を先に書くと「Xcode organizer でアップデートする時に正しい選択肢を選びましょう」です。

Xcode15 で organizer が大きく変わった

Xcode15 の見逃せない変化の一つに、organizer で ipaファイルの再署名とエクスポート・アップロードのUIが少し変わったことがあります。アーカイブの一覧が表示されて、ここから操作するって基本は変わっていないのですが、

問題はこの後ですね。配布用の ipa ファイルを作る時、 Xcode14 以前では下図のように配布タイプを選ぶUIが出てきていました。

ADEPのInHouseなら3番目のEnterpriseを選んでエクスポートしてipaを納品、みたいなことをしていたわけですね。しかし、Xcode15では以下のような画面が表示されるようになりました。

Apple Developer へのアクセス権や Cloud Signing の権限が付与されることを前提としたUIに変わっています。Apple は、アプリ開発のフローを自動署名・自動アップロードに寄せていきたいのだと考えられます。

自動署名や Cloud Signing って何？という方は、Xcode14.0 の Release Note や WWDC2021の動画 Distribute apps in Xcode with cloud signing を見てみて下さい。本稿主旨ではないため詳細は別投稿としますが、将来的には全関係者が幸せになれる署名関連の新機能です。

Apple Developer で適切な権限が与えられていない場合、Xcode15 organizer の上図でそのまま [Distribute] をクリックすると以下のようなエラーが表示されます。(別のエラーの場合もあります)

(cloud-managed distribution certificates なる特別な配布用証明書が存在する。あなたは使えませんよというエラー)

適切なアクセス権を与えられていなかったり、そもそも今まで自動署名をやってきていなかったり、ADEPのInHouseしか経験が無かった開発現場では、このエラー回避に前述Xcode15の画面で Custom を選ぶことになります。すると以下の見慣れた画面となります。

(Xcode15では、この直前に自動署名&アップロードを前提とするUIが挟まるようになったということ)

しかし、この後に注意しないとハマってしまう罠が待ってます。次へ次へと進むと…以下の画面。

(配信オプションを指定するお馴染みの画面だが…)

Xcode15では、3つ目の項目が追加されています。デフォルトOFFです。ここで「このダイアログは全部ONにするもの…」ってな具合に何も考えずチェックして進むと、冒頭の「申請できない」問題が発生します。

内部テストにしか使わないという指定ができるようになった

3つ目のチェックボックスには以下の文言があり、

TestFlight internal testing only
Distribute only to internal testers with TestFlight. When enabled, this build of the app cannot be distributed via external TestFlight or the App Store.

「ONにするとTestFlight外部テストやAppStore向けに使えませんよ」と書いてあります。そう、文字通り App Store 向けに使えないビルドとしてアップロードされてしまうんですね。

「よく読みましょう」案件ではあるのですが、TestFlight の経験が浅い中で InHouse からカスタムApp に移行しているケースでは、致し方ないこととも言えます。慣れてませんし、英語ですし、TestFlightの細かなことを書かれてもよく分からないってなりますから。

このチェックボックスをONにしてビルドをアップロードすると、App Store Connect の [TestFlight] タブで以下のように表示されます。

(ビルド7のアップロード時に前述のチェックボックスをONにした。内部と明示されているのが分かる)

TestFlightの内部テスト専用となるわけです。なので、[配信] タブのバージョン設定からビルドを選択しようとすると…

(非常に分かりにくいがビルド7の行だけグレーアウトしている)

内部テスト専用であるビルド7はクリックできません。ここで、「App Store Connect にアップロード成功してるし、TesetFlight でのテストもできている。なぜ申請だけできない？」となってしまうのです。Xcodeを触る人とApp Store Connectを触る人が違う場合や、異なる会社の場合はなおさらです。

AppStoreアプリに慣れていない開発者の方であれば、Xcode organizer の設定が申請に影響を及ぼすとまで思い至らないのも無理はありません。また開発者自身は TestFlight を使わずテストできる場合も多いですから、TestFlight に慣れていない限り内部テスト関連の設定にまで気が回らないものです。

TestFlight の内部テストや外部テストを駆使したテストフローがあるのでもない限り、Xcode15 での以下画面では必ず3つ目のオプションはOFFにしましょう。

本来は、誤って外部テスト向けビルドや申請用ビルドとして指定してしまうのを避けるためのストッパー機能です。TestFlight を使いこなすフェーズになってくれば、テスト体制や運用ルールを考慮してON/OFFを柔軟に変えていくと良いと思います。

なお前述の Cloud Signing も理解して活用できている現場では、Xcode15 organizer 初っ端の以下画面で [TestFlight Internal Only] を選んで内部テスト用の署名・アップロードを行います。

以上となります。本稿では、InHouseからカスタムAppに移行する際に開発現場でハマりがちな罠を一つご紹介しました。内部テスト用かそれ以外用か…という使い分けは理解して活用するととても便利で安心できる機能ですので、是非TestFlightを使いこなして頂きたいと思います。

ちなみに、弊社からご提供するワークフロー手順書では開発会社様向けドキュメントに明記しているのですが、

(エンドユーザ企業から委託先開発会社に向けて提示することを想定したガイドライン)

繰り返しのルーティンなので注記していてもハマってしまうことがあるようです。難しいものですね。

Xcode も App Store Connect も仕様・UIが頻繁に変わりますので、やはり関係者全員が App Store や ipa ファイルの構造を理解して、対応力を身に着けたいものだなと感じるお問い合わせ例でした。