コードに設定を書かない、デフォルト設定で出荷、OTA アップデートを許可する

GitHub で編集する

アプリの設定とはデプロイ（App Store、TestFlight、ローカル開発）の間やコードの変更なしに時間経過で変更される可能性があるすべてのものです。これは次のものを含みます。

  • バックエンドサービスの API キー（内部サービスと外部サービス）
  • リモートリソースの URL（アプリで使う API)
  • 機能トグル（Feature toggles）

アプリはコードに定数として設定を保存することがあります。これは「コードから設定を分離する」という iOS-factor に反するもので、コードから設定を厳密に分離する 必要があります。設定はデプロイをまたがって大きく異なりますがコードはそうではありません。

アプリケーションがコードからすべての要素を正しく抽出したかどうかを確認するためのリトマステストは、いずれの認証情報も損なうことなくコードベースをいつでも公開することができるかどうかです。

ビルド時に設定を注入する方法はたくさんあります。

  • 設定ファイル（例: JSON や YAML ファイルなど）
  • キーを隠してビルド時に iOS アプリに適用するための cocoapods-keys
  • カスタムビルドソリューション（例: Build Phases の使用など）

iOS プラットフォームでのデプロイはサーバーのデプロイより著しく遅いため、すばやく問題に対応するためには OTA で設定をすばやくアップデートする方法が必要な場合があります。

OTA での設定アップデートはパワフルですばやくできます。

  • A/B テストを実行して特定の機能や UI 変更を一部のアクティブユーザーに対してのみ有効にする
  • API キーをローテーションする
  • Web ホストや変更された URL をアップデートする
  • リモートで機能を無効にする、ボタンを隠す

OTA アップデートなしでは、アプリの審査で1日ほど待つ必要があります。またリジェクトされて緊急リリースが遅れるリスクもあります。

同時に、下位互換性が必要な場合もあります。最新の iOS バージョンにアップグレードできないユーザーは、アプリのアップデートをまったくインストールできない可能性があることを意味します。 特定の OTA アップデートを提供することによって、古いバージョンのアプリをサポートし続けることができます。

OTA での設定アップデートを実装するときのポテンシャルアプローチ：