2021.4.19

カスタムApp（CustomApp）とは何か（７） 〜カスタムAppの審査を回避する方法はあるか〜

前回の投稿でカスタムAppの審査日数や難易度について紹介しましたが、そもそも審査を回避する方法はないのでしょうか？

結論から言うと、カスタムAppとしてリリースするための審査回避方法はありません。

必ず審査を受ける必要があります。自社専用の業務アプリは、カスタムAppとして申請して、審査に通過して、ABMで「購入」して、ようやくiOS端末に届けることができます。ABMを介する以上、審査は必須です。

(原則的にカスタムAppでも審査を免れることはできない)

これまでADEPでのInHouseアプリ開発・納品経験のある開発会社やSIerにとっては、残念なお知らせでしょう。ただ全く方法がない訳ではありません。そこで本稿では、審査回避しるう配布方法を1つ紹介します。

 

TestFlightの内部テスト使う

AppStoreには、TestFlightというアプリ公開前テストのための仕組みがあります。

(元々あるベンチャーが開発していたテストの仕組み。Bustly社が買収後、Appleが買収・統合し2014年から公式提供)

通常、AppStore公開アプリを事前テストする文脈で紹介されますが、このTestFlightはカスタムAppでも使うことができます。カスタムAppはAppStoreアプリの一種だからですね。

→

(左はテストバージョンが配布されるTestFlightアプリ。TestFlight経由でインストールしたアプリは黄色い●印がつく)

TestFlightを使えば、ABMを介すことなくTestFlightアプリ経由でカスタムAppを配布することができます。カスタムAppの説明でよく載せている図に描き加えるとすると以下のような感じですね。一番右端です。

(TestFlightは審査通過を前提とするABMの迂回路になりうる)

TesetFlightには以下の通り内部テストと外部テストがあり、内部テストを使うと実質Appleの審査を受けることなくカスタムAppが配布できます。

テスト形式	インストール制限	審査される内容
内部テスト	100人/30台	.ipaファイルの最低限のバイナリ妥当性
外部テスト	10000人	App Store Review ガイドラインの項目

ただしTestFlightは、

• テスト・評価の用途限定
• 有効期限が90日(90日毎に再ビルド再配信が必要)
• AppleID必須
• 配布対象数に上限がある
• 配布ツールとして専用のTestFlightアプリのインストール必須

など様々な制約があります。審査回避できるとはいえ、この方法で配布できるケースは研究開発やPoCを目的とするアプリの場合に限られます。通常業務に使うリリースが見えてきた時点で、最新バージョンを正規の審査に提出することになります。

カスタムAppの審査を実質的に回避する方法は、このTestFligth内部テストを使う方法に限られます。これ以外に、カスタムAppの審査を免れる方法はありませんし、ADEP/InHouseのようなやりたい放題をカスタムAppに期待することは残念ながらできません。

ですので、ADEPの契約を持っていない企業が専用の業務用アプリ開発を行う場合、カスタムAppでの審査は原則必須で不可避と考えておいたほうが良いでしょう。審査を迂回する方法を考えるより、本当に審査を回避する必要があるのか？を今一度考え直すほうが賢明です。

 

そもそも、なぜ審査を回避したいのか？

企業や案件によって理由は種々様々ですが、代表的なよく聞く理由と、それが審査回避を目指す理由にはならないことについて幾つか書いてみようと思います。

アプリ配信を審査完了まで待ってられないから

先の投稿の通り審査には1-3日程度しか要しません。これはAppleも公式に述べていますので、例年末のクリスマス休暇に伴う審査受付停止時期にかぶらない限り通常は問題にならない筈です。

「万が一通らなかったら…？」

その場合は事前に申請しておくと良いです。本申請でなくても、TestFlight の外部テストでも良いでしょう。App Store Review ガイドラインに抵触していないかどうか Apple に事前チェックして貰うようなものです。

それでも万が一の時にどうすれば？…と気になる場合は、AppStore公開アプリと同様に緊急申請という仕組みがあることを知っておくと安心できるのではないでしょうか。

(どうしても大至急審査が必要な場合は使用できる。余程のことがない限り使ってはならず乱発は厳禁。ADP契約企業のみ申請可能)

以上をふまえても「やはり自社都合でいつでもリリースできる状態を担保したい、だから審査は嫌だ」というなら、まずアプリ開発の計画そのものや品質担保体制を考え直すことをお勧めします。

Appleが推奨されないAPIの使い方をしたいから

推奨されていないと分かっている場合は考え方を改めましょう。推奨されたAPIを使って実現できないかを考えるか、iOSアプリとして開発することを諦めたほうが良いです。

機密性の高い情報を扱うアプリだから

認証機構を実装して、審査用アカウントと審査用ダミーデータを用意して申請しましょう。

(審査用アカウント情報を提供する申請画面。アカウント情報以外にテストの手順を詳細に解説したり、レビューに使う添付ファイルを送ることも可能)

Appleに審査用アカウントでログインして貰った上で審査して貰えます。審査用アカウントでは機密性を除外したダミーデータしか参照されない仕組みにしておくと良いでしょう。

通常、どんなシステムでもテスト用のデータセットとテスト用アカウントを用意して関係者の間でレビューするものです。そのアカウント情報をAppleにそのまま伝えるだけで十分です。

最新バージョンではない自由なバージョンで配布したいから

ADEPによるInHouse配布と同様の自由度を求める場合によくある理由です。InHouseアプリの場合、いつでも任意のバージョンに戻すことができました。が、カスタムAppでは常に最新版が配布されます。AppStore公開アプリと同様、過去バージョンに戻すことはできません。

ただ、TestFlightの内部テスト→外部テストで本配布前に十分なテストを行うことができますし、また万が一の時には先に述べた緊急申請という手段もありますから、過去バージョンに戻せることを必須とする理由はない筈です。

それでもやはり心配であれば、TestFlightで複数バージョンを提供しましょう。有事の際は一時的にTestFlightから過去バージョンを使ってもらうのもアリです。

→ →
(TestFlightアプリからカスタムAppの過去バージョンから選択的にインストールする様子)

 

以上、カスタムAppの審査回避について考察しました。まとめると以下のとおりです。

• 原則、審査は必須。避ける方法はない
• 技術評価やPoC用途であれば TestFlight の内部テストで運用しうる
• 審査を避ける理由の幾つかには妥当性がないので審査は受け入れる

弊社所感ですが、悪意(非推奨APIを意図的に使う)や知識不足(推奨APIでできることを知らない)、計画不足(無理なスケジュール)や品質不足(テスト体制の不備)といったことがない限り、カスタムAppの審査を迂回したいと考える理由は余りありません。APIへの確かな理解で計画的なアプリ開発をしたいものですね。