「EAS Build で TestFlight に上げたら、本番ビルドが開発用 API に繋がっていた」— こういうミスは、Rork Max でアプリ開発を始めて間もない頃に一度は体験するのではないでしょうか。私自身も最初の頃、development プロファイルでビルドしたものをそのまま App Store Connect に送ってしまい、Stripe のサンドボックス API が動く「本番アプリ」をリリースしてしまいそうになりました。
EAS Build のプロファイルは、Rork Max でネイティブアプリを作る上で避けて通れない仕組みです。でも「なんとなく動いているからいい」で済ませていると、リリース直前に大きなミスに気づくことになります。プロファイル切り替えで実際によく起きる問題を症状ごとに整理し、対処法を順を追って整理していきます。
EAS Build プロファイルの3つの役割を整理する
まず eas.json に定義されるデフォルトの3プロファイルを整理します。それぞれ用途が明確に違います。
// eas.json（Rork Max が生成するデフォルト設定）
{
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"preview": {
"distribution": "internal"
},
"production": {
"distribution": "store"
}
}
}- development: Expo Go なしで動く開発用クライアント。デバッガーが使えますが、App Store には提出できません
- preview: TestFlight や内部テスト向けのビルド。production に近い動作をしつつ、審査なしで配布できます
- production: App Store / Google Play に提出するリリースビルド。コードが最適化され、開発用の設定は除外されます
最重要なポイントは developmentClient: true の有無です。development プロファイルには Expo の開発クライアントが含まれるため、ファイルサイズが大きく、App Store に提出するとリジェクトされます。見た目は同じアプリでも、プロファイルが違えば挙動も配布先も大きく変わります。
トラブルパターン1: 環境変数が意図したプロファイルで反映されていない
「EAS Build したのに、API エンドポイントが開発用のままだ」— よくある症状です。
原因の多くは eas.json の env 設定が抜けているか、ローカルの .env ファイルとの競合にあります。EAS Build では、環境変数を以下のように各プロファイルごとに明示的に設定する必要があります。
// eas.json — プロファイルごとに環境変数を定義する
{
"build": {
"development": {
"developmentClient": true,
"distribution": "internal",
"env": {
"APP_ENV": "development",
"EXPO_PUBLIC_API_URL": "https://dev-api.yourapp.com"
}
},
"preview": {
"distribution": "internal",
"env": {
"APP_ENV": "preview",
"EXPO_PUBLIC_API_URL": "https://staging-api.yourapp.com"
}
},
"production": {
"distribution": "store",
"env": {
"APP_ENV": "production",
"EXPO_PUBLIC_API_URL": "https://api.yourapp.com"
}
}
}
}Rork が生成するコードでは process.env.EXPO_PUBLIC_API_URL のような形で環境変数を参照していることが多いです。EXPO_PUBLIC_ プレフィックスが付いた変数はクライアントサイドでも参照できますが、ビルド時に静的に埋め込まれる点に注意が必要です。つまり、ビルド後に環境変数を変えても、再ビルドしないと反映されません。
確認方法としては、デバッグ用に一時的に Text コンポーネントで process.env.APP_ENV を画面に表示させることをおすすめします。どのプロファイルでビルドされたかを視覚的に確認できます。
トラブルパターン2: 本番ビルドで Stripe のサンドボックスキーを使っている
リリース後に「ユーザーから課金されない」という報告を受けて調べると、本番ビルドがテスト用の Stripe キーを使っていた— これは実際に起きると非常に痛い問題です。
Stripe キーのような機密情報は、eas.json に平文で書かず EAS シークレットとして登録します。
# EAS シークレットに本番 Stripe キーを登録する
eas secret:create --scope project --name STRIPE_PUBLISHABLE_KEY --value pk_live_YOUR_KEY
eas secret:create --scope project --name STRIPE_SECRET_KEY --value sk_live_YOUR_KEYEAS シークレットに登録した値は、ビルド時に自動的に環境変数として注入されます。これにより、開発者がローカルに秘密鍵を持たなくても、本番ビルドに正しいキーが埋め込まれます。
Rork の AI にコードを生成させると、Stripe キーをソースコードにハードコードしてしまうことがあります。コードレビュー時には pk_test_ や sk_test_ がソースに直書きされていないか、必ず確認するようにしています。
トラブルパターン3: TestFlight に development ビルドを送ってしまった
ERROR: Invalid Binary
The binary you uploaded was built for development use only.
このエラーが出たら、development プロファイルのビルドを App Store Connect に送ってしまっています。解決策はシンプルで、preview か production プロファイルでビルドし直すだけです。
# TestFlight 向け（preview プロファイル）
eas build --platform ios --profile preview
# App Store 提出向け（production プロファイル）
eas build --platform ios --profile productionビルド完了後は EAS ダッシュボードでビルドの詳細を確認し、Distribution: Internal または Distribution: Store になっているかをチェックしてから提出しましょう。ひと手間ですが、送り直しのコストを考えると確認する価値があります。
トラブルパターン4: EAS Build と EAS Update を混同している
Rork のプロジェクトを進めていると、EAS Build（ネイティブバイナリの再ビルド）と EAS Update（JS バンドルの OTA 配信）を混同しやすいです。
- EAS Build (
eas build): ネイティブコードを含む IPA / APK を生成します。ネイティブコードや設定が変わるたびに必要です - EAS Update (
eas update): JS バンドルのみをアップデートします（OTA）。高速ですが、JS 層の変更にしか対応できません
EAS Update は素早く反映できますが、ネイティブコードの変更（権限の追加・ネイティブモジュールの追加など）には対応できません。「OTA で更新したはずなのにアプリの挙動が変わらない」という場合、実はネイティブの変更が必要だったというケースがよくあります。
Rork が自動生成するコードがネイティブモジュールを追加していた場合、EAS Update だけでは反映されません。app.json や package.json の変更を伴う場合は必ず EAS Build で再ビルドするようにしてください。
トラブルパターン5: Rork Companion でしか動作確認していない
「Rork Companion では動くのに EAS Build したら動かない」という問題が起きやすい機能があります。
- カメラ / マイク / 位置情報: Companion では権限が共有されるが、独立アプリでは
app.jsonの permissions 設定が必要 - プッシュ通知: Companion 用のプッシュトークンと本番アプリのトークンは別物
- ディープリンク: Companion のスキームと本番アプリのスキームが異なる
リリース前には必ず preview プロファイルでビルドした実機テストを行うことを強くおすすめします。Rork Companion での確認は開発速度を上げるために非常に便利ですが、あくまで「Companion での動作確認」にすぎません。
プロファイル管理に役立つコマンド
# 過去のビルド履歴を確認（どのプロファイルで何をビルドしたか）
eas build:list
# 登録済みの EAS シークレット一覧
eas secret:list
# 現在の EAS 設定を確認
eas build:configureeas build:list は過去のビルド履歴とプロファイルを一覧表示してくれます。「TestFlight に送ったのがどのビルドか」を後から確認するのに役立ちます。
全体を振り返って: プロファイル設計で「間違えにくい」構成にする
EAS Build のプロファイル切り替えトラブルの根本原因のほとんどは、「どのビルドが何のためのものか」が曖昧になっていることです。私がおすすめしているのは、development ビルドに識別子をつける方法です。
// eas.json で development ビルドに suffix を付ける
{
"build": {
"development": {
"developmentClient": true,
"distribution": "internal",
"ios": {
"bundleIdentifier": "com.yourapp.dev"
},
"android": {
"applicationId": "com.yourapp.dev"
}
}
}
}Bundle ID を変えることで、development と production のアプリが端末に別々にインストールできます。アイコンを見ただけに「これは開発用」「これは本番」が一目でわかるようになり、誤ったビルドをストアに出すリスクが大きく下がります。
まずは eas.json の各プロファイルに環境変数を明示的に設定するところから始めてみてください。それだけで、プロファイル切り替えによる多くのトラブルは防げます。