Shipping to the App Store and Google Play: what it takes

Getting a native app into the App Store and Google Play in 2026 is less about writing good code and more about clearing a moving set of gates. Apple reviewed 7.7 million submissions in 2024 and rejected 1.9 million of them, a rejection rate near 25%. Google went further last year and terminated more than 80,000 developer accounts alongside almost 2 million policy rejections. If you treat review as a formality at the end of the build, you will slip your launch date.

This is a practitioner's map of what actually breaks: account setup, the technical floors that rise every year, the metadata traps that catch experienced teams, realistic timelines, and the billing shifts after Epic v. Google. Read it as a compliance calendar, not a checklist.

The scale of the problem: rejection rates and account bans

The 24.7% rejection rate on the App Store is the number to internalise. One in four submissions fails on first pass, and that includes teams who have shipped before. Google's headline figure, 80,000+ developer account terminations in 2025, is the harsher signal: rejection is not the worst outcome. Losing your account, your history and your published apps is. The two stores are converging on enforcement but diverging in method.

Review is not one pipeline. It is a stack of gates: account setup, closed testing, technical checks, metadata, then human review. You need to clear every one, and they do not run in the order you might expect.

Account setup: the gate before the gate

Both stores now do meaningful identity work before you can publish anything. Google began requiring government-issued ID for new individual developer accounts in 2023 and tightened enforcement in 2025, so new accounts must upload ID before their first release. Legal name and address must be accurate. Verification can take hours or days, and any mismatch stretches that further.

If you are reading this before you have written a line of the app, this is the single easiest thing to get ahead on. Set the accounts up now.

Google's closed-testing requirement

The one that catches almost every first-time Android team: if your Google Play developer account was created after 13 November 2023 as a personal account, you must run a closed test with at least 12 opted-in testers for 14 continuous days before you can push to production. Google cut the threshold from 20 testers to 12 in December 2024, but the 14-day clock is not negotiable. Organisation accounts are exempt.

This gate alone can push a launch by two weeks if you did not know about it. Recruit testers early. Real people with real Google accounts. Family and colleagues count, but they need to actually opt in through the tester link.

When you must register as an organisation

Google now requires organisation registration for developers offering financial products and services, health services, VPNs and government services. If your app touches any of those categories, do not attempt to publish under an individual account. You will be blocked, and you may burn the account in the process.

An organisation account is also the cleanest way to sidestep the closed-testing requirement for teams that are legitimately incorporated. If you are already an entity, use it.

Technical requirements that move every year

Both stores raise the floor on SDK and API level annually. Miss a deadline and you cannot submit. Existing apps in the store usually get a grace period; new submissions do not.

Android API level deadlines through 2027

Google Play required apps to target API level 35 (Android 15) for new submissions from August 2025 and for all existing app updates from November 2025. The Android Developers Blog has confirmed API 36 will be required in August 2026 and API 37 in August 2027. If you are scoping a build now, target the next floor, not the current one. Shipping to the current floor is technical debt at commit one.

Two other Android specifics worth flagging. Google Play only accepts Android App Bundles (.aab), not APKs, and every build must be signed with an upload key and release key. Separately, 16 KB memory page size support became a requirement from November 2025. Native libraries compiled against 4 KB assumptions will fail on newer devices, so check every SDK in your dependency graph.

SafetyNet is also gone. Google retired the SafetyNet Attestation API in June 2024. If your app still calls it, you get no response. The replacement is the Play Integrity API, which is what any fintech, identity or anti-fraud product now needs to be built against.

iOS SDK and privacy manifest obligations

All iOS submissions must be built with the iOS 26 SDK or later from 28 April 2026. That is a hard cutover, not a soft warning.

The bigger change on iOS is the privacy manifest. Since May 2024, any iOS app that uses a "required-reason" API or bundles a listed third-party SDK must ship a PrivacyInfo.xcprivacy file declaring the data types collected, the third-party SDKs and their purposes, and approved reasons for each required-reason API call. In practice almost every app is in scope, because almost every app uses at least one listed SDK (analytics, crash reporting, ad networks) or a required-reason API (file timestamps, user defaults, disk space).

If you are early enough to make architecture decisions, the choice between cross-platform and native has real compliance implications. Our take on that trade-off is in React Native vs native in 2026: how to choose.

Why metadata kills more launches than bad code

Here is the counter-intuitive part. Guideline violations account for about 40% of App Store rejections; bugs and crashes account for about 30%. The rejections that surprise teams are almost never about broken code. They are about metadata.

