Apple App Store vs Google Play: how to launch on both from one build

Why launching on both stores matters

The same app reaches a completely different audience on each store. Apple's users skew toward higher spend and the App Store drives strong subscription revenue; Google Play reaches over 2 billion active Android devices and a far larger install base worldwide. Shipping to only one store cuts your reachable audience in half for no good reason. With Expo you build once and submit to both, so launching on both stores is not double the work - it is the same build reaching two audiences instead of one.

One codebase, both stores: the Expo advantage

The old way meant two separate codebases - Swift for Apple, Kotlin for Google - and effectively building the app twice. Expo removes that: you write one React Native codebase and EAS Build produces both an iOS and an Android build from it. EAS Submit then pushes each to the right store. That single-codebase, dual-store pipeline is exactly what makes shipping to both stores realistic for a solo builder. The upside is that every feature you build lands on both stores at once, so there is no reason to launch on just one. Build once, ship to both, keep the one-pipeline edge.

• Apple App Store - higher spend per user, strong subscription revenue, faster review
• Google Play - 2 billion-plus active Android devices, larger global install base
• One Expo codebase - build both iOS and Android from the same React Native project
• EAS Build and Submit - both store builds and submissions from one pipeline
• No Mac required - EAS builds in the cloud for both stores from any computer

How the two stores differ at launch

The stores differ in ways that matter for your launch timeline. Apple's review is stricter and often decides in a day or two, with Guideline 4.3 and privacy rules as the common first-app hurdles. Google's review is generally more lenient on content but adds a hard process step: new personal developer accounts must run a 14-day closed test before production access. Apple's developer enrollment can also take days to verify. Knowing these differences up front lets you start both accounts early so neither store's paperwork becomes the thing that delays your launch.

Google's closed test: the step first apps miss

The biggest difference that surprises first-time builders is Google Play's closed-testing requirement. New personal developer accounts must run a closed test with at least 12 testers for 14 continuous days before they can apply for production access. Apple has no equivalent. This is the single step most builders do not know about until their launch stalls, so start the closed test as soon as your build is ready and line up your 12 testers early - the club works as your tester pool, which turns a two-week wall into a solved step.

Handle each store's rules and fees

Each store has its own compliance and fee profile. Apple uses App Privacy nutrition labels; Google uses the Data Safety form - both must accurately describe your data handling. Both take a 15% cut if you enroll in their Small Business programs, which most first-time builders qualify for, versus 30% if you do not. Both require a privacy policy URL if you collect data. Fill each store's fields correctly and enroll in both Small Business programs, and you keep 85% of revenue while clearing the compliance rules on each side.

Make launching on both the default

Over time, launching on both stores from one Expo build should be automatic, not a decision you weigh each time. Build in React Native with Expo, produce both builds with EAS, submit to both stores, and clear each store's specific rules. The dual-store launch process taught in App Store Launch Club walks you through every account, asset, and answer for both the Apple App Store and Google Play - so you are shipping to both audiences from one codebase instead of relearning each store's quirks app by app.