iOSを主戦場にしてきた期間が長く、Androidへの対応は「そのうちやろう」と思いながら後回しにしていました。iOSの開発と審査フローが身体に染み込んでいて、もう一つのプラットフォームを同時に学ぶコストが見えづらかったのです。
Rorkがクロスプラットフォームのコードを自動で生成してくれるようになってから、その理由は消えました。コードは同じプロンプトから両方出てきます。残っているのは、ストア側の作法だけです。
実際に壁紙系のアプリをGoogle Playにも展開してみて、驚いたのはコードではなく「配布の設計思想がここまで違うのか」という点でした。技術的に詰まったところと、事前に知っていれば回避できたところを整理しておきます。
提出する成果物からして違う（IPA と AAB）
まず、手を動かす前につまずいたのがここでした。App Storeに出すのは .ipa ですが、Google Playの新規アプリは Android App Bundle（.aab） でなければ受け付けられません。2021年8月以降、新規アプリのAPK提出は廃止されています。
Rork（Expo ベース）の場合、EAS のビルドプロファイルで出力形式を指定します。
| 用途 | プロファイル設定 | 成果物 |
|---|---|---|
| 実機に直接入れて確認 | "buildType": "apk" | .apk |
| Google Play に提出 | "buildType": "app-bundle"（既定） | .aab |
// eas.json
{
"build": {
"preview": { "android": { "buildType": "apk" } },
"production": { "android": { "buildType": "app-bundle" } }
}
}preview プロファイルで作った .apk を手元の実機に入れて確認し、提出は production の .aab で行う、という二段構えにしておくと迷いません。私は最初にこの区別を知らず、実機確認用に作ったAPKをそのままアップロードしようとして弾かれました。
AAB になると、端末ごとに必要な解像度の画像だけが配信されます。便利な反面、画面密度の指定が甘いと特定端末で画像が欠けることがあります（Play Store の密度分割で画像が消えたときの対処 にまとめています）。
新規の個人アカウントには「12人 × 14日」の関門がある
これはApp Storeに一切ない概念で、知らないと計画が2週間ずれます。
2023年11月13日以降に作成された個人のGoogle Play Consoleアカウントは、アプリを製品版として公開する前に、クローズドテストを実施する必要があります。要件は、12人以上のテスターが、14日間continuous（連続）でオプトインしている状態を作ること。これを満たしてはじめて、Play Consoleのダッシュボードから製品版アクセスを申請できます。
注意点が2つあります。
- 途中でオプトアウトしたテスターは、その時点でカウントが途切れます。14日は「連続」である必要があります
- 各アプリごとにこのテストが必要です。1本目で通過しても、2本目は改めて実施します
なお、法人（組織）アカウント、および2023年11月13日より前に作成された個人アカウントは対象外です。私は対象外のアカウントを使っているため実体験としては通っていませんが、これから始める方が一番驚くポイントだと思うので、スケジュールに14日間を先に確保しておくことをおすすめします。
審査は速い。ただし「公開後も検査は続く」
提出後の体感速度はGoogle Playのほうが速いことが多く、数時間〜1日程度で公開まで進む場合があります（近年は数日かかるケースも増えています）。
速いのは入口だけで、Google Playは公開後も継続的にポリシーチェックが走ります。特にコンテンツポリシーや広告の扱いは、リリース後に問題が検出されてアプリが一時停止になることがあります。「審査が通った＝安心」ではなく、「ポリシーの維持管理が継続して必要」というのがGoogle Playの実情です。
もうひとつ、Play固有で毎年やってくるのが target API level の年次要件 です。一定の期日までに新しいAPIレベルを対象にビルドし直さないと、新規ユーザーへの配信が止まります。既存の公開は残るものの更新が出せなくなるため、放置すると詰みます（target API 36 の期日は、更新を出す人と出さない人で意味が違います に整理しました）。
Rorkで生成されるコードはExpoベースでしっかりしていますが、広告設定やパーミッションの宣言は自分で確認しておくのが安全です。ATTパーミッションの実装についてはATTパーミッションが表示されない問題の修正も参考にしてください。
プライバシー申告は「別のフォームを一から書く」
App Storeの「Appのプライバシー」を埋めたから、そのままGoogle Playにも転記できる、と考えていました。実際には設問の粒度も分類も違い、書き直しが必要でした。
Google Play側は「データセーフティ」セクションで、収集するデータの種類・目的・第三者共有の有無・暗号化の有無・削除リクエストの手段までを申告します。ここが未入力・不整合だとリジェクトされます（データセーフティ未入力でリジェクトされたときの直し方）。
実務的には、SDKごとに「何を収集するか」を先に洗い出しておくのが近道です。広告SDK・解析SDK・クラッシュレポートの3つを表に書き出してから両ストアのフォームに向かうと、二度手間になりません。
公開の出し方が違う（段階的公開の自由度）
App Storeにも段階的リリースはありますが、Google Playの段階的公開はより細かく制御できます。1%から始めて、クラッシュ率を見ながら5%・20%・50%と広げ、問題があれば公開を停止して次のバージョンに差し替えられます。
Rorkで生成したコードを本番投入するとき、この差は安心感に直結しました。生成されたコードを読み切れていない箇所があっても、1%配信でPlay Vitalsのクラッシュ率とANR率を見てから広げられるからです。
Play固有でもうひとつ助かるのが**事前登録前の「事前公開レポート」**です。アップロードした.aabを実機のファームで自動起動し、クラッシュ・アクセシビリティ・脆弱性の指摘を返してくれます。テスト端末を持っていない個人開発者にとって、これは無料で使える実機テストに近い価値があります。
検索アルゴリズムが根本的に違う
App Storeでは、タイトルとキーワードフィールド（100文字）が検索に影響する主な要素です。説明文は検索インデックスにほとんど使われないと言われています。
Google Playは逆で、ストアの説明文全体が検索インデックスに使われます。特に「長い説明」（4,000文字まで）に、自然な形でキーワードを含める点が肝心です。
App StoreのASO優先順位:
タイトル（30文字）> キーワードフィールド（100文字）> サブタイトル（30文字）
Google PlayのASO優先順位:
タイトル（30文字）> 短い説明（80文字）> 長い説明（4,000文字）※全文が検索対象これはWebのSEOに近い感覚です。壁紙アプリの説明文を整理して、自然な文章の中にターゲットキーワードを3〜5回含めるよう書き直したところ、2週間後にオーガニック検索からの流入が目に見えて増えました。
App Storeに慣れていると、説明文はユーザー向けに読みやすく書けばいいと思いがちです。Google Playでは「読みやすく、かつキーワードが自然に含まれている」という両立が求められます。App Store側のキーワード設計についてはApp Storeキーワードフィールドを100文字で最大化する設計術にまとめています。
Short Description と Feature Graphic — App Storeにない2つの枠
Google Playにあって App Store にないフィールドが2つあります。どちらも軽視されがちですが、費用対効果は高いです。
短い説明（Short Description） は80文字以内。ストアが折りたたまれた状態で最初に表示され、検索にも影響すると言われています。私が書くときに心がけているのは次の3点です。
- ターゲットユーザーが検索しそうな言葉を1〜2個含める
- アプリの「核心的な価値」を一言で伝える
- 80文字に収まるよう、何度も削り直す
壁紙アプリなら「毎日変わる美しい壁紙で、スマートフォンの画面を自分らしく」のような形です。「壁紙」というキーワードを含みつつ、価値が伝わります。作業自体は30分で終わります。
フィーチャーグラフィック は1024×500ピクセルのバナー画像です。Google PlayのTOPやフィーチャー枠で大きく表示され、設定していないとフィーチャーの候補にすら入りません。初回リリース時にこの存在を後から知って慌てて追加したので、いまはスクリーンショット撮影と同じタイミングで必ずセットで作るようにしています。
評価の分布が検索順位に効いている（体感）
App StoreもGoogle Playも、ユーザー評価が検索順位に影響します。ただGoogle Playでは「星5の割合」が特に効いているように感じます。
星3が多くて平均3.8のアプリより、星5が多くて平均4.2のアプリのほうが、同程度のDL数でも検索順位が高い傾向を複数のアプリで見てきました。これは私の観測範囲での傾向であって、Googleが公表している指標ではありません。断定はできない前提で読んでいただければと思います。
打ち手としては、レビュー依頼を出すタイミングの設計が効きます。インストール直後ではなく、アプリの価値を体験した後に出すのが基本です。
import * as StoreReview from 'expo-store-review';
// ユーザーがアプリの核心的な価値を体験した後に呼び出す
// 例: お気に入りを5件以上追加した後、設定を完了した後など
const requestReview = async () => {
// 端末・OSがレビュー依頼に対応しているか
if (!(await StoreReview.isAvailableAsync())) return;
// ストアへのフォールバック導線が用意できているか（未設定なら何も出ない）
if (!StoreReview.hasAction()) return;
await StoreReview.requestReview();
};isAvailableAsync() だけを見て requestReview() を呼ぶ実装をよく見かけますが、hasAction() を挟んでおくと「呼んだのに何も起きない」状態を検知できます。なお両OSとも表示回数には上限があり、呼べば必ず出るわけではありません。この前提でUIを組んでおくと、テスト時に無用に悩まずに済みます（タイミング設計はレビュー数は『お願いの文面』より『出すタイミング』で決まるに詳しく書きました）。
AndroidはiOSと別のストア戦略が必要
Rorkは同じプロンプトからiOSとAndroid両方に対応したコードを生成してくれます。実装面での工数は大幅に下がりました。下がらなかったのは、ストア側の準備です。
提出形式、テスト要件、プライバシー申告、公開の刻み方、そして検索の効き方。ここまで見てきた5点は、どれもコード生成では埋まりません。逆に言えば、この5点を先にチェックリストにしておけば、Androidへの展開は「そのうちやろう」から外せます。
今日から着手するなら、順番はこうです。まず eas.json のプロファイルを分けて .aab が出る状態を作る。次に個人アカウントの方は12人×14日のテスト枠をカレンダーに置く。その待ち時間で、短い説明とフィーチャーグラフィックを仕上げる。待ち時間を作業時間に変えられます。
課金まわりまで進む場合は、Google Play サブスクリプションオファーで解約を防ぎ収益を最大化するも合わせてどうぞ。
お読みいただきありがとうございました。両ストアの違いに戸惑っている方の遠回りが、少しでも減れば嬉しいです。