The recurring offenders: a missing or too-generic privacy policy link, screenshots that show features not in the shipped build, screenshots at the wrong dimensions, an app description that oversells or references competitors, an unclear paywall, unlicensed content in demo data, a "sign in" screen behind which reviewers cannot see anything. Give them test credentials in the review notes.

The Play Store listing has hard limits: 30-character title, 80-character short description, 4,000-character full description, a 512×512 icon and a 1,024×500 feature graphic, 2 to 8 screenshots. Get those wrong and the review does not start.

Treat metadata as an engineering deliverable. Screenshots should be generated from the actual build, not marketing mockups. The privacy policy needs a stable URL, hosted somewhere you control, and it needs to match the data declarations in your manifest and data-safety form. Review notes should include working test credentials and a short paragraph explaining how to reach the main flow. Reviewers have minutes, not hours.

The teams that ship on time are the ones who write the App Store description before they write the code.

Two other metadata mines worth calling out. Apps using external AI services must disclose and get consent, and Google's July 2026 policy clarification extended limited-use, disclosure and consent requirements to third-party AI integrations. And if you target the EU, the European Accessibility Act has been in force since 28 June 2025, so accessibility is no longer aspirational. Our guide on designing for accessibility (WCAG AA) from the first screen covers that from a design perspective.

Get plain-English guides like this in your inbox.

One short email a month. WordPress, Shopify, SEO, no fluff. Unsubscribe in one click.

Email address

Website

Subscribe →

We never share your email.

Review timelines: what to actually put in your launch plan

Apple's average review is 24 to 48 hours, and they claim 90% clear within 24 hours. Google Play tends to be faster for established accounts, often under 24 hours for updates, but new-developer reviews run 3 to 7 days and policy-triggered reviews can stretch to 7 business days.

The real risk is not the first review. It is the second. A rejection resets the clock, so a same-day rejection on Apple followed by a fix and resubmission still costs you another 24 to 48 hours. Two rejections and you are a week late.

Practical planning buffer:

• Apple: 5 to 7 days end-to-end, accounting for one rejection cycle.
• Google Play: 10 to 14 days if the account is new or you have any listing changes.
• Add 14 continuous days on top for the closed-testing gate if you are on a personal Google account.

Large feature releases and UI overhauls face deeper scrutiny on both stores. Apple re-tests new APIs and major UX changes almost like a new app; Google re-checks monetisation, ads and privacy. A single new SDK can trigger a full review even on a mature app. This matters for how you plan release cadence, and it is one reason we recommend tightening initial scope. Our approach to that is in how to scope an MVP that ships in weeks.

The billing and payments landscape after Epic v. Google

On 12 September 2025 the Ninth Circuit upheld the injunction in Epic v. Google. From 29 October 2025, Google cannot prohibit US-distributed apps from telling users about external pricing or availability, and cannot require the use of Google Play Billing.

This is a genuine shift for subscription and commerce apps, but only for US users. Outside the US, Google Play Billing remains the default. Apple's equivalent rules are stricter, and the EU DMA is pulling policy in a third direction. The net effect for anyone with an international audience is a dual-path (or triple-path) compliance model: US flows can point users to your web checkout; non-US flows generally cannot.

Do not assume the injunction's language applies globally. Read the country-by-country policy pages, and if you monetise cross-border, budget engineering time for gated purchase flows keyed by user region.

Apple still rejects apps that route users to external purchase flows for digital goods without using in-app purchase in most cases, and it will reject apps with unclear pricing terms. If your paywall does not spell out what the user is being charged for and how to cancel, expect a rejection.

Building a compliance calendar, not a one-time checklist

Submission is not a launch task. It is a recurring product concern. The API level rises every August. The iOS SDK rises every spring. Privacy manifests get new required-reason categories. Accessibility rules widen. The billing landscape is still shifting in the courts.

A workable compliance calendar for a mobile product includes:

• A quarterly review of the Android target API against the next deadline, so you upgrade before the cliff.
• An iOS SDK upgrade slot scheduled before each April cutover.
• A dependency audit twice a year against the manifest and data-safety declarations.
• A metadata review before every major release: screenshots, description, privacy policy, review notes.
• A regional billing check whenever a new market goes live.

We do this for the mobile app development work we ship, because the alternative is fire-fighting a store rejection three days before a launch we already committed to. Compliance is cheaper as a habit than as an emergency.

If you are staring down a first native launch and the moving parts above feel like a lot, talk to us about your app. We ship native and cross-platform mobile work with the compliance calendar built into the roadmap, not bolted on at the end.