App Store & Play

概要

モバイルアプリを出荷するということは、コードを書く以上のことを意味します。署名し、パッケージ化し、審査に提出し、Apple の App Store と Google Play に公開しなければなりません。各ストアには独自の開発者アカウント、署名システム、メタデータ、審査プロセスがあります。Apple はプロビジョニングプロファイルを伴う App Store Connect と、ベータテスト用の TestFlight を使います。Google はアプリ署名と段階的ロールアウトを備えた Play Console を使います。これは、ビルドを人々がインストールできるものへと変える最後の一マイルです。

強み

圧倒的なリーチ — この 2 つのストアは、数十億のユーザーがアプリを発見し信頼する手段です。
配信、決済、アップデート、クラッシュレポートを標準で備えています。
安全なプレリリースのためのベータチャネル（TestFlight、Play の内部/クローズドテスト）。
段階的ロールアウトと、不具合のあるリリースを停止する能力。

トレードオフ

審査は遅いことがあり、ポリシーやガイドラインを理由にときおりリジェクトされます。
Apple の年間開発者料金と Google の一度きりの料金。どちらも売上から手数料を取ります。
署名、証明書、プロビジョニングは扱いが面倒で、設定を誤りやすいです。
2 つの別々のパイプライン、メタデータのセット、ストア掲載情報を維持する必要があります。

使うべきとき

すべてのコンシューマー向けモバイルアプリは、いずれこれを通過します。早めに計画しましょう。アプリ名を予約し、両方の開発者アカウントを設定し、各リリースが手作業の慌ただしい作業にならないよう、自動ビルドを整えておきましょう。

バイブコーディングとの相性

ここは AI アシスタントが最も多くの面倒を省けるところです。署名、バージョニング、アップロードが 1 つのコマンドで済むよう、Fastlane や Expo の EAS Submit のようなツールでリリースをスクリプト化するようモデルに依頼しましょう。ストアのメタデータ、スクリーンショットの仕様、リリースのチェックリストを生成させ、リジェクトが起きたときにはその理由を平易な言葉で説明させましょう。繰り返しの部分を自動化し、ポリシーの判断は人間に任せておきましょう。

# Expo: build and submit to both stores
npx eas build --platform all
npx eas submit --platform ios
npx eas submit --platform android