App Store and Play Store Submission: What Actually Happens

By Nikola, founder at ZEROX. We build React Native apps for iOS and Android, and we took our own product, Loop ELD, through both stores. Last updated March 2026.

The part of shipping an app that founders understand least is usually the last one: app store submission. You spend months building, and then two companies you have never spoken to decide whether anyone can install it. That gap between the build working and the app being live is where first-time teams lose the most time, almost always to predictable problems.

This post covers what actually happens when you submit to Apple's App Store and Google Play: the listing to prepare, real review timelines, why apps get rejected, and why rejection is a normal step, not an emergency. It is for founders shipping v1.

App store submission is a listing review, not just a code upload

Submission is not just uploading a build and waiting. The reviewer looks at your whole store listing, and a large share of delays come from the listing, not the code.

For each store you prepare:

• Name, subtitle, and description. Claiming features the app does not have, or stuffing keywords, is a rejection reason on its own.
• Screenshots and an optional preview video, taken from the actual app. Marketing mockups that do not match the real UI get flagged.
• Icon, category, age rating, and a working support URL.
• A privacy disclosure. Apple's App Privacy label and Google Play's Data safety form ask what data you collect and why, and must match what the app actually does. Automated scanners and reviewers check.
• Review notes and a demo account. If anything sits behind a login, give the reviewer working credentials and a note on how to reach the key screens. That one step prevents a large share of first-round rejections.

Set up both developer accounts early. Apple's Developer Program and Google Play registration each carry a fee and identity verification that can take days, so do not leave it to launch week.

How long review actually takes

Apple's review is faster than its reputation. In 2026 most submissions clear within a day or two. It is a real human review, so anything borderline takes longer.

Google Play mixes automated and manual checks and is no longer instant, and new apps and new developer accounts get extra scrutiny. If you registered a personal Google developer account recently, Google may require a closed test with a minimum number of testers over a set period before you can apply for production access. Check the current rule before you promise a date, because it has caught a lot of solo founders off guard.

Either way, submit earlier than feels necessary, and never tie a launch date, press, or paid campaign to a build still in review.

The rejection reasons that catch first-timers

Most are not mysterious. The same short list recurs:

• Permissions without a reason. Requesting location, camera, contacts, or microphone with a vague usage string. Explain why, at the moment you ask.
• Privacy mismatches. Your disclosure does not match what the app actually sends, including App Tracking Transparency on iOS if you track users across apps.
• No privacy-preserving login on iOS. If you offer third-party or social login, Apple generally requires an equivalent option that limits data collection, such as Sign in with Apple.
• Misleading metadata. Screenshots or copy that promise more than the app delivers.
• Crashes and dead ends. The reviewer hits a crash, a broken login, or a button that goes nowhere. Test on a clean device with no cached state.
• Placeholder content. Lorem ipsum, a support URL that 404s, an empty screen where content should be.

None of these need insider knowledge, only reading the guidelines and testing honestly.

Test before you submit: TestFlight and internal tracks

Both platforms let you run the real production build with real users before the public sees it, and skipping that is how avoidable bugs reach the reviewer.

On iOS, TestFlight distributes to internal testers immediately and to external testers after a light beta review. On Android, Play's internal testing track pushes a build to a small tester list with no review, and closed and open tracks widen from there.

Use them to confirm the boring things: the app installs from the store pipeline rather than your laptop, push arrives, offline and sync behave, and the reviewer's login works. We caught real issues in Loop ELD this way, because background location and offline logging behave differently once the app is signed and living on a real device.

Rejection is a step, not an emergency

Treat a rejection as routine feedback, not a verdict. Apple cites a specific guideline and often includes a screenshot. You fix that issue, reply in the Resolution Center or resubmit, and you are usually back in review quickly. Plenty of normal apps get rejected once or twice on the way to approval.

What turns a rejection into a real delay is panic: rewriting half the app over a narrow note, or arguing instead of fixing. Read exactly what they cited, change exactly that, and move on.

How you build for both stores from one codebase shapes all of this. We covered that tradeoff in React Native vs native; a shared codebase is what we use for most client apps and our own.

FAQ

How long does app store submission take in 2026?

Apple usually reviews within a day or two. Google Play can take longer, especially for new developer accounts, some of which must run a closed test before applying for production. Submit with buffer, and never hard-commit a date to a build still in review.

Why do apps get rejected the first time?

Usually permissions without a clear reason, a privacy disclosure that does not match behavior, a missing privacy-preserving login option on iOS, misleading screenshots, or a crash the reviewer hit. Almost all of it is preventable with honest testing and a demo account.

Do I need both a TestFlight and a Play testing pass?

Yes. Running the signed, store-distributed build with real testers surfaces problems that never show up in local development, so the reviewer is not the first person to install your app the normal way.

Ready to ship your first app?

If you would rather not learn every guideline the hard way, that is what we do. ZEROX handles mobile app development end to end, from the build through store setup, submission, and the fixes that come back. Tell us what you are shipping on our contact page and we will give you an honest read on scope and timeline.