Rorkでアプリが完成したとき、多くの方が「iOSだけ先に出して、Androidは後で」という選択をされます。私も最初はそうでした。ところが実際に同時公開を試みると、プラットフォームごとの仕様の違いが思った以上に多く、対応に時間がかかりました。
今回は、RorkアプリをApp StoreとGoogle Playに同時リリースした経験をもとに、事前に知っておくと役立つポイントをまとめます。「Rorkが両プラットフォーム対応である」という事実は知っていても、実際の申請フローで何が違うのかは、やってみるまで分からないことが多いです。
スクリーンショットのサイズ仕様が全然違う
まず最初に詰まったのがスクリーンショットです。App StoreとGoogle Playでは、要求される画像のサイズがかなり異なります。
App Storeでは、iPhone用として少なくとも6.7インチ（iPhone 15 Pro Max相当）のスクリーンショットが必要で、iPad対応アプリならiPadのサイズも別途必要です。Google Playは1枚以上のスクリーンショット（最小320px）とフィーチャーグラフィック（1024×500px）の組み合わせが要求されます。
Rork Companionアプリで実機確認したスクリーンショットをそのまま使おうとすると、iPhoneのサイズが6.1インチで、Appleが要求する6.7インチの仕様を満たさない場合があります。Figmaなどでスクリーンショットをリサイズするか、EAS Buildでシミュレータから取得するかのどちらかで対応することになります。
Google Playのフィーチャーグラフィックは多くのアプリで省略されがちですが、Play Storeの検索結果で一覧に表示されるカード部分に使われるため、作っておいた方が見栄えが改善します。
AndroidはTarget SDK Levelに注意する
Google Playに提出するアプリは、Android APIのTarget SDK Level（targetSdkVersion）が一定以上でなければ審査を通過できません。2026年現在、新規アプリはAndroid 14（API Level 34）以上が要件です。
RorkはExpoをベースにしているため、Expoの最新SDKを使っている場合はほぼ問題ありません。ただし、古いバージョンのテンプレートや、しばらく開発が止まっていたプロジェクトでは、targetSdkVersionが古いままになっていることがあります。
EAS Buildでビルドする前に、app.jsonのandroid.targetSdkVersionを確認してください。Rork Maxを使っている場合は、プロジェクト設定から確認できます。
{
"android": {
"targetSdkVersion": 34,
"minSdkVersion": 24
}
}iOSのプライバシーマニフェストは必須
iOS 17以降、Appleはプライバシーマニフェスト（PrivacyInfo.xcprivacy）の提出を必須化しています。カメラ・マイク・位置情報・フォトライブラリなどの権限を使うアプリはもちろん、UserDefaultsを使うだけでもAPIの利用宣言が必要です。
RorkがEAS Buildを通じて生成するネイティブコードは、サードパーティライブラリの宣言を含むことが多いです。App Storeの審査でプライバシーマニフェストの不備を指摘されると、修正して再提出が必要になり、審査期間が伸びます。
対処方法は、EAS Buildの出力ログでプライバシーマニフェスト関連の警告を確認し、必要なAPIを宣言しておくことです。Rork Maxユーザーであれば、Rorkのサポートチャンネルで最新のテンプレート設定を確認するのが早道です。
審査期間の違いを織り込んでリリース計画を立てる
同時公開を目指す場合、审查期間の差がネックになることがあります。
App Storeの審査は通常24〜48時間で完了することが多いですが、初回申請や機能の変更が大きい場合は数日かかることもあります。Google Playの審査は、初回はやや長くかかる印象ですが、2回目以降は公開まで数時間のケースも多いです。
私が経験したのは、iOSが先に審査完了してPublicになってしまい、Androidの審査がまだ続いていた状況です。「同時公開」のつもりが2日差になりました。厳密に同時公開が必要な場合は、App Storeの「審査後に手動でリリース」オプションを使ってiOSの公開日をコントロールするのが現実的です。
Google PlayのData Safety設定はApp Storeと別途必要
App Storeにはプライバシーに関する「App Store Connect」上での質問票があり、Google PlayにはData Safetyフォームが別にあります。内容は似ていますが、設問の切り口が違うため、どちらかを埋めても自動的にもう一方には反映されません。
Google PlayのData Safetyで特に見落としやすいのは「データの暗号化」と「データ削除リクエストへの対応」の項目です。「ユーザーからデータ削除を求められたときの対応方法」を用意していないアプリは、審査でフラグが立つことがあります。
リリース後：クラッシュレポートの確認を両方で行う
無事に両プラットフォームで公開できた後も、iOSとAndroidで別々のクラッシュレポートを確認する必要があります。
App Store ConnectのCrashesタブとFirebase Crashlytics（またはSentry）を合わせて見ると、プラットフォームごとのクラッシュ傾向が分かります。React Nativeベースのアプリは基本的に動作が共通していますが、ネイティブモジュールやOSバージョンに依存する部分ではiOS・Android固有のクラッシュが出ることがあります。
リリース直後の48時間は、両方のダッシュボードを意識的にチェックする習慣をつけると、問題の早期発見につながります。
同時リリースは「2倍の準備」ではなく「1.3倍の準備」
iOS・Android両対応と聞くと大変そうに感じますが、実際には「まったく別の作業が倍になる」わけではありません。コアのアプリロジックは共通で、違いはストア申請素材・権限設定・審査タイミングのコントロールくらいです。
Rorkがクロスプラットフォーム対応を前提に設計されているおかげで、EAS Buildで両プラットフォーム向けのバイナリを生成する手順自体はシンプルです。詰まりやすいのは申請前の準備段階が多いため、この記事で挙げたポイントを事前にチェックリスト化しておくと、スムーズに進められるはずです。
最初の同時リリースは多少手間取っても、2回目以降は要領が分かってくるので格段に楽になります。まずは一本、両プラットフォーム向けに出してみることをおすすめします。