ADEPからADPへの移行(カスタムApp化)を進める企業や、新たに独自アプリを作る企業、またそうした企業を支援する関係者の方に役立てて頂けるかと思います。

自社従業員に使わせるアプリで、かつADPを前提としている点はご留意下さい。1枚ものの簡単なチャートになります。

画像貼り付けだと少し見にくいのでPDFも用意しました。以下にチャートの順に解説しますので、別ウィンドウでPDFを拡大しながら読み進めて頂くと良いと思います。

配信方法選定チャートの解説(1) : そもそも論

チャートは左上からスタートです。まず最初の判断は、

ここですね。まさかの「Webにしましょう」です。本サイトでもいくつか関連エントリを書いています。

• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (前編)
• 業務用WebシステムのiOS用クライアントアプリ開発は本当に必要か？を考える (後編)

弊社はiOSアプリと関わり始めて2025年6月時点で17年近く。その間、B2C/B2B/自社アプリ/受託アプリこれら全ての組み合わせを色々経験していますが「安易な自社アプリ開発はお勧めしない」が一貫したスタンスです。今も昔も業務用iOSアプリの真理だと思っています。

(10年以上前のセミナー資料。自社アプリを作るのは最終手段であると解説し続けてきた)

MDM/ABMを併用すれば、自社専用のアプリがなくてもWeb技術だけでiOS端末を十分に活用できます。なので、カスタムApp化を考える場合も新規アプリ開発をする場合も、まず真剣に「本当にWebではダメなのか？」を問うてみることをお勧めします。

2025年現在、業務用アプリの9割はWebで十分であるという感触を持っています。以下もご覧下さい。

• Webクリップとは何か(1) -Webサイトのブックマークを配布する-
• Webクリップの作り方と各設定値を徹底解説 [前編] -Webクリップとは何か(2)-
• Webクリップの作り方と各設定値を徹底解説 [後編] -Webクリップとは何か(3)-
• WebクリップはSafariを削除していても使用できる(ようになった) -Webクリップとは何か(4)-

配信方法選定チャートの解説(2) : PoCや実験

Webが無理なら、次はTestFlightの活用を検討して下さい。

TestFlightの最大のメリットは審査関連の面倒臭さがないことです。ユーザが100人以下ならTestFlightの内部テスト、ユーザが100人より多く10000人以下なら外部テストが使えます。外部テストには審査が必要ですが、あってないようなものですし、バージョンを変えない限り無審査というハックもあります。

TestFlightのデメリットは主に以下2つ。

• 有効期間は90日
• AppleIDが必要

ただ前者は1,2ヶ月ごとに定期的にビルドを作ればほぼ解決です。後者は、ABMを使って全社員にAppleID(Manged AppleID)の供与が容易になっているため、昔に比べてハードルは下がってます。Managed AppleID については以下をご覧下さい。

• AppleIDの新規登録方法 2024年保存版 – ABMからの登録 –

従業員が多い場合は EntraID や GoogleWorkspace との連携も活用できますので、TestFlightのAppleID要件はデメリットにならないケースもあります。

配信方法選定チャートの解説(3) : 本番稼働でも審査回避

TestFlight が適切でない場合、AdHoc 配布を検討することをお勧めします。

繰り返しますが、業務用iOSで一番面倒でかつ運用に制約を与えるのは審査関連です。それを避けるためのWebであり、TestFlight であったわけですが、それらがダメなら次は AdHoc です。

AdHoc についての詳細は以下をご覧ください。

• AdHocとは何か
• AdHocアプリを社外ユーザに配布できるのか
• AdHoc配布はテスト用途以外に使用できるのか

Apple Developer Program に明示的に端末識別子(UDID)を登録して稼働させる方法で、端末種別ごとに上限100台以下に抑えられるなら、ADEP の InHouse に近しい運用が可能です。

先に書いたTestFightの「AppleIDが必要」という条件は満たせないが、100台以下のPoCや実験アプリである場合でも有用です。

配信方法選定チャートの解説(4) : AppStoreからの配信

チャートもここまでくると、AppStoreからの本配信しか選択肢がありません。

AppStoreからの本配信にも種類があり、最初に検討すべき配信方法は「公開アプリ」です。我々が個人利用で App Store で見かけるようなアプリと同じ位置付けとなります。社名や関連名で検索した時にアプリの存在を知られても良い場合に採用できます。

公開アプリをまずお勧めするのは、他の選択肢である非公開アプリ(カスタムApp)と非表示アプリに比べて、実績のある開発会社が多くアプリ開発から配信までスムーズに進む可能性が高いからです。

非表示アプリなら追加の特別な審査が必要だったり、非公開アプリ(カスタムApp)ならABM/MDMの知識や運用体制も必要だったりと少々面倒臭くなります。

配信方法選定チャートの解説(5) : カスタムApp or 非表示アプリ

ここまでくるということは、Web技術では実現できず、まとまった端末数で本稼働させる必要があり、世間に知られたくないアプリです。この場合、どんな端末で動作させるのか？という視点で三択になります。

ひとことでカスタムAppといっても配信の仕方には2種類あり、インストールの仕方も変わります。どのような端末に配信するかに応じてどちらかを選ぶことになります。

• カスタムApp (管理対象ライセンス)
• カスタムApp (引き換えコード)

大半の場合(国内従業員向けの非公開アプリ)は、前者です。一方で以下に該当する場合は後者です。

• 端末を会社支給せず個人端末を業務に使わせるBYODスタイル
• MDMが導入できないケース

後者の引き換えコードを選んだ場合、業務用アプリが個人AppleIDに紐づいてインストールされる(つまり退社後も使われる可能性がある)点には注意して下さい。万が一に備えて認証機構を備えたアプリでなければ採用はできないでしょう。

