2021.5.17

MDMの導入から利用開始まで(2) -MDMチェックイン-

以前の投稿で、MDM導入初期に必要なPUSH証明書の取得について解説しました。PUSH証明書とは、以下の図の(1)ができるようにするためのものでした。


(MDMによる端末管理の登場人物は、MDMサービスとAPNsと端末の3者)

次に必要になるのがMDMにiOS端末を登録することです。これをMDMチェックインと言います。本稿ではこのMDMチェックインの基本を解説します。

 

MDMチェックインとは

MDMの運用では、その管理者がいきなり任意のiOS端末を制御できるようになるわけではありません。もし勤務先の情シスが使っているMDMサービスが、いきなり自分の個人端末を遠隔制御し始めたら困りますよね。

当然そんなことができる筈もなく、MDMによる端末管理では最初にまずiOS端末側から「私はあなた(MDM)にコントロールされても構いません」と明示的に宣言する儀式を行う必要があります。


(端末側からMDMサービスに管理(支配)を依頼する。MDMから端末を管理(支配)しにいくわけではないことに注意)

端末側が主体であることに注意して下さい。例えるなら、MDMサービス側に端末の入る箱をまず用意して、端末からその箱に入りに行く感じです。まさにホテルのチェックインですね。

一度チェックインすると端末はMDM支配下に収まり、それ以降はMDMサービスから(つまり管理部門から)遠隔制御、アプリや設定のインストール、各種の情報収集などが行われるようになります。

それでも良いですよ構いませんよと端末から意思表明することがMDM チェックイン(Check in)です。次に紹介するMDMチェックインの手順は、チェックインが端末主体であることをよく示しています。

 

MDMチェックインの具体的手順

弊社でよく使っているBizMobile Goを例にMDMチェックインするまでの手順を紹介します。

(1) まずMDMサービス側で管理対象端末が入る「箱」を作ります(BizMobile Go では「デバイス」という言葉が使われています)

(2) MDMサービスが(1)で作った「箱」にチェックインするためのURLやQRコードを生成してくれます (BizMobile Go に限らず他のサービスも同様です)

(3) チェックインすべき端末で(2)のQRコードをカメラで読み取るか、Mobile Safari でURLを直接開きます。MDMプロファイルなるものが提供されますのでダウンロードします。MDMプロファイルとはMDMチェックインするための特別なデータを含むプロファイルです

(4) MDMプロファイルのダウンロードが終われば、設定アプリを開いて [ファイルがダウンロードされました] をタップしてプロファイルの詳細に「リモート・マネジメント」と表示されていることを確認します。


(右図のように削除ボタンがあることは、この時点で端末側がMDM管理下に入ることを拒否できることを意味する)

(5) 右上の[インストール] をタップすると信頼するかどうかを聞いてきますので[信頼]をタップします。もちろん、心当たりがなければ [信頼] してはいけません。

以上でMDMチェックインは完了となります。どこまでも端末主体であり、MDM側から一方的に管理し始められるものではないことが理解できたと思います。手順(1)(2)はMDMサービス毎に異なりますので、詳細は各サービスのマニュアルを参照して下さい。

ちなみに、手順(3)にあるMDMプロファイルには、MDM payload という特別なデータが含まれていて、これが端末に取り込まれるとMDMチェックインのプロセスが発動するようになっています。MDMチェックインで何が行われているか技術的な興味がある人は、Appleが公開しているMDMプロトコル仕様書の第2章 MDM Check-in Protocol を読むと良いでしょう。


(iOS端末のMDMプロトコルについて詳細を記すAppleの技術文書)

 

MDMチェックアウト

ここまでMDMチェックインについて解説しましたが、逆に、ホテルの「チェックアウト」で退室するようにMDM管理下から逃れる方法はあるのでしょうか。

答えはYESです。

MDMチェックインした端末で、設定アプリを開き [一般]→[デバイス管理] の画面を表示すると以下のような表示になります。

[削除]というボタンがあるのが分かります。これをタップすると最終確認の後にMDM管理下から逃れることができます。以後、MDMは端末を遠隔制御したり情報収集したりすることはできません。

