はじめに
Apple Developer Enterprise Programの更新がほぼほぼの企業でできなくなり
一般企業でのin houseなどの配信が難しくなりました。
ただ、テスト端末へのアプリ配信はアプリのデバッグ用に必要のため
アプリ配信などで現状使用している配信手段を整理してみます
※Apple Developer Program については加入前提としています
Test Flight
Apple公式の配信手段で、AppStoreConnectにアプリを作成しArchiveしたビルドデータをストアに送ることで使用可能
公式だけあり、クラッシュを含む機能が便利
また審査も入るため、ストアリリース前にリジェクト内容があった場合の確認が可能
メリット
- Apple公式の配信手段
- Storeにデータをアップロードすることで使用が可能
- ストア未公開状態でも使用可能
- ストアリリース前にリジェクト理由を知ることができる
- メールアドレスのみで配信可能
- メールアドレスの種類をグループとして管理が出来、まとめての送信が可能
- 配信上限は10,100
- 内部テストユーザー 100名（審査前のテスト可）
- 外部テストユーザー 10,000名（審査後のみテスト可）
- テスター端末からフィードバックを送ることで、クラッシュや現象のスクリーンショットをもらうことが可能
デメリット
- 審査が入る
- バージョン変更 (1.0 → 1.0.1など) ごとにストア申請並の審査が入る※同バージョンのbuildNumber違いは審査がほぼ無い
- 非公開APIや落ちるようなアプリは審査で落とされる可能性が高いので、実験的アプリでは使用しづらい
- コマンドで送ることも可能でjenkinsなどを使って自動化も可能だが、配信についてはAppStoreConnectにアクセスする必要有
- テスト期間が有り、配信開始から90日のみ
- ストアに送信する関係上App Identifierを作成する必要有
FirebaseDistoribution
FireBaseの配信手段
Ad Hocのipaファイルを作成しアップロードすることで配信が可能
Ad Hocのため、テスト用の端末を事前にすべて登録をしてProvisioningProfileを作成してビルドする必要が有る
CLIが用意されておりコマンドで操作し配信まで自動化することが可能
メリット
- 審査なしでアップロード後すぐに配信が可能
- 証明書の期限は有るが、テスト可能な日数の期限は無い
- Crashlyticsなどの機能を入れてテスターのクラッシュ情報を確認することが可能
- テストアプリなどもipaさえ作れれば配信が可能
- Gmailアドレスのみで配信可
- メールアドレスのグループ化をして管理が出来、まとめての送信が可能
- CLIがあり、配信まで自動化も可能
- App Identifierをワイルドカードにしても使用可能
デメリット
- 基本はAd Hoc配信になるため、テスト端末をすべて登録しておく必要有
- Crushを知るためにCrashlyticsなどを入れる必要があり、アプリサイズが若干大きくなる
- テスター用にGoogleアカウントの作成が必要
- テスター端末でプロファイルのインストールが必要
- Deviceを登録する関係上最大で各デバイス（AppleTV,iPad,iPod,AppleWatch,iPhone）で100ごと
最後に
ここに記載した配信方法に関しては、現状使用しているものに絞っています
この他のアプリ配信方法で言えばdeploygateや
Webページを用意してAd Hoc用のPlistとipaをアップロードし配信する方法もあります。
Webページを用意する系（一般的なAd Hoc）の配信方法は、インストール中に途中で止まり一生消せないアプリとして存在するバグなどが昔に多数起こって苦い思いをしたので自分からはオススメし辛いです。