また、日本企業としてABMの利用申請を行った場合、海外従業員のBYOD端末に対しては、カスタムAppの引き換えコードライセンスは使用できません。必然的に非表示アプリを選択することになります。

(研修資料より。AppStoreは国ごとに分かれており、カスタムAppの配信は国単位で閉じる必要がある)

あるいは、端末管理や運用体制まで調整して「国内法人で調達した端末に管理対象ライセンスでインストールして、海外従業員に当該端末を使わせる」という逃げ道を採用することもできます。

海外従業員への非公開業務用アプリの配布は、カスタムAppやライセンスの種類、ABM/MDMの十分な理解がないと難しいので余りお勧めしません。素直にWebアプリにしましょう(笑) というのは冗談で、非表示アプリか公開アプリにしてログイン機構を設けるのがベストです。

以上、ADP前提で自社従業員が使うアプリをどう配信するかの判定チャートを解説してきました。配信方法を決定する社内ルールを作る時の参考として頂ければと思います。もし「このアプリはどの配信方法が良いんだろう？」と気になる場合、こちらよりお問い合わせ下さい。

なお、本チャートは ADEP InHouse は考慮していません。ADEPは意外にもまだ使えている企業が多く、徐々に移行を強いられている印象ですが、まだ使えるなら使い続けるのが最善です。カスタムApp化を考える時に本ページのチャートを参考にして下さい。

また本チャートでは、従業員が使用するアプリを前提としました。もし「販売代理店に使って貰うアプリ」「ソリューションを販売した顧客企業の従業員が使うアプリ」のように自社従業員利用でない場合は少し異なるので注意して下さい。非従業員のケースはまた別の機会に紹介したいと思います。

• コンテンツ視聴型の業務アプリをカスタム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つご紹介しました。該当する場合は是非早めに手を打つようにして下さい。

両サイトにはユーザという概念があり、適切な人を適切な権限で招待するために「役割」を正しく理解する必要があるということを以前に書きました。

• ADPのユーザに割り当てる役割の基礎(前編)
• ADPのユーザに割り当てる役割の基礎(後編)

本稿では、ユーザのメールアドレスと姓名について、知っておくと良いプチ情報を幾つか紹介します。

App Store Connect は余り親切な設計になっていませんので、本稿で紹介することをあらかじめ知っていると、いざという時に詰まることが避けられるかも知れません。目次は以下の通り。

• 姓名にアンダースコアは使えない
• UIが変更されることがある
• メールアドレスに + を使えない
• メールアドレスには Managed AppleID も指定できる

では順番にみてみましょう。

姓名にアンダースコアは使えない

App Store Connect にユーザ招待する場合、ユーザの名前を「姓」「名」に分けて入力する欄があります。その両方の入力欄で、アンダースコアが使えません。

部門名等の属性情報も一緒入れておきたい…ってな時に遭遇しがちな問題です。上図の通りエラー文言で教えてくれますが、実は正確ではありません。スペースが利用できます。姓名情報に何か属性情報的なものを付加したい場合は、ピリオド・ハイフン・スペースを使うと良いでしょう。

UIが変更されることがある

App Store Connect の UI は時々ひっそりと通知もなく変更されます。ユーザを招待するUIも例外ではありません。

以下画像は、2024年2月時点の新規ユーザ招待画面です。冒頭にも同じ画面を載せました。実はこの画面が何度も変更されています。

以下は、同じ画面の2023年10月時点のキャプチャです。違いが分かるでしょうか。

メールアドレス入力欄の幅が違っていて、最下部のアプリ項目の有無(次の画面に移っただけ)も相違点です。加えて驚くべきは、一番上の「姓」「名」欄の順番が入れ替わっていることです。さすがに普通はやらない変更ですよね

ブラウザの言語設定によるものでもないため理由は謎ですが、このように App Store Connect ではUIが変更になることが時折あることは知っておくと良いでしょう。(Appleは過去にユーザの「役割」設定の UI を変更し、致命的なバグを発生させていたこともありますので油断できません)

メールアドレスに + を使えない

Google の Gmail を常用している方にはお馴染みの機能です。これが使えません。

ご存知ない方のために説明すると、一部のメールサービスではアドレスのアットマーク(@)の自分の名前の後に + と任意文字列を追加して擬似的にメールアドレスを量産できる仕組みがあります。Plus Addressing と呼ばれるもので、Gmail や Exchange Online が当該機能を備えています。

例えば、bob@example.com のメールアドレスを持つボブさんが、メールマガジン受信用メールアドレスとして bob+mailmagazine@example.com を勝手に作ることができます。当該メールアドレス宛のメールは全て bob@example.com の受信箱に届きます。

これを Plus Addressing (Sub Addressing と呼ぶこともある) と言い、App Store Connect でユーザ招待する際に使いたくなる場合があります。App Store Connect 用のメールアドレスだ、という意味で bob+appstoreconnect@example.com ってな感じで登録したくなるわけですね。

が、下図の通りエラーとなります。

(無効であるとしか表示されない不親切なエラー。パッと見で原因が分からず混乱する)

過去にはokだったのですが、2024年現在、App Store Connect に招待しようとするユーザのメールアドレスに Plus Addressing なメールアドレスは指定できません。

どうしても App Store Connect 用の意味づけを与えたメールアドレスで既存のアドレスと同じ受信箱に届くようにしたい場合は、エイリアスかメール転送を使いましょう。業務用途のメールサービスでは、いずれも管理部門での設定が必要になる場合が多いですので担当部門に相談して下さい。

メールアドレスには Managed AppleID も指定できる

ABM(Apple Business Manager)には、Managed AppleID と呼ばれる特別な AppleID が存在します。従業員用の AppleID を企業が自由に作成できる機能です。