前節で解説した手順でチェックインした場合、必ずこの画面に削除ボタンが表示されます。MDMに管理されるのも、MDMの管理から外れるのも、端末を操作する側の自由であるということですね。

…しかし。これでは意味ないのでは?

管理下から勝手に外れて貰っては管理の意味がありませんよね。そう考える管理者もいるでしょう。運用でカバーする方法もありますが、できれば禁止したい。そんな管理部門の期待に応えるのが DEP(Device Enrollment Program) という機能です。

DEPを使えばMDM管理から外れる行為を禁止することができます。(ついでにチェックインを自動化したり自動で監視モード化することも可能になります)


(DEPによる自動チェックインをした端末での [一般]→[デバイス管理] の画面。削除ができず管理下から逃れられない)

 

以上、MDMの導入準備二大項目の1つ目PUSH証明書の取得&登録に続く、MDMチェックインについて紹介しました。まとめると以下のとおりです。

  • MDMから勝手に任意の端末を管理・コントロールできるわけではない
  • MDMは端末側からチェックインして貰ってはじめてその端末を管理できる
  • MDM管理下にある端末は任意でMDMの管理対象から外れることができる
  • DEP機能を使えば管理対象から外れることを禁止したり自動チェックインができる

最後に言及したDEPは、また別の記事で解説します。本稿ではひとまずMDMチェックインの基本的な振る舞いについて紹介しました。

2021.5.10

カスタムApp(CustomApp)とは何か(10) 〜引き換えコード配布でのアップデートや再インストールについて〜

以前の投稿でカスタムAppにはインストール方法が2つあると紹介しました。

本稿では、後者の引き換えコードでカスタムAppを配布した場合の再インストールやアップデートについて解説します。(ライセンス配布の場合については前回の記事を参照して下さい)

 

引き換えコード配布はAppleIDに紐づく

カスタムAppを引き換えコードとして購入した場合、コードを従業員に配布し、各従業員は受け取ったコードを使ってインストールするのでした。下図中央の配布フローです。


(AppStoreアプリ内で引き換えコードを使ってインストールする)

この引き換えコードで配布した場合、 カスタムAppのアップデートや再インストールはどのように行うのでしょうか。

MDMを介したライセンス連携配布とは異なり、引き換えコード配布されたカスタムAppは必ず従業員のAppleIDに紐づくことになります。従って何か特別な運用になるというよりは、通常のAppStore公開アプリを従業員が勝手にインストールしている時と同じような運用になります。順にみていきましょう。

 

引き換えコード配布したカスタムAppのアップデート

通常のAppStore公開アプリと同じです。

従業員の端末側の設定でAppStoreアプリの自動アップデートがONになっていれば、カスタムAppも自動的にアップデートされます。一方、自動アップデートの設定がされていなければ、従業員が手動でアップデートするまで最新バージョンはインストールされません。


(OFFにしている従業員がいるかも知れないので、カスタムAppのアップデートの周知徹底が必要になる)

カスタムAppは、過去に紹介した通りAppStoreアプリの一種です。また引き換えコードのインストールではAppStoreアプリを使います。非公開アプリであるということ以外に、AppStore公開アプリと異なる点は全くないわけですね。

ですから、アップデートが配信されるかどうかは従業員側に委ねられ、管理部門は一切コントロールできません。カスタムAppを引き換えコード配布で運用する場合は、アプリ内部で「最新バージョンになっていなければアップデートを促す」といった仕組みが必要になるでしょう。

 

引き換えコード配布したカスタムAppの再インストール

削除してしまったアプリは通常AppStoreアプリから検索して再インストールします。が、カスタムAppはAppStoreアプリで検索しても検索結果には現れないのでした。ではどうやってカスタムAppを再インストールするのでしょう?

答えは、AppStoreアプリの購入済みアプリの一覧からとなります。配布済みの引き換えコードを再度使ってもらうのではないことに注意して下さい。引き換えコードは一度使うと再利用できないからです。


