2021.3.22
カスタムApp(CustomApp)とは何か(3) 〜自社アプリのカスタマイズ版を顧客企業に提供する方法〜
前回の投稿で、カスタムAppを申請するパターンが複数あると書きました。以下に表を再掲します。
開発スタイル | ADP契約主体 | カスタムApp申請 | |
---|---|---|---|
(A) | エンドユーザ内製 | エンドユーザ企業 | エンドユーザ企業 |
(B) | 開発会社に外注 | エンドユーザ企業 | エンドユーザ企業 or 開発会社 |
(C) | 既存アプリのカスタマイズ版 | 既存アプリの開発元企業 | 既存アプリの開発元企業 |
本稿では、カスタムApp活用法のパターン(C)について解説します。
カスタムAppは、iOS対応の企業向けサービスのメーカにとって、共通アプリをAppStore公開する以外の新たなアプリ提供方法になりえます。本稿をビジネスモデルを考える参考にして貰えればと思います。
アプリを少しだけカスタマイズしてくれないか
通常、企業向けサービスを提供する場合、ログイン機構を持ったサーバシステムと専用アプリを開発して、アプリはAppStore公開するのが一般的です。
サービス導入を決めてくれた顧客企業には「AppStoreにお客様に共通の専用アプリを公開しているのでダウンロードしてください。サーバとアカウント情報はこれこれです」と案内するのがよくある形態です。
しかしサービス導入を検討してくれている企業から、時々こんなリクエストを受けることがあります。
- アイコンをウチで指定するアイコンやアプリ名にできないか?
- 接続サーバの入力が面倒だから設定済みの専用バージョンを作ってくれないか?
- ◯◯の機能だけをオフにしてくれないか?
アプリとしては基本このままで良いのだけど、ちょっとだけカスタマイズして欲しい…という要望ですね。または逆にメーカ側が、特別な顧客にはアイコンやアプリ名を変えて個別にアプリ提供したいと考える場合もあるかも知れません。こんな時にカスタムAppが役に立ちます。
カスタムAppを使ってカスタマイズ版を申請する手順
カスタマイズ版の申請では、業務用アプリの受託開発パターン(冒頭の表の(A)(B))と違って、メーカ企業側のADPアカウントを使うことに注意して下さい。カスタマイズ版を提供する先の顧客企業がADPを契約する必要はありません。
前回の投稿と一部かぶりますが、以下にカスタマイズ版の申請手順を紹介します。
(1) まず、カスタマイズ版アプリを提供する先となる顧客企業にABMの契約をして貰います。
(2) 顧客企業がABMを使えるようになったら、ABMの [設定]→[登録情報] に表示される組織IDと組織名を教えて貰います。
(3) 次にADPのDeveloper画面です。カスタマイズ版は別の新規アプリとなるため、App ID を新しく作成します。顧客企業名が分かるIDにしておくのが良いでしょう。
(4) さらに AppStore 用の provisioning profile を作成します。ここで (3) で作った App ID に紐づけます。
(5) App Store Connect で新たなアプリを作成します。
(6) アプリ詳細画面で配信設定を非公開にし、(2)の組織IDと組織名を入力して保存します。
(7) Xcodeでターゲットを新たに作成し、(3) で作成した provisioning profile を指定。リソースやロジック・プロジェクト設定等を顧客のカスタマイズ要望に沿って実装または設定します。
(8) ビルドしてアップロードし、App Store Connect で各種メタデータ登録の後に申請します。
以上でカスタムAppの申請は完了、後はAppStore公開アプリと同様に審査待ちとなります。リジェクトされたらAppleからの指摘やガイドラインに沿って対応します。申請が通って Ready for Sale 状態にすると、顧客企業のABMのカスタムAppのページに現れます。
ABM上に表示されたカスタムAppは、この後「MDM」か「引き換えコード」かの2種類の方法で顧客企業が社内で配布します。(カスタムAppの配布方法についてはまた別の記事で紹介します)
以上がカスタムAppを使ったカスタマイズ版アプリの申請手順です。ポイントを整理すると
- 顧客企業にABMの利用申請をして貰い、組織IDと組織名を教えて貰う
- App Store Connect で公開アプリと同様に新規のアプリ登録する
- 配信の設定を非公開にして、組織IDと組織名を入力する (公開アプリとの唯一の違い)
- Xcodeでターゲットを作りバイナリをビルドし分けてアップロードし申請する
となります。
InHouseを使ったカスタマイズ版の提供について
ところで、古くから法人向けアプリを提供しているメーカ企業の中には、顧客にADEP(Apple Developer Enterprise Program)の契約をして貰うことを前提に InHouse アプリとしてカスタマイズ版を提供している場合があります。
運用は以下のようにしている場合が多いでしょう。
- まず顧客企業にADEPを契約して貰う
- メーカ側はエンドユーザ企業の InHouse 用 Provisioning Profile と秘密鍵を入手
- カスタマイズ版をInHouseビルドして ipa ファイルを納品
- エンドユーザ企業がMDMやOTA、有線で社内配信
ただ今はADEPの取得が難しいため、この方法で法人向けアプリを提供しているメーカ企業は、上述のカスタムAppを使った運用に切り替えていくことをお勧めします。
カスタムAppにすると以下のようなメリットもあります。
- お客様のADEP契約コストが不要 (¥37,800/年)
- お客様の秘密鍵を預かるリスクからの開放
- 年に一度のInHouseアプリ再署名や、MDM経由の Provisioning Profile 配信が不要
特に、顧客のMDM導入を前提とせずInHouse版を毎年ビルド提供しているメーカ企業は、カスタムAppによる大幅な工数減が見込めます。(アプリのバージョンアップが頻繁にある場合は余り工数減にはなりませんが)
なお、自社アプリのカスタマイズ版の提供が初めて・未体験、というメーカ企業におかれては、この InHouse アプリを使う方法ではなく、前述のカスタムAppを使った方法で提供するようビジネスモデルを設計して下さい。事前に、自社でABMを使えるようにして一連の流れを確認しておくと良いと思います。
以上、カスタムAppを使って自社アプリのカスタマイズ版を提供する方法について紹介しました。次の記事ではカスタムAppを受け取って社内配布する側について紹介しようと思います。
余談
紹介してておかしな話ですが、メーカ企業側は、できればカスタムAppでカスタマイズ版アプリを提供しないほうが良いです。アプリはAppStore公開版のみとするのがソース管理上も楽だからです。ロジックにまで手が入るとブランチがカオスなことになります。
顧客企業からアプリ名やアイコンの変更を求められた場合はカスタムApp化は避けられませんが、サーバ設定値だけカスタマイズしたい…という設定値だけの変更やロジックの軽微なカスタマイズで済む場合は、カスタムAppより Managed App Configuration を使ったカスタマイズが楽です。これについてはまた別記事で紹介予定です。(MDMベンダーに問い合わせてみるのも良いでしょう)