(ABMで特別な AppleID を作成する様子。任意数作成可能。ABMについてはこちら)

活用されている例は多くはありませんが、実は ABM 上で作成した Managed AppleID を App Store Connect のユーザとして招待できます。

従業員が自身の会社用メールアドレスを appleid.apple.com で AppleID として登録済みの場合は役に立ちませんが、App Store Connect に招待するためだけの AppleID を新たに用意したい場合には活用できます。(チーム共用の AppManager 権限ユーザを作って招待したい…等)

なお Managed AppleID でサインインした端末は AppStore アプリのインストールができないため、TestFlight でのカスタムAppテスト目的で上記を行う場合は少し工夫が必要です。また改めて別投稿で紹介します。

以上、App Store Connect でユーザを作成する時にあらかじめ知っておくと良い豆知識を紹介しました。App Store Connect でのユーザ管理の際に役立てて頂ければと思います。

• カスタムAppのアプリ審査についてよくある誤解(1) 〜審査には時間がかかる〜
• カスタムAppのアプリ審査についてよくある誤解(2) 〜仕様や機密情報を開示する必要がある〜
• カスタムAppのアプリ審査についてよくある誤解(3) 〜特殊なアプリは審査して貰えない〜

今回は、「緊急アップデートは不可である」という誤解についてです。

ADEP(InHouse)なら自社の都合だけで即時配信が可能ですが、審査が必須となるカスタムAppではそうはいきません。とはいえやはり業務用アプリ。業務停止する程のクリティカルな不具合が発覚した時に、現場の端末にアプリを即時配信できないのは困りますよね。

緊急アップデートができないからADEP(InHouse)から移行はできません、という言葉はADP(カスタムApp)移行検討時の現場あるあるです。実際のところはどうなのでしょうか。

半分正解。アップデート版の即時配信はやはり不可

カスタムAppは緊急アップデートできない、という理解は半分正解で半分誤りです。まず正解部分を解説します。

理屈上は確かにそうなのです。カスタムAppは緊急アップデートできません。絶対に審査して貰う必要がありますから。例外はありません。

全てのAppStoreアプリは、審査をして貰い、Appleからの回答を待ち、その上で申請者側が「リリース」をする必要があります。業務用の非公開なカスタムAppでも同様です。

(カスタムAppのリリース作業の様子。審査合格で自動リリースする設定も可能だが、業務用では通常手動にする)

細かく流れを並べると以下のようになります。自社でコントロール可能なことを主導権欄に○で示しています。

コントロールできる範囲が全てではないため、自社都合で即時アップデート配信ができるとはとても言えそうにないですよね。その意味で「緊急アップデートはできない」という理解は正解です。ただ、正解度合いは半分です。

というのも、「緊急」の温度感は各社毎に、アプリ毎に、シチュエーション毎に、全て異なるからです。致命的な不具合が発覚したとして、何時間以内ならokと言えるか。これに明確な答えを出せる現場は少ないでしょう。そもそも「緊急」とは曖昧であり、定量化しにくいものなのです。定性的な表現で物事を断定すべきではありません。

緊急時対策を考える時に大切なのことは、

• (A) 緊急時を極力発生させないように開発・運用すること
• (B) 緊急時の業務フローを定めること

です。

カスタムAppは緊急アップデートができない…と嘆く関係者ほど、カスタムAppを前提としたルールや業務フローを検討すらしていないように感じます。例えば以前の投稿で紹介したような、本番用・テスト用でアプリを分けるといった開発手法を採ってしまっているとかですね。

(A)は開発テクニック論になるので別途紹介することとして、ここで考えたいのは(B)の緊急時の業務フローです。先ほどの表を再掲します。

実は各手順を細く見ると、カスタムAppでも「緊急」と言えるスピード感で対応できる可能性が見えてきます。

1,3はAppleを待つ時間ではありません。自社の問題です。誰がどのようにやるかを決めて正しい設定をすれば瞬殺で完了できるタスクです。また5,6はADEP(InHouse)を使っている場合でも一緒ですから考慮は不要。4はMDMの実装や仕様によりますので、MDMベンダーに確認し最短化する方法を提案して貰うことができます。

1,3,4,5,6は自分達が頑張れば瞬殺または最小化できること。では、残った2はどうでしょう。ここはAppleに依存する部分です。

緊急審査の要請ができる

余り知られていませんが、先ほどの表の1と2の間に、緊急審査要請を行うことができます。実は、公式ドキュメント App Review のページの中ほどに書いています。

唯一、自社だけの努力ではどうにもならない、かつ一番時間がかかりそうな Apple 審査の所要時間について、短縮の要請が可能になっているのです。もちろん然るべき理由は必要で、常に認められるわけではありません。

リンク先から専用のフォームを開くと、以下のようにどのアプリについてなぜ緊急審査が必要なのか入力を求められます。

(ADPのユーザとしてサインインした状態で入力する)

この緊急審査要請が受け入れられると、ものの数時間で審査して貰えてリリースが可能だということです。ただ、繰り返しになりますが理由が妥当でなければなりません。理由が不適切なら緊急審査を受理して貰えない場合もあります。

また、下図の注意表記(特に赤枠部分)は英文だからとスルーせずよく目を通しておきましょう。

過度な申請は将来の申請受理を難しくすると書いてありますね。従って乱用は避けるべきです。メールのタイトルにいつも「緊急」と書く人が信用されなくなるのと一緒です。

本当の緊急時に緊急審査をして貰えなくなる可能性がありますので気をつける必要がありますし、勝手に申請しないよう社内関係者や(AdminやAppManager権限を付与している)委託先にも注意を促しておくのが良いでしょう。

そもそも緊急審査要請は必要か？

実は、緊急審査の有用性は下がっています。