(引き換えコードは使い切り。再インストールに未使用コードを提供しても良いが運用が煩雑となり現実的ではない)

購入済みアプリの一覧を見るには、AppStoreアプリを起動して、画面右上のAppleIDアイコンをタップします。


(AppStoreアプリからアカウント画面を表示する。多くのユーザには余り馴染みのない画面)

次に、[購入済み]をタップすると、過去に入手したアプリの一覧が確認できます。


(カスタムAppとAppStore公開アプリとの区別は無い。上図では2つ目のアプリがカスタムApp)

一覧には引き換えコードでインストールしたカスタムAppも含まれていますので、アプリ右端のアイコンタップで再インストールできます。

分かってしまえば何のことはないのですが、事前に知らされていなければ誤ってカスタムAppを削除した従業員は混乱してしまうことでしょう。引き換えコードを使って運用する場合は、アプリの再インストール方法を一緒に案内しておくことをお勧めします。

 

以上、引き換えコードを使ってカスタムAppを配布した場合のアップデートと再インストールについて紹介しました。完全に従業員に委ねることになりますので、管理部門にとって不都合である場合がほとんどです。

従って、業務用アプリは原則的にライセンス連携でMDM経由の配布を行うべきです。MDM経由で配布できない事情がある特別な場合や、MDM経由の配布が不適切なアプリである場合でのみ、引き換えコードを使うのが良いでしょう。

2021.5.3

カスタムApp(CustomApp)とは何か(9) 〜ライセンス連携配布でのアップデートや再インストールについて〜

過去の投稿でカスタムAppには配布方法が2つあると紹介しました。

本稿では前者のライセンス購入でカスタムAppを配布した場合の、アプリの再インストールやアップデートについて解説します。何度か掲載している下図の一番右端の配布フローとなります。

カスタムAppをライセンス購入した場合、アプリの個数情報がMDMに同期されます。MDM側では購入個数を超えない範囲で「どの端末にどのカスタムAppをインストールするか」を設定し、その設定に従ってアプリがインストールされるのでした。

では運用フェーズに入ってから、カスタムAppがアップデートされた時はどんな挙動になるのでしょうか?また、万が一ユーザが端末側でアプリを誤って削除してしまった場合、どうすれば再インストールできるのでしょうか?順にみてみましょう。

 

ライセンス購入配布したカスタムAppのアップデート

MDMの設定によりますが、

  • 自動でアップデートされる
  • 手動でアップデートしてもらう

のどちらかになります。通常の個人利用の端末では、自動 or 手動をユーザが設定アプリで指定しますが、MDM管理下にある業務端末の場合はMDM側でアップデートのポリシーを定めます。


(BizMobileの場合はアプリ毎に自動更新にするかどうかを切り替えられる、自動更新のチェックを入れていなければ手動)

自動にするか手動にするか。これはカスタムAppの種類にもよりますし、同じカスタムAppでもバージョンによってどちらが良いかは変わってきます。よく吟味して設定しましょう。

 

ライセンス購入配布したカスタムAppの再インストール

デバイス側で万が一カスタムAppを削除してしまったらどうなるのでしょうか。答えは、

インストール命令が再び送られ、再インストールされる

です。大半のMDMサービスは、端末をMDMで設定した通りの状態にしようと積極的に働きかけてきます。端末側のアプリ一覧にMDMでインストール指定したアプリがなければ「欠けてるぞ。インストールせよ!」と命令が降ってくるイメージです。そうしないと遠隔管理の意味がないですから当然の動きですね。


(MDMの設定と差分がないか定期的な確認と同期命令が送られる)

よってユーザがカスタムAppを勝手に削除してしまった場合でも心配無用。MDMからの命令により再インストールされることになります。ただし監視モードでない端末では以下のようになる点は留意してください。(参考 : iOSの監視モードとは何か)


(監視モードでない場合は再インストールを強制できない。強制したい場合は監視モードにすること)

