Before you submit, nail four things: complete, correctly sized store assets; an accurate privacy label and Data safety form; a real round of TestFlight and Play internal testing; and a build that dodges the usual rejection triggers — broken links, a missing demo login, and thin "4.3 spam" content. Then expect a review that usually lands within 24–48 hours.

A store launch fails on details, not on big mistakes. Below is the practical, ordered checklist we run before pushing any client app to the App Store or Play Store — the same steps that get a build approved on the first try instead of the third.

Why do so many first launches get rejected?

Because founders treat submission as a formality and Apple treats it as a review. Apple in particular reads your listing, taps your links, and logs into your app with the credentials you provide. Miss a detail and you lose days waiting for a second pass.

The good news: nearly every rejection comes from a short, known list. Clear that list before you submit and approval is routine.

Step 0 — Set up your developer accounts early

Before any of this, make sure your store accounts exist and are verified, because approval is not instant. An Apple Developer account costs $99 a year; a Google Play developer account is a one-time $25. Apple's enrolment can take a day or two to verify, and if you are enrolling as a company rather than an individual, expect a longer identity check involving a D-U-N-S number.

Sort this out weeks before launch, not the night before. Founders regularly lose real time discovering that the account they need is stuck in verification while a finished app sits waiting to ship.

Step 1 — Prepare your store assets

Both stores need a complete set of listing assets, sized exactly to spec. Get these ready before you open the submission form:

  • App icon in the required resolutions, with no transparency and no rounded corners baked in.
  • Screenshots for each required device size — at minimum a 6.7-inch iPhone set for Apple, plus phone and tablet sets for Google. Show the real product, not a marketing mock-up.
  • An optional preview video — worth it for consumer apps, where it lifts store conversion.
  • Title, subtitle, and description that read like a human wrote them and describe what the app genuinely does.
  • A privacy policy URL that actually loads — both stores require one, and a dead link is an instant rejection.

Step 2 — Complete the privacy label and Data safety form

Every app must declare what data it collects and why. Apple calls it the privacy nutrition label; Google calls it the Data safety form. Both are mandatory, and both must match your app's real behaviour.

Go through every SDK you have added — analytics, ads, crash reporting, login providers — and declare what each one collects. The fastest way to fail here is to under-declare because you forgot a third-party SDK is quietly gathering device data. If the stores detect collection you did not disclose, they reject the build and trust erodes fast.

Step 3 — Test properly before you submit

Never push a build straight from your laptop to the store. Run it through the platforms' own testing tracks first:

  • TestFlight (Apple) — send the exact build you plan to release to a handful of real testers on real devices. It surfaces crashes and login issues the simulator hides.
  • Internal and closed testing (Google Play) — the same idea, and Google now expects new personal developer accounts to run a closed test with real testers before production access is granted.
  • Test on low-end Android hardware, not just the newest iPhone. If you are shipping to India, a mid-range Android phone is your real reference device.

The point is to catch the embarrassing, obvious break — the crash on launch, the button that does nothing — before a reviewer or a user does.

Step 4 — Clear the common rejection reasons

Most rejections trace back to a handful of causes. Walk this list before you submit:

  1. Guideline 4.3 (spam). Apple rejects apps that are thin, template-like, or nearly identical to others. If your app is a repackaged website or a barely customised template, expect trouble. Ship something with real, distinct value.
  2. A missing or broken demo login. If your app has a login wall, you must provide working demo credentials in the review notes — or a reviewer who cannot get in rejects it immediately. Confirm the account works the day you submit.
  3. Broken links and placeholder content. Dead privacy-policy links, lorem ipsum, empty screens, and "coming soon" sections all get flagged. The build you submit must feel finished.
  4. Privacy mismatches. Data collection that does not match your declared label, or a permission you request but never justify, triggers a rejection.
  5. Crashes and bugs. An app that crashes during review is an automatic no. This is exactly what Step 3 exists to prevent.
  6. Payment rules. Selling digital goods or subscriptions? They generally must run through the platform's in-app purchase system, not an external payment link.

How long does app review actually take?

In 2026, Apple reviews most apps within 24–48 hours, sometimes faster. Google Play is often quick too, but new developer accounts and sensitive categories can take several days to a couple of weeks while extra checks run.

Plan for it. Do not promise investors or users a launch date that assumes instant approval, and never schedule a press push before your build is actually live and approved. Submit with a few days of buffer.

Step 5 — Get the basics of ASO right before you publish

App store optimisation decides how many of the people who could find your app actually do. You do not need a full campaign at launch, but get the fundamentals right, because they are hard to change later:

  • Title. Your app name plus, where it reads naturally, one or two key terms people actually search.
  • Keywords. Apple gives you a dedicated 100-character keyword field — use every character, no spaces after commas, no wasted words. Google reads your description instead, so weave terms in naturally.
  • Screenshots. The single biggest driver of store conversion. Lead with your strongest value, add short captions, and show the real product in action.
  • The first two lines of the description — the only part most people read before deciding. Make them count.

The final pre-submit checklist

Run this the day you submit:

  1. All screenshots and icons uploaded at the correct sizes.
  2. Privacy label and Data safety form completed and accurate.
  3. Privacy policy URL live and loading.
  4. Demo login credentials added to review notes and verified working.
  5. Build tested on real iOS and low-end Android devices with no crashes.
  6. No broken links, placeholder text, or empty states.
  7. In-app purchases configured correctly, if you have them.
  8. Title, keywords, and screenshots optimised for search and conversion.

Tick all eight and you have removed almost every reason a store would say no.

A clean launch is unglamorous work, but it is the difference between going live on schedule and losing a fortnight to review ping-pong. We handle store submission and ASO as part of every build we ship — see how we work on our services page.

If you want a second set of eyes before you hit submit, tell us about your app and we'll help you launch it right the first time.