以前の投稿でも紹介した通り、90%のアプリが24時間以内に審査されていると公式に表明されていて、実際に数時間で審査が完了する場合もままあるからです。緊急審査要請の画面でも強調されています。

文頭から「今は平均で90%が24時間以内に審査されますよ。それにも関わらず御社は…」と書いてありますね。

審査を開始して貰うにも2週間かかっていた…という時代ならまだしも、審査スピードが上がっている昨今では、「Appleに緊急対応を求めても恥ずかしくない程度に、自社の緊急時体制は果たして整備されているか？」をまず問うことをお勧めします。

企業によっては非現実的なこともありますが、例えば以下のような検討/確認を行なって、体制を整えておくのが良いでしょう。

• 外部委託では商流段数を少なくし App Store の知見を持つ企業を選定する
• App Store アプリ申請の手順や役割分担を明確にする
• 本番用アプリとテスト用アプリを分けて開発しない
• TestFlight を活用して本番用アプリ想定で十分なテストを行う
• 端末側で TestFlight を配信し過去バージョンに戻せる体制を作っておく
• AdHoc 配布を併用することで有事のワークアラウンドにできないか検討する
• 初回バージョン以降は審査時間が短い傾向を活用し事前に初回審査を通しておく
• そもそも本当にアプリである必要があるかを考え、場合によってはWebアプリ化してWebClipでMDM配信する

緊急時を気にすればこそ色々と考えることがあるということですね。

以上、AppStoreアプリでは緊急アップデートができないという誤解について解説しました。半分正解で半分誤りです。なぜそう言えるのか、また緊急時対応が気になるアプリで事前に検討できる項目についても紹介しました。

アプリの緊急アップデートができないことを理由に、ADEP(InHouse)からADP(カスタムApp)には移行しないと決めてしまうのも一つの選択です。しかし、ADEPの将来が明るいとは考えにくいため、契約継続が難しくなる場合に備え本稿等を参考にして頂き諸々検討しておくことをお勧めします。

• カスタムAppのアプリ審査についてよくある誤解(1) 〜審査には時間がかかる〜
• カスタムAppのアプリ審査についてよくある誤解(2) 〜仕様や機密情報を開示する必要がある〜

審査のことがよく分からないという不安から、心配が誤解に繋がっていることが多いです。

これには非常に分かり易い理由があります。業務用iOSアプリを請け負う開発会社も、商流の間に入るコンサル会社やSIer企業も、B2Cの世界とは無縁な場合が多いのです。つまり AppStore に触れる機会がほとんど無い(無かった)。だから知らないし、よく分からないし、不安、となります。当然ですね。

ですが、誤解は紐解いてみれば「な〜んだ、そうなんだ」と拍子抜けすることがほとんどです。

シリーズ3つ目となる本稿では「専用機器やローカルネットワークの使用を前提とする特殊アプリは、そもそも審査して貰えない」という誤解について解説します。

結論 : 審査して貰える

結論を書くと、審査して貰えます、となります。

この誤解は、AppStoreのアプリ審査の経験がない業務用iOSアプリ関係者にありがちな思い込みです。ADEP(InHouse)からADP(カスタムApp)への移行検討時には特によく聞かれる言葉でもあります。

業務で使う専用ハード用のアプリだから審査して貰える筈がない、だから移行は無理です…ってなもんですね。

実は、AppStore で公開されている(審査を通過している)アプリ群を冷静に見渡してみると、専用ハードウェアと連携する前提のアプリが多く存在していることが分かります。例をあげましょう。

(最近何かと問題のLUUPのアプリ)

(SONYのDIY用IoTモジュールMeshのアプリ)

前者はバイクのQRコードを読み取る機能があります。後者は 2cm x 5cm 程度のIoT用パーツとBluetooth連携するアプリです。どちらも「ブツ」が必要ですね。

さて、これらの専用ハードウェアが必要なアプリを Apple はどのように審査しているのでしょうか？

ハードウェアをApple 現地法人に送付する…と思われますか？それとも審査が難しいという事情があれば無審査で通過させて貰えると思われますか？はたまたAppleの審査員(レビュワー)が開発元までわざわざ飛行機で来日して審査してくれると思いますか？

答えは、

• アプリの起動等の最低限のチェックは行われる
• その上で、アプリを説明する動画や画像を送って審査して貰う

です。

そう、専用機器を触って貰えないからAppleは審査ができない、社内ローカルネットワークでしか動作しない特別なアプリだから審査がそもそも不可、ではないのですね。

動画や画像で審査して貰った具体例

弊社実績の中からの具体例を2つほどあげてみます。

• 自社開発の、BLE (Bluetooth) 通信前提の専用ハードウェアと連携するB2Cアプリ
• 受託開発の、商業施設内に固定された機器をネットワーク経由で遠隔操作するB2Bアプリ

前者のB2Cアプリは、アプリ使用中の様子を動画撮影して審査して貰い、AppStore公開アプリとして国内で配信しました。2014年のことです。詳細は以下に掲載されていますのでご興味あればご覧ください。(2016年に(株)そらかぜに事業譲渡。その後、販売/サポート終了)

• 玄関先で雨降りを予想！iBeaconと連動する降雨予想自動通知アプリがお目見え
• 外出の際に傘が必要か知らせてくれる「そらビーコン」を衝動買い！

後者のB2Bアプリは、いわゆる専用ハードウェアのリモコンアプリ。同様に撮影動画で審査を受け AppStore の非公開アプリ(カスタムApp)としてABM→MDM経由でお客様の業務用端末に配信しています。ADEP(InHouse)からADP(カスタムApp)に移行した例で、審査は2022年のことです。2023年12月現在も現役稼働中です。