MDMがカスタムAppの削除を認識するタイミングや再インストール命令を送ってくるタイミングは、MDMサービスによって異なります。詳しくはMDMベンダーに確認しておくのが良いでしょう。(弊社がよく利用するBizMobileでは毎日深夜2:00頃とされています)

一方ユーザ(従業員)から「間違って削除してしまった…」と連絡があった場合は、その都度MDMから当該端末を「同期」してあげれば数秒後に再インストールされます。

なお当然ながら、自動手動に関わらずアプリ内に含まれていたデータは復旧しませんので注意して下さい。

 

以上、ライセンス購入したカスタムAppのアップデートと再インストールについて解説しました。次回はもうひとつのカスタムApp配布方法である「引き換えコード」を使った場合の、アップデートと再インストールについて解説します。

2021.4.26

カスタムApp(CustomApp)とは何か(8) 〜業務用アプリを配布しても良い範囲〜

カスタムAppを提供しても良い範囲はどこまでなのでしょうか。

カスタムAppには、MDM連携するライセンス配布と引き換えコードによる配布と2種類があります。

前者はともかく、後者の引き換えコードの場合はコードやURLを配布すれば誰にでもカスタムAppを提供できますから、業務に全く関係のない人に配布しようと思えばできてしまいます。ただ、さすがにAppleがそれを許容する筈もなく、カスタムAppには配布対象制限が設けられています。

そこで本稿では Apple Business Manager の利用規約を読み解き、カスタムAppの配布可能範囲について考察してみたいと思います。

なお本記事の内容は、Apple Buisness Manager Agreement についての弊社解釈を記すものです。必ず自社で利用規約を確認し、法律に詳しい専門家にも確認の上で最終判断を行うようにして下さい。

 

Apple Business Manager 利用規約の入手方法

まず利用規約の入手の仕方をおさえておきましょう。ABMの利用規約は過去分に遡っていつでもPDFを入手できるようになっています。ABMにサインインして、[設定]→[契約情報]→[利用規約] の順にクリックして一覧を表示して下さい。


(過去にABM上で同意した利用規約が全てPDFで入手できる)

一覧の中から Apple Business Manager 利用規約 をクリックするとPDFで入手できます。一覧下にスクロールすると過去に同意した分まで確認できますが、一番上の新しいものだけで十分です。

日本語で書かれていますがPDF後半には英語での原文があります。以下では日本語部分のみを引用しながら解説しますが、原文も併せて確認することが推奨されます。

 

利用規約の1ページ目に結論が書いてある

身も蓋もないのですが、利用規約を読み進めると最初のページいきなりこんな記述が飛び込んできます。

「契約」とは、このApple Business Manager契約を意味します。明確性のために明記すると、
このApple Business Manager契約はApple Device Enrollment Program契約の後継となる契約です。

実は、もう規約上でABMはADEPの後継であると明記されているのですね。よって、配布対象の制限も同じと考えるのが自然です。ADEPでは契約主体企業の従業員や業務委託者にしかアプリを使わせてはいけないのでした。であれば同じ解釈で、カスタムAppの配布可能範囲もまたABM利用主体企業の従業員や業務委託者に限定される筈です。

さすがに「後継です、以上!」の説明しかないわけではありませんので、配布可能範囲について書いている箇所を以下で詳しく見てみたいと思います。

 

利用規約を読み解く

カスタムAppの配布可能範囲に言及があるのは「2.6 コンテンツの購入」です。

本サービスではコンテンツの取得が自動的に無効化され、お客様による利用には、
アプリケーションとブックを利用する前に本サービスにおいて提示されるVolume Contentの利用に関する要件
および諸条件が適用されます。

お客様は、お客様の管理者に購入権限を付与し、Appleの Volume Purchaseの諸条件へのアクセスを許可して、
本サービスの一環として利用および管理のためのコンテンツを購入できるようにすることにより、
当該管理者が本サービスを介してコンテンツにアクセスできるようにすることを選択できます。

