Android is now the harder app store to launch on

If you’re picking a platform to launch a new app on, the old advice says start with Android. It’s the open one. Apple’s the fussy gatekeeper who might knock you back; Google just lets you publish and you sort the rest out later. We followed that logic for years.

It’s wrong now, and it’s been wrong for a while.

Here’s what shipping to Apple actually looks like. You submit the build, a reviewer checks it against the App Store guidelines, and you wait. They’re strict, and they’ll bounce you for things you didn’t think mattered. You fix them and resubmit. Annoying, but it’s one gate, usually hours to a day or two, and once you’re through the app’s live to everyone.

Apple’s rejections are at least legible, too. The reviewer cites a guideline, you can read it, and the fixes are usually mechanical: a missing privacy string, a login flow they couldn’t test, a screenshot that oversells. Two or three round trips is a bad run. Budget a week of calendar buffer for review on a first app and you’ll rarely need it all. The point isn’t that Apple is easy, it’s that Apple is a known quantity, and known quantities can be scheduled.

Google makes you earn it now

Google’s the part that changed, and most people haven’t noticed. Open a new personal developer account today and you can’t release to the public at all until you’ve run a closed test first: at least twelve testers, opted in and keeping the app installed for fourteen days straight. Clear that, and then you get to apply for production access, which is its own review.

The fourteen days are continuous, and people drift. Someone wipes their phone, a couple lose interest and uninstall, and you’re scrambling to top the numbers back up before the count resets under you. We’ve sat and watched that clock tick down. It’s not hard engineering, it’s herding twelve people for a fortnight while the iOS build of the same app is already in the store taking signups.

And the closed test isn’t the finish line. Production access is an application, where Google asks about your testing, your app’s readiness and your plans, and can say no. The whole pipeline for a fresh account, account setup and identity verification, the closed test recruitment, the fourteen days, the production application, its review, runs three to five weeks in practice even when nothing goes wrong. Compare that against the day or two you were budgeting because someone told you Android was the open one.

The catch is who it hits: personal developer accounts opened on or after 13 November 2023. Older accounts and some organisation accounts skip the whole thing, which is half the reason the old reputation’s survived. A lot of the people still saying Android’s the easy one last shipped before the rule existed. This is also why you’ll find developers online insisting the requirement doesn’t exist, it doesn’t, for them. Their account predates it. Yours won’t.

To be fair to Google about the why: the rule exists because Play was drowning in shovelware and scam apps from throwaway accounts, and forcing a fortnight of real testing is a crude but effective filter. The policy has a defensible purpose. It just also has an undisclosed cost that lands on legitimate first-time publishers, and nobody puts it in the brochure.

Where it actually hurts

It hurts most on a first app, which is exactly where a lot of businesses are. You don’t have a pool of users yet. Your twelve testers are your staff, a few mates, and some patient early customers, and they’ve all got to be on Android. That’s meant to be the popular platform, but try rounding up twelve people you know who aren’t on an iPhone. A lot of the people around us are on iPhones, and finding a full dozen Android testers took more chasing than the closed test itself. Nobody flags this at the build stage, and it turns up at launch, which is the worst possible time to find out your public release is two weeks and twelve commitments away.

Fourteen people is the practical target, not twelve, because attrition is certain: someone gets a new phone mid-fortnight, someone’s kid uninstalls it, someone just stops opening their messages. Recruit the spares up front. Make the ask explicit too, install it, keep it installed for two weeks, open it now and then, because “can you test my app?” gets interpreted as a five-minute favour, and an uninstall on day nine costs you the clock.

The account type decision deserves a minute at project kickoff too. Organisation accounts have their own verification hoops, a D-U-N-S number, business documentation, waiting, but they change how the testing requirement lands, and for a business shipping under its own name they’re usually the right call anyway, because an app published from a director’s personal account is a small ownership mess waiting for a resignation or a dispute. Whichever type you choose, choose it deliberately and early; converting later is its own paperwork.

There’s a marketing knock-on as well. A coordinated launch, the email announcement, the social push, the customer who promised to mention you, wants both stores live at once. If nobody planned the Android pipeline, you either launch iOS-only and burn the Android goodwill on “coming soon”, or you hold the whole launch hostage to a fortnight of tester-herding. Both are avoidable with a calendar and some honesty at the scoping stage.

What to do about it

So if you’re planning a build, sort the testers out early and by name, while the app’s still being written, not the week you want to go live. Put the fourteen days in the timeline ahead of your launch date, where they can’t get quietly squeezed when something else slips. And if getting to a real public release quickly is what matters, ship iOS first. The reflex to start on Android because it’s the easy one is left over from a Google Play that doesn’t exist anymore.

Two more moves worth knowing. First, start the Play account the day the project kicks off, not the week before launch; the account setup and verification have their own waiting built in, and the closed test can run on an early build while development continues, the fortnight doesn’t need the finished app, it needs an installable one. Second, check whether you need the public store at all. If the app is for your own staff, a field tool, an internal workflow, private distribution paths skip the public-release circus entirely, and plenty of business apps belong there anyway.

None of this should scare anyone off Android as a platform, to be clear. The install base is enormous, plenty of industries skew Android-heavy, tradies and field crews especially, and for some products it’s where most of your customers are. The argument is narrower: the launch order and the calendar should be decided by the actual 2026 pipeline, not by a reputation Google retired years ago.

We still build for both, and most apps belong on both. It’s just that the Android side now costs you a fortnight and twelve committed people before anyone outside your test group can download it, and a plan that ignores that runs late.

The general lesson travels beyond Google, too: platform rules change quietly and reputations lag them by years, so the launch plan should be checked against the current documentation every time, not against what worked on the last project. The store you shipped through in 2022 is not the store you’ll ship through this year.

If you’re scoping an app and want the launch worked out before you commit a budget, that’s part of how we run app development and custom software projects. Tell us what you’re building and we’ll go through the platform order, the timeline and that testing window with you.