他にも事例はありますが、審査の受け方はどれも一緒です。アプリを実際に触ることだけが審査というわけではなく、Appleなりにアプリを理解しようと頑張ってくれます。そのための追加情報を提供するわけです。

どのようにして動画や画像を提出するのか

AppStore向けアプリは App Store Connect から審査に提出します。

(App Store Connect ではアプリ毎に詳細な情報を登録する)

アプリに関する様々な情報を入力しますが、その中にAppleの審査員(レビュワー)向けに各種ファイルを送付できるUIが用意されています。下図のように添付ファイルをアップロードできるのですね。

(通常は余り使わない)

1ファイルしか添付できませんので、複数ファイルを送る必要がある場合はzip化して添付します。

動画の場合はサイズが大きくなりがちですので、Box や Dropbox 等のクラウド型ファイルストレージを使ってもokです。共有用URLを発行し、そのURLをメモ欄に記載します。

秘密情報が含まれていてAppleのレビュワー以外にダウンロードされたら困る場合は、共有用URLにパスワードをかけメモ欄にパスワードを併記すれば良いでしょう。

「最初から動画をいちいち用意しなければならないのか？」

と気になる方もいると思います。最初から添付すると確かに親切なのですが、最初から必須というわけではありません。レビュワー用のメモ欄にテキスト解説するだけで十分な場合もあるからです。社内用のマニュアル動画を用意しているのであれば、ついでに添付するぐらいのスタンスで最初は良いと思います。

仮に、動画や画像なしで審査提出したとします。Apple のレビュワーが実際にアプリを起動して確認し「ちょっとこれでは審査しようがないなぁ…」となったとします。そうすると審査情報不足とされ、以下のように reject されます。(ガイドラインの2章「パフォーマンス」の違反という扱い)

(審査の情報が足りないとして reject されている様子)

Apple からはこんなメールが届きます。(太字は筆者)

We have started the review of your app, but we are not able to continue because we need access to a video that demonstrates the current version of your app in use on a physical iOS device, which shows 〜〜〜.

(rejectメールは基本的に英語だが、2023年12月頃からは日本語で送られてくる試みも始まっている)

要約すると「実機で動作している様子が分かるデモ動画を送ってください」ということです。文中 〜〜〜 の箇所は具体的に Apple のレビュワーが確認したいと考えている内容です。かなり親切に分かり易くアドバイスしてくれていると思いませんか？

こうなってから動画や画像を制作してもokです。reject を受けたからといってペナルティを課されたり、以後の審査で通りにくくなる…なんてことはありません。

また、このような情報不足系 reject ではアプリを修正して再ビルドしてアップロードする必要はありません。レビュワーのアドバイス通りに動画や画像を添付するか、共有URLを提示して再度申請するだけです。

(reject時にレビュワーと会話できるスレッドが用意される。ここで返信しても良い)

ちなみに、アプリ情報の修正/追加だけを求められるタイプの reject のことをメタデータリジェクトといいます。メタデータリジェクトでは、アドバイス通りに情報を修正/追加すれば審査が続行され、別の問題がない限りすぐ審査通過となります。

以上、「特殊なアプリは審査して貰えない」という誤解について 、実は動画や画像などのリッチメディアを提出することで審査して貰うということを解説しました。

カスタムAppは特定企業の非公開アプリですので、Appleが決して使うことのない専用機器や専用環境を前提とする場合が多くなります。動画や画像で説明が求められることに備えて、それらを制作するための体制作りと時間確保をしておくと良いでしょう。

そんなに恐れる必要はないしAppleもちゃんとやってるんですよ、ということを伝えるべくAppStore審査関係の投稿を幾つか投稿してきました。

• 業務用AppStoreアプリで審査にリジェクトされないために読んでおくべき公式ドキュメント
• カスタムAppのアプリ審査についてよくある誤解(1) 〜 審査には時間がかかる〜

AppStoreアプリ審査のことをよくご存知ない方は是非、上記の2投稿を先にご覧下さい。本稿では、カスタムAppアプリの審査について持たれがちな「Appleに仕様書や機密情報を開示しなけれならない」という誤解について解説します。

結論 : 開示の必要はない

今回も結論から書きます。アプリ審査にあたり仕様書の提出や機密情報の開示は不要です。

ドキュメント類の提出を求められることはありません。例えば、アプリの要件定義書や画面設計、サーバ構成、サーバ〜アプリ間で行う通信APIやプロトコル仕様書…等々、いずれも提出または開示する必要はありません。

この誤解も、AppStore 審査をよく知らないことからくる不安や猜疑心に起因しているかもしれませんね。

(AppStoreには200万個近いアプリが存在する。全アプリが書類提出していると想像するのは果たして妥当か？)

Appleによる審査は物凄い数のアプリに対して行われています。しかもアプリ毎に最初だけ…というではなく、全てのアプリの全てのバージョンで審査しているわけです。世界中の百万個を超えるアプリが、です。とてつもない数の審査が日々行われており、いちいち仕様書を渡されたところで Apple が見れる筈もないことは想像に難くないでしょう。

それに、我々は多くのソフトウェアで「ドキュメントは嘘が多い」ことを知っている筈です。メンテがされず仕様変更に追随できていないドキュメントが多いことはソフトウェア業界の経験則です。Apple にはそんなドキュメントを確認することの合理性はないと考えるのが順当です。

見られるのはアプリです。資料ではありません。

判断基準は App Store Review Guideline ただ一つ。これを守ること、本当にこれだけなのです。当該ガイドラインに書類提出要件はありません。App Store Review Guideline を熟読しましょう。弊社は15年以上アプリ審査を3桁以上のアプリで経験していますが、資料提出を求められたことは一度もありません。

提出しようと思えば資料をアップロードできる

