Your app got rejected: how App Store and Play Store releases actually work

When a store rejects your app, the cause is usually not your code. Rejections cluster in three places: a login screen the reviewer could not get past, a feature the store requires but nobody built (account deletion, the right payment method, a data declaration), or a platform deadline that has already passed. Publishing is not the upload you do after the code is finished. It is a separate piece of work with its own calendar, its own owner and its own annual maintenance cost. Apple's own numbers show the scale: in 2025 the App Review team evaluated more than 9.1 million submissions and rejected over 2 million of them, including 1.2 million new apps and nearly 800,000 updates.

The calendar starts when the account opens, not when the code ships

Setting up a company developer account is not an afternoon task. Apple Developer Program membership costs 99 USD a year, and enrolling as an organization means three checks: a D-U-N-S Number for your company, a real legal entity that can sign contracts with Apple (no DBAs, trade names or branches), and a working public website on a domain associated with your organization. Whoever enrolls must have the legal authority to bind the company. Your organization's name also becomes the seller name shown on the App Store, so the entity you enroll with is partly a marketing decision.

Google Play charges a one-time 25 USD registration fee. An organization account there also needs a D-U-N-S Number plus identity and organization verification. Getting a D-U-N-S Number is free, but the request can take days and sometimes weeks to come back. That is not a discovery you want two weeks before launch.

A personal Play account costs you two extra weeks

This is Google's least known and most schedule-breaking rule. Personal developer accounts created after November 13, 2023 must run a closed test before they can apply for production access: at least 12 testers, opted in continuously for at least 14 days. If testers drop out and the chain breaks, the 14 days restart. Once you qualify, you apply for production access in Play Console and describe what the closed test taught you, who your audience is and why the app is ready. Google says that review usually takes seven days or less but can occasionally take longer.

Organization accounts are exempt. If a company is publishing the app, open an organization account from the start instead of shipping from a developer's personal account and trying to transfer it later. Who holds the store account is an ownership question, just like who holds the source code.

The most common rejection: the reviewer could not get in

Apple's guideline 2.1 comes back labelled "information needed", and in practice it usually means one of three things. The demo account you supplied does not work, your backend was switched off, or sign-in requires an SMS code the reviewer has no way to receive. Phone verification at login is common, and it stops review dead.

The fix is a small package you prepare before every submission. Create a permanent demo account, do not rotate its password during review, and make sure it has realistic data in it. If login needs phone verification, wire a fixed test code for that account. Then write the reviewer's path step by step in the Notes for Review field in App Store Connect. Guideline 2.3.1 asks for new features to be described specifically there, and generic descriptions get rejected. If a flow needs hardware, a dealer account or anything else a stranger cannot obtain, say so explicitly.

Features the store makes you build

Some rules are not metadata, they are development work. The two most often missed are account deletion and payments.

Apple's guideline 5.1.1(v) requires any app that lets users create an account to offer account deletion inside the app. Google Play goes further: alongside the in-app path, it wants a web link where a user can request deletion without reinstalling the app, and you must declare all of this in the data deletion questions of the Data safety form. That declaration is shown on your store listing, and you cannot publish updates while the form has unresolved issues.

Shipping a delete button is the easy half. Behind it sits a decision: what data actually gets deleted, what has to be retained for legal or accounting reasons, how the remainder is anonymised, and how invoices stay intact once the account is gone. Teams that treat this as a two-day task and leave it to release week are the teams that slip.

If you sell digital goods, read the payment rule first

Apple's guideline 3.1.1 is unambiguous. Unlocking features, subscriptions, digital content or a "full version" inside the app has to go through in-app purchase. License keys, QR codes and redirects to your own checkout page are not acceptable alternatives. Physical goods and services consumed outside the app are out of scope, so an ecommerce app keeps using its own payment provider.

Where that line falls changes your product economics, because the platform commission changes your margin. Price the mobile tier of a SaaS product with that in mind. The harder engineering problems on the payment side are covered in payment integration and reconciliation.

Wrapping your website does not pass review