お客様は、こうした購入および適用される諸条件の遵守について単独で責任を負います。
お客様が本サービスの一環としてコンテンツを購入する場合、
お客様は、お客様がお客様の正規ユーザーに代わってそうした諸条件を受諾する権限を有していること、
およびそうした条件を受諾することに同意するものとします。

ここでいうお客様はABMの利用者のことですが、最後の一文に「正規ユーザーに代わって諸条件を受諾する」とあります。ABMでは情シス等の部門担当者が、従業員ユーザの代わりにカスタムAppを一括購入して配布することになるため、このような書き方になっています。

ということは、代わられることになる「正規ユーザー」が、コンテンツ(つまりアプリ)を配布する対象を示していると言えそうです。では「正規ユーザー」とは誰でしょうか。利用規約のp.2には以下のように定義されています。

「正規ユーザー」とは、お客様の会社もしくは組織の従業員および外部契約者(もしくはサービスプロバイダ)、
またはお客様の認可事業体の従業員および外部契約者を意味し、
お客様が病院である場合、「正規ユーザー」の用語には認定医、紹介元となる医師および臨床医も含まれます。

正規ユーザーとは、まず従業員か外部契約者とあります。これにより、

  • 企業が雇用する正社員・非正規社員
  • 企業が雇用するアルバイト
  • 企業が業務委託する個人事業主

などが含まれることになると解釈できるでしょう。組合系組織や合同会社の場合は雇用という関係性が無い場合がありますが、その場合は組織の構成員や所属する人員まで解釈を拡大しても問題ないでしょう。いずれにしてもABM利用企業の「身内」に限定されるというわけです。

NGケースとなる例をあげると、ある製品の販売支援アプリを製品開発企業が開発し自社のABMを介してカスタムAppとして販売代理企業のスタッフに使って貰う….といったケースでしょう。販売代理企業の従業員は、製品開発企業の「正規ユーザー」に含まるとは考えにくく、ADEPと同様にNGと考えるのが妥当です。(参考 → ADEPの契約ができないパターン集)

ただ、「正規ユーザー」に「認可事業体の従業員および外部契約者」も含まれるという定義は、カスタムAppの配布可能範囲を広げる可能性があります。「認可事業体」とは何でしょうか。同じく利用規約のp.2に定義されており、

「認可事業体」とは、(a)お客様が⾃動⾞メーカーである場合は、お客様の正規ディーラーお
よび認定サービスパートナーのことを、(b)お客様がホテルの持株会社である場合は、お客様
の名称、商標、もしくはブランド(またはその持株会社が所有もしくは管理している名称、商
標、もしくはブランド)の下で運営されているホテル資産のことを、または(c)Appleがその単
独の裁量により書⾯で承認することのあるその他の類似する事業体を意味します。

とされています。

(a)(b)はまさに販売代理店的な位置づけとして期待されるものですね。ただ自動車業界とホテル業界についてのみ明示的に許容されているだけであり、残念ながら該当しない事業の場合は (c) 該当となるようAppleの承認を求める必要があります。

実はこの(a)〜(c)も最新のADEP契約書と同じ記載なのですが、開発するカスタムAppが自動車業界とホテル業界に関係する場合は、カスタムAppの配布可能範囲を広範囲に解釈できる可能性があります。

 

以上、カスタムAppの配布可能範囲について解説しました。

原則は ADEP と同じであり、ABM利用主体の企業の従業員や業務委託者にしか使わせてはいけないということです。カスタムAppの多くはMDM連携して管理デバイスに配布されますから、おのずから従業員や業務委託者以外には配布されにくくなっていますが、引き換えコードを使って配布する場合には注意が必要でしょう。

なお冒頭の繰り返しになりますが、ご紹介した解釈はあくまで弊社による解釈ですので、各エンドユーザ企業におかれてはABM利用規約の英語原文も確認のうえで最終判断されるのが良いでしょう。

2021.4.19

カスタムApp(CustomApp)とは何か(7) 〜カスタム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への確かな理解で計画的なアプリ開発をしたいものですね。

本サイトはACNメンバーの(株)フィードテイラーが運営するエンタープライズiOS情報サイトです

最近の投稿