審査をする際に各種の情報を登録する App Store Connect には、レビュワー(審査員)に対してファイル送付できる機能が備わっています。

(あるアプリのバージョン1.0申請準備の画面。ファイルを添付できる)

なので、提出しようと思えば提出できます。複数ファイルにまたがる場合は zip 化して送ることもできますし、レビュワーに向けて審査情報テキストを入力するメモ欄にクラウド型ストレージのURLを記載することも可能です。

(あるアプリで審査員向け文章中にDropboxのURLを記載した例)

が、仕様書や機密情報を提示したから審査が早くなるとか、ガイドライン違反も許容して貰えるといったものではありませんので、あえて提出する必要はないでしょう。

本来、審査提出時のファイル送付機能は、レビュワーにアプリの概要をテキストでは伝えにくい時に画像や映像を送るために使うものです。

暗号化技術については別。だが開示先はAppleではない

App Store Connect にアップロードしたアプリを、TestFlightで配信する時やTestFlight配信をせず直接申請する場合、原則、暗号化に関する自己申告を行う必要があります。

いわゆる暗号化技術に関する「輸出コンプライアンス情報」の設定です。

AppStore アプリの配布はB2CかB2Bか、公開か非公開か、に関係なく米国からみればソフトウェアの「輸出」になります。公式ページの輸出コンプライアンスの概要が詳しいですが、iOS SDK が標準で備えている暗号化機構を使わずに独自暗号技術を使う場合は情報提供が必要となります。

とはいえ、何を目的に暗号技術を使っているかの情報開示のみであり、暗号アルゴリズムを開示することまで求められるわけではありません。

(独自暗号技術を使っている場合、商務省管轄のBISに書類の提出が必要になる)

さらに、開示先は Apple ではなく、米国商務省産業安全保障局(BIS)です。BISに情報提示をして発行された書面PDFをApp Store Connect にアップロードするだけのことで、Apple に情報開示するわけではありません。

以上、「Appleに仕様や機密情報を開示しなければならない」という App Store のアプリ審査によくある誤解について解説しました。結論は、必要ないです。審査について不安になったら必ず App Store Guideline を読むようにして下さい。

業務用AppStoreアプリで審査にリジェクトされないために読んでおくべき公式ドキュメント

AppStoreアプリの審査については、紹介したリジェクト(審査不合格)に関する質問以外にも多く頂きます。しかし、大半の質問の背景には噂や想像や大昔の伝聞に惑わされている誤解が結構あると感じます。

(審査に関するApple公式ページ。ここに多くの誤解を解くヒントが詰まっている)

そこで、弊社経験とApple公式の2023年時点の最新情報も織り交ぜつつ、業務用iOSアプリ関係者が持ってしまいがちなカスタムAppアプリ審査の誤解を、シリーズで幾つか紹介していきたいと思います。

初回の今回は「Appleのアプリ審査には物凄く時間がかかる」という誤解。審査期間は誰もが気になることのようで御相談を頂くとほぼ100%質問を頂きます。

結論 : 思う程かからない

結論をいきなり書くと、極めて特殊な例を除けば AppStore アプリの審査に時間はほとんどかかりません。

Appleの審査にはものすごく時間がかかるもの…と仰る方は、そもそもAppStoreアプリに関わったことがないか、経験があるとしても数年〜10年以上前の経験だけで言っている、のいずれかでしょう。昨今では2,3日も見積もれば十分過ぎる程です。

具体例があったほうが分かり易いと思いますので、以下に弊社のあるアプリ(非公開のカスタムApp)の審査履歴を示します。2021年の例です。

(App Store Connect では審査の履歴を見ることができる)

AppStore アプリが初めての方には専門用語がありすぎて何のこっちゃ…かも知れません。

(研修資料から。代表的な状態遷移)

詳細な解説は本稿の主旨と異なるので避けますが、アプリにはステータスがあります。そして、そのステータス(状態)が変化していきます。目指すのはリリース済みを意味する緑色の「配信準備完了」の状態。ここでもう一度先の状態遷移履歴を示します。

「ユーザ」列は誰がその状態にしたのか、「日付」はその状態に変わった日時で、どれぐらい審査に時間がかかっているか分かります。

実際に読み解いてみると…

2021年1月29日 11:05の「審査待ち」となった瞬間がまさに審査に提出したタイミング。その約5時間半の同日17:38に審査対象となってますね(審査中)。その50分後の同日18:28に「デベロッパーによるリリース待ち」となったことがわかります。これで審査完了。あとはデベロッパー(つまり弊社)がリリース操作をするだけです。(手動リリースを選んだアプリだから)

リリース操作が翌日の2021年1月30日 14:50。24時間近く間が空いていますが、Appleに待たされていた訳ではありません。弊社のリリース操作が即時ではなかったからですね。即時リリースしたい場合は自動リリースの設定にします。…が、業務用アプリでは現場の混乱必至なのでお勧めしません。

ということで、上記例の審査所要時間は「審査待ち」から「デベロッパーによるリリース待ち」までの実質7時間半だった、ということになります。

思ったほどにはかからないと思われないでしょうか？時差の関係もありますが、タイミングが良ければ1,2時間で審査結果が返ってくることもあります。

公式に9割が24時間以内とされている

冒頭に紹介したAppleの公式ページ App Review には以下のような記載があります。

審査の所要時間は、9割のアプリで24時間以内なのです。もちろん審査NG(リジェクト)されると再審査ですが、審査そのものはそんなに待たないということです。

iOSが日本に上陸した2008年やその後数年の黎明期は、Apple側の体制も不十分だったり、App Review Guideline の整備も不足していたり、Apple も審査に不慣れだったりで、審査を待って2週間、ちょっとした修正でも下手したら1ヶ月かかってもリリースできない…なんてこともありました。弊社も当時は「提出してから2週間〜1ヶ月は見込んで下さい」とお客様に伝えていたものです。