Apple's guideline 4.2 asks for features, content and UI that go beyond a repackaged website, and it excludes apps that are mostly marketing material, web clippings, link collections or content aggregators. Guideline 4.3 targets the same app shipped under multiple bundle IDs and apps that are indistinguishable from what already exists. Apple reported rejecting more than 371,000 submissions in 2025 for copying other apps, spam or misleading users.

So the mobile decision comes before the release decision. Do you actually need an app in the store, or would a good mobile web experience do the job? We worked through the criteria in native versus cross-platform.

The deadlines that repeat every year

Store rules move on an annual rhythm, and when that rhythm is not in the maintenance budget, an app quietly becomes unshippable.

• Google Play target API level. Since August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher. Existing apps must target at least API 35 to stay available to new users on newer Android versions; below that, the app is only discoverable on devices running its target level or older. Google allows an extension request until November 1, 2026 for teams that need more time.
• Apple SDK floor. Since April 28, 2026, iOS apps uploaded to App Store Connect must be built with Xcode 26 and the iOS 26 SDK or later. This does not stop your app running on older devices, it just moves your build environment forward.
• Age rating questions. Apple asked developers to answer the updated age rating questions by January 31, 2026; unanswered, submissions get interrupted.
• Privacy manifests. Since May 1, 2024, apps must declare approved reasons for a defined list of APIs, and that includes third-party SDKs. Every ad, analytics or crash reporting library you pull in is your responsibility at review time. The dependency discipline in software supply chain security turns into a direct publishing blocker on mobile.

Distributing in Europe adds one more item. Under the Digital Services Act, App Store distribution requires a trader status declaration. Apple made it a condition of submission from October 16, 2024 and removed apps without verified trader status from the EU App Store after February 17, 2025. The contact details you declare are public on your store listing.

Plan a release window, not a release day

Apple review often completes in a day or two, but nothing guarantees it. On Google's side, new accounts and sensitive categories get looked at longer. Two practical rules follow. Never tie launch communications to a build that has not cleared review, and do not announce the date before it has. Then roll the release out gradually.

Both stores give you the tools. Apple's phased release distributes an update to users with automatic updates enabled over seven days (1 percent on day one, then 2, 5, 10, 20, 50 and 100), and you can pause it for up to 30 days if something looks wrong. Google Play's staged rollout works on percentages too and can be halted. Managed publishing in Play Console lets you decide when reviewed changes actually go live.

For testing, TestFlight gives you 100 internal testers and up to 10,000 external ones. Worth remembering: the first build for external testers has to clear Beta App Review, which can cost you another day.

The store has no rollback button

This is the most expensive difference between web and mobile. On the web you pull a bad release in ten minutes. In the store there is no going back to the previous version: you submit a fixed build and wait for review again, while some share of your users sits on the broken one.

That makes feature flags a rollback plan rather than a convenience. If you can turn a risky feature off from the server, a bad release is maintenance work instead of a crisis. Feature flags and progressive rollout covers the mechanics. For the same reason, put a forced upgrade check into your very first release, where the app asks the server for a minimum supported version on launch. Add it later and the users who most need it are exactly the ones who will not receive the update that contains it.

The last half hour before you submit

After acceptance testing is done and before anyone presses submit, have one person walk the list end to end. Does the demo account work and is the backend up? Are the reviewer's steps written in the notes? Does account deletion work both in the app and from the web? Do the Data safety form and privacy labels match what the app really collects? Are the screenshots from the current build? Does the app name or description overclaim? Are the target API level and SDK current? Did any staging URLs survive into the build?

Most of this belongs in a pipeline. If building, signing, uploading and writing release notes are manual steps, human error is a matter of time; the reasoning in CI/CD for small teams applies to mobile releases as written. For the sign-off process around all of it, see acceptance testing before go-live.

If your app has just been rejected, the first move is to read the guideline number in the message rather than argue with it. Apple lets you ask questions through Resolution Center and appeal to the App Review Board if you think the decision was wrong, though in most cases the fix is small and you can resubmit the same day. The real goal is not repeating the round trip: put the dates above in a calendar and the checklist above in your release process.