For years I shipped almost exclusively to iOS. Android was always on the "someday" list — not because I doubted the platform, but because the iOS build-and-review rhythm was muscle memory, and learning a second one felt like a cost I couldn't size.
Rork removed that excuse. The same prompt produces code for both platforms. What's left is store paperwork.
Then I actually shipped one of my wallpaper apps to Google Play, and the surprise wasn't the code at all. It was how differently the two stores think about distribution. Here's what tripped me up, and what I'd want to know before starting.
The Artifact Itself Is Different (IPA vs. AAB)
This one blocked me before I wrote a line of config. The App Store takes an .ipa. Google Play will not accept an APK for a new app — it requires an Android App Bundle (.aab). New-app APK submissions were retired back in August 2021.
With Rork (Expo under the hood), you control this through EAS build profiles.
| Purpose | Profile setting | Artifact |
|---|---|---|
| Sideload onto a test device | "buildType": "apk" | .apk |
| Upload to Google Play | "buildType": "app-bundle" (default) | .aab |
// eas.json
{
"build": {
"preview": { "android": { "buildType": "apk" } },
"production": { "android": { "buildType": "app-bundle" } }
}
}Keeping these as two separate profiles removes the ambiguity: verify on a real device with the preview APK, submit the production bundle. I learned this the slow way, by trying to upload the APK I'd just installed on my own phone.
One consequence of AAB worth knowing: Google Play serves only the density assets each device needs. That's efficient, but if your drawable configuration is loose, images can vanish on specific devices — I wrote up that failure mode in fixing missing images from Play Store density splits.
New Personal Accounts Face a 12-Tester, 14-Day Gate
There's no App Store equivalent to this, and not knowing about it will push your launch back by two weeks.
Personal Google Play Console accounts created on or after November 13, 2023 must run a closed test before they can publish to production. The requirement: at least 12 testers opted in continuously for 14 days. Only after that can you apply for production access from the Play Console dashboard.
Two details that catch people out:
- If a tester opts out partway through, the streak breaks. The 14 days must be continuous.
- The requirement applies per app. Clearing it once doesn't exempt your next release.
Organization accounts, and personal accounts created before November 13, 2023, are exempt. My account predates the rule, so I haven't been through it myself — but of everything on this list, it's the one most likely to blindside someone starting today. Block out the 14 days on your calendar before you write the store listing.
Review Is Fast — But Inspection Never Stops
Google Play often publishes faster than the App Store; hours to a day is common, though multi-day reviews have become more frequent recently.
The speed is only at the entrance. Google Play runs continuous policy checks after publication, and apps can be suspended post-launch when something is flagged — ad configuration and permission declarations are the usual culprits. "Passed review" means the initial check passed, not that you're safe indefinitely.
There's also an annual obligation that has no App Store counterpart: the target API level requirement. Miss the deadline and your app stops being served to new users. Existing installs survive, but you can't ship updates — which is the worse half of that sentence. I broke down how the deadline differs depending on whether you're actively updating in what the target API 36 deadline actually means.
Rork's generated Expo code is solid, but ad setup and permission declarations are worth auditing by hand. For ATT specifically, fixing ATT permission not showing covers the usual pitfalls.
Privacy Disclosure Is a Separate Form, Not a Copy-Paste
I assumed I could transcribe my App Store privacy answers into Google Play. The categories and granularity don't line up, and I ended up filling the form from scratch.
Google Play's Data safety section asks what you collect, why, whether it's shared with third parties, whether it's encrypted in transit, and how users can request deletion. Leave it incomplete or inconsistent and you get rejected — see fixing a Data safety rejection.
The practical shortcut: inventory what each SDK collects before you open either form. Write down your ads SDK, analytics SDK, and crash reporter in a single table, then fill both stores from that. It turns two separate research tasks into one.
Rollout Control Is Where Google Play Pulls Ahead
The App Store has phased release. Google Play's staged rollout is meaningfully more granular: start at 1%, watch your crash rate, expand to 5%, 20%, 50% — and if something looks wrong, halt the rollout and replace it with a fixed build.
Shipping AI-generated code, that control mattered more than I expected. Even when I hadn't fully read every line Rork produced, I could put it in front of 1% of users and watch Play Vitals for crash rate and ANR rate before going wider.
The other Play-only gift is the pre-launch report. Upload your .aab and Google runs it on real devices, returning crash, accessibility, and security findings. For an indie developer without a device lab, that's close to free hardware testing.
Search Works on Opposite Principles
On the App Store, the title and the 100-character keyword field drive search. The description is essentially not indexed.
Google Play inverts this. The long description (up to 4,000 characters) is fully indexed — much closer to web SEO than to App Store ASO.
App Store ASO priority:
Title (30 chars) > Keyword field (100 chars) > Subtitle (30 chars)
Google Play ASO priority:
Title (30 chars) > Short description (80 chars) > Long description (4,000 chars, fully indexed)When I rewrote my wallpaper app's long description — keeping it readable while working target keywords in three to five times — organic search traffic rose noticeably within two weeks.
Coming from iOS, it's easy to treat the description as pure persuasion. On Google Play it has to persuade and signal relevance. For the App Store side of keyword planning, see maximizing the 100-character App Store keyword field.
Two Fields the App Store Simply Doesn't Have
Short Description is 80 characters, shown before a user expands the listing, and indexed for search. It's one of the most neglected fields in indie listings, and one of the cheapest to improve. My rules when writing one:
- Include one or two words your target users would actually type
- Communicate the core value in a single thought
- Rewrite until it fits 80 characters without feeling truncated
For a wallpaper app: "Beautiful daily wallpapers that make your phone screen feel personal." Keyword present, value clear. Thirty minutes of work.
Feature Graphic is a 1024×500 banner. It appears prominently wherever Google Play features your app — and without one, you aren't eligible to be featured at all. I discovered this after my first Android release and added it retroactively. Now it goes on the screenshot-production checklist so it can't be forgotten.
Rating Distribution Seems to Matter More (An Observation)
Both stores factor ratings into ranking. On Google Play, the share of 5-star ratings appears to carry more weight than the raw average.
Across several of my apps, a 4.2 average with a heavy 5-star concentration has tended to outrank a 3.8 average at comparable download volumes. That's my observation, not a documented Google signal — treat it as a hypothesis worth testing, not a rule.
The actionable part is prompt timing: ask after the user has experienced your app's core value, not on first launch.
import * as StoreReview from 'expo-store-review';
// Call after the user has experienced your app's core value
// e.g., after saving 5 favorites, or completing setup
const requestReview = async () => {
// Does this device/OS support in-app review at all?
if (!(await StoreReview.isAvailableAsync())) return;
// Is a store fallback configured? Without it, nothing happens.
if (!StoreReview.hasAction()) return;
await StoreReview.requestReview();
};Most snippets check isAvailableAsync() and call it done. Adding hasAction() lets you detect the "I called it and nothing appeared" case instead of guessing. Both platforms also cap how often the prompt can display, so design your UI on the assumption that calling it may show nothing at all. On timing itself, review count is decided by when you ask, not how you ask goes deeper.
Android Needs Its Own Store Strategy
Rork collapses the engineering cost of supporting both platforms. What it doesn't collapse is store preparation.
Artifact format, testing requirements, privacy disclosure, rollout mechanics, and search behavior — none of those five are solved by code generation. Turn them into a checklist, though, and Android stops being the thing you'll get to someday.
If you're starting today, the order that works: split your eas.json profiles so a .aab comes out of production. If you're on a newer personal account, put the 12-tester, 14-day window on the calendar next. Then use that waiting period to finish the Short Description and Feature Graphic — turning dead time into launch prep.
If you're heading toward monetization, Google Play subscription offers for reducing churn picks up where this leaves off.
Thanks for reading. If this saves you a detour between the two stores, it was worth writing.