ですが、Appleは審査の体制を強化しています。上図の「90%が24時間以内」の記載は、少し前までは「80%が24時間以内、90%が48時間以内」でした。審査にかかる時間は徐々に短くなっています。

ただ、常に24時間以内と限りませんし、公式情報に記載のない留意すべき傾向があります。

初審査に時間がかかる？

アプリの審査は「初回バージョンは遅い、バージョンアップは早い」と言われます。これは公式情報には明確な記載はありません。実際のところどうでしょうか。以下の図をご覧下さい。あるアプリの初回バージョンの審査履歴です。

初回の「審査待ち」となった2022年5月27日 14:35が提出した瞬間です。その14時間後の翌日4:26に審査が始まります(審査中)。そして約2時間後の6:43に審査完了でNG回答(却下済み)です。

指摘の修正に時間を要して、再提出したのは6月4日 13:26(2回目の審査待ち)です。その9時間後に2回目の審査が始まり(2回目の審査中)、その90分後には審査に合格し「デベロッパによるリリース待ち」状態となったことが分かります。結果的に初回提出から1週間程を要しています。

総所要期間はさておき、まず初審査の結果(NG)が出るのが14時間ということですから、前項の例(7時間半)に比べて時間がかかっているような気はしますね。

もう一つ例を示しましょう。また別のアプリの初回バージョンです。

こちらは初審査の結果(NG)に24時間以上待っていますね。実に37時間(7月13日 18:44 〜 7月15日 9:38)です。これぐらい待たされる場合もあるにはあります。

が、実は理由が1つあります。審査提出をして「審査待ち」状態になったのは 2020年7月13日 18:44 で、これは月曜日の夕方、しかも日本時間です。米国では7月12日で日曜日ですね。まぁつまり、そういうことです。公式情報がある訳ではないですが、米国時間の日曜日は待たされ易いというのも傾向としてあるようです。

本件の見かけ上の初審査所要時間37時間から24時間を差し引くと13時間。いずれにしてもやはり、最初の例に比べるとかかってる方です。

いかがでしょうか。

上記の2例から、初めての審査には結果が出るのに時間がかかる傾向があるのが感じて頂けるでしょう。弊社が関わったアプリの全履歴を示すことはしませんが、他アプリもほぼほぼ同様であり、やはり初審査は時間がかかる傾向は確かに感じますので、その認識を持っておくのは賢明だと思います。

ということで、審査に昔ほどには時間がかからないこと、とはいえ初審査は比較的長くなりがちなことを紹介しました。公式にも9割が24時間以内と表明されていることも示しました。本投稿が審査の感触を得る助けになればと思います。

ところで、紹介した初回バージョンの審査履歴の画面キャプチャでいずれもNG(リジェクト)を受けていることに気が付かれた方もおられるでしょう。実はそうなんですよね。これも実は傾向の一つです。初審査では審査NG(リジェクト)を食らうことが多いです。

こうした審査の傾向を踏まえたカスタムApp開発スケジュールの工夫については、また別途紹介したいと思います。

カスタムAppは App Store のアプリですので、Appleの審査に通過しなければなりません。頑張って開発しても審査に合格しなければ配信もできませんから心配なのは当然です。ADEP(InHouseアプリ)から移行するアプリの場合は、業務継続すら危ぶまれますので尚のこと気になるでしょう。

そこで本稿では、Apple が審査で何を見るのか、どんな場合にリジェクトをされるのか、を窺い知るのに役立つ情報を紹介します。

• Apple が公式にNGといっているものを確認する
• Apple のソフトウェア哲学を知りリジェクトを避ける
• Apple 公式の最新情報を常に確認する
• 誰が何の情報をみるべきか

順に見ていきましょう。

Apple が公式にNGといっているものを確認する

App Store のアプリでは申請されたアプリに審査員(レビュワー)がつきます。アプリの審査は生身の人間が行うのですね。B2CだろうがB2Bだろうが一緒です。

人間が判断して審査する以上、基準が必要です。それが App Store Review Guideline。公式のルールブックであり、カスタムApp関係者全員が読むべきドキュメントです。

App Store Review Guideline

レビュワーは基本的にこのガイドラインを根拠にアプリの合否を決めます。リジェクト(不合格)となった時には、下図のようにガイドラインの番号付きで指摘されます。

(リジェクトされている様子。不合格理由をガイドラインの番号で示してくれる)

ガイドラインが判断基準となっていることがよく分かりますね。

ルールを知らずにスポーツや競技で勝つことはできません。例えば、オフサイドのルールを知らずしてサッカーの試合にどうすれば勝てるか…を心配するのは滑稽ですよね。

それと同じことです。App Store の審査で勝利(審査通過)を得るには、まずルールを知る必要があります。App Store のルールブックが App Store Review Guideline。審査が心配な人はまずこれをよく読まなければなりません。話はそこからです。

App Store Review Guideline は昔と違って随分親切なドキュメントになっていますので、カスタムApp関係者は是非読んでみて下さい。

App Review

とはいえ、App Store Review Guideline は項目数も多く全部読むのは正直大変。確かにそうなんです。文字数にして数万文字ありますから。

サマリーだけ知りたいという人向けに紹介したいのが、App Store を紹介するページの App Review です。

Apple の審査とは？を基本から教えてくれるドキュメントで、リジェクトされる具体的な例も列挙されていますので、カスタムAppはおろか App Store 向けのアプリすら全くの初めてだ…という方には最初の入口として最適なドキュメントです。

(当たり前の理由でリジェクトされる割合が、案外多いことが分かる)

Apple のソフトウェア哲学を知りリジェクトを避ける

審査のガイドラインのほかに、目を通すべきなのが Human Interface Guideline です。略して HIG と書かれることもあります。 読み方はそのままエイチアイジー、あるいはヒグと呼ぶ方もいますね。

Human Interface Guideline

量は膨大で App Store Review Guideline を遥かに上回ります。AppleはデザインやUX/UIに強いポリシーを持っていて、それを明文化したのが HIG になります。

アプリが分かり易いデザインで使い易い作りになるよう、見た目や操作感の基本原則やベストプラクティスを OS ごとにまとめたものです。UIはこうした方が良いよって Apple 自身が書いてくれてるのですね。

例えばボタンのセクション。

そのページにベストプラクティスというセクションがあり、以下のようなことが書いてあります。

「ユーザが使いやすいボタン」とは一体何なのか、「目的が明確に伝わる」とはどういうことか、解説してくれています。ボタンはこうすべきと Apple が言っているわけですから従っていないとリジェクトになる可能性は高まります。

(研修資料より。ユーザ体験が損なわれることを Apple はとても嫌う)

前述の App Store Review Guideline でもHIGはアプリが従うべきガイドであると明記されています。

ただ、弊社経験の感触ですが、App Store Review Guideline ほどの重要度は高くないように思います。従っていないと思われるアプリも実際たくさんありますので。リジェクトを極力避けるという意味で目を通すべきですが、UIを設計するデザイン担当の方以外は副読本的な捉え方で良いかも知れません。

iOSアプリのプランニング

公式の副読本的な読み物は他にもあります。次に紹介するのはiOSアプリのプランニングというドキュメントです。

iOSの世界に相応しいiOSアプリをどのように開発していくのか、初めてiOSアプリを開発する方に向けたドキュメントという位置づけです。下図のようにページ中程に、開発観点でのアドバイスがあります。

ベストプラクティスに違反するアプリの仕様とならないよう最初から意識しておくと良いでしょう。実装方針を誤ってしまう…といったことが避けられます。

iPadOSアプリのプランニング

前述の iOSアプリのプランニングのiPad版です。名称はそのまま。iPadOSアプリのプランニングと言います。iPadOS に特化した文書です。

共通している箇所も多いですので、iPad専用アプリを作る場合は、最初からこちらを確認すれば良いでしょう。iOS/iPadOS両対応の場合は、大変ですが両方ですね。

Apple 公式の最新情報を常に確認する

ここまででご紹介した App Store Review Guideline も Human Interface Guideline も結構頻繁に更新されます。WWDCが開催される毎年6月や、新製品の発表のある9,10月あたりは要注意。それ以外でも Apple の文書は度々更新されます。

そこで読むことをお勧めしているのが、最新情報を配信してくれるニュースとアップデートのぺージです。冒頭に紹介した App Store Review Guideline が更新されたらこのページに掲載されます。

(2023年6月に更新された際の掲載内容。どこが変わったのか詳細が示される)

他にも、App Store に審査提出する時のSDK/Xcodeの制限情報や、全てのアプリに求められる新たな条件等の情報もこのページに掲載されます。

(2023年4月からXcode15以上でなければ審査提出すらできなくなるという重大なことがシレッと書かれている)

エンドユーザ企業というよりもアプリ開発会社が見ておくべきページといえます。この確認を怠ると、無駄なリジェクトを受ける可能性が高まったり、そもそも審査提出すらできず手戻り作業が発生する等の事態に遭遇することになります。

想定外の工数増を強いられる変化もありますから、必ずチェックしなければなりません。WWDCのキーノートや各セッションの動画を普段見ている開発会社や開発者の方は問題ありませんが(情報感度が高い)、そうでない場合は要注意です。

アプリ開発案件の商流の間にいるSIerやコンサル会社におかれては、再委託先の開発会社がこの種の情報にアンテナを張っているかどうかはチェックしたほうが良いでしょう。

ちなみに本ページを「更新されていないか？」と毎日チェックするのは大変です。なので、公式のRSSを購読することが推奨されます。

フィードリーダを使っても良いですし、slack 等のチャットサービスでRSSを解釈して通知してくれるBOT等を導入しても良いでしょう。

(RSSを購読すれば更新があればすぐ分かる。macOSのRSSフィードリーダ Vienna)

Apple が開発会社に届ける情報を確実に受け取り、取り残されないようにしたいものです。

開発会社が見るべき情報については過去の投稿でも言及しています。ニュースとアップデートを開発者向け専用アプリで閲覧することもできますので、併せて確認して下さい。

誰が何の情報をみるべきか

ここまでで紹介した情報は全て公式のものです。審査について心配する前に、そしてググるより前に、確認すべき情報が沢山あり、それを Apple 自身が膨大に発信してくれていることが理解頂けたと思います。

理想は関係者全員が全部の文書に目を通すことですが、普通は余り現実的ではありません。そこで、どの公式ドキュメントを誰が読むべきか、重要度別に表にまとめましたので参考にして下さい。

◎が絶対、◯が可能であれば、- は興味があれば、ぐらいの感じです。

アプリを外注し、デザイン会社と開発会社が分かれてるようなプロジェクトを想定しています。プロジェクト体制によって「会社」を「担当」や「部署」と読み替えて下さい。

以上、リジェクトを避けるために読むべきドキュメントを紹介しました。

iOSが日本に上陸した2008年当時は、この種のドキュメントは余り整備されていませんでした。App Store Review Guideline もいい加減なもので、理不尽・不可解なリジェクトも多々聞かれました。(弊社も色々体験しました)

が、現状は違います。

ドキュメントも豊富で、事前の準備でリジェクト回避が相当可能になります。面倒くさがらずにドキュメントを読み、Apple の審査で合格を勝ち取れるようにしていきたいものです。

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

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