Before You Submit Your App to the App Store: The Technical Steps That Actually Matter

Launch is two weeks out. The app works, the team has been testing it for weeks, the marketing calendar is set, the store listing copy is written. You submit to Apple, and thirty-six hours later the answer comes back in one line: rejected under "Guideline 2.1 – App Completeness." It doesn't say which screen, and it doesn't say which device the problem showed up on. Launch is no longer two weeks away — it's whenever this gets sorted. If that scenario sounds familiar, the real issue usually isn't code quality; it's a short, well-documented technical checklist you're supposed to finish before you submit your app to the app store, and most teams only learn it exists the first time they get rejected.

##The Technical Steps You Need to Finish Before You Submit Your App to the App Store

Most of what Apple and Google reject apps for isn't a complicated bug — it's a small, already-documented requirement someone skipped: a live privacy policy URL, a human-readable explanation for every permission request, a working demo account for the reviewer on any screen that requires login, store copy that actually matches the screenshots, an account-deletion flow that lives inside the app instead of an "email us to delete your account" page. None of these are hard. They just get noticed while filling out the submission form, not while writing the code — and usually a week before launch. This is that list: why each item exists, and how to clear it before your first rejection, not after.

##Critical Differences Between the Apple App Store and Google Play

The two stores don't operate on the same logic, and not knowing that difference all but guarantees a second surprise rejection. Apple's review combines automated scanning with a human reviewer actually opening and navigating the app; anything touching payments, accounts, or health data gets extra scrutiny. Google Play's first pass leans more on automated systems and usually resolves faster, but the real difference shows up after launch: Play keeps scanning for policy violations days or even weeks after approving your app, and it can suspend the app the moment it finds one. So the hard part on Apple is getting through; the hard part on Play is staying compliant after you're already live. Payments split the two stores further: if you're selling digital goods or services, Apple requires In-App Purchase and won't let you link out to your own payment flow (with a few narrow exceptions); Play gives you a bit more flexibility there, but if your Data Safety form doesn't match what the app actually collects, the suspension risk is just as real.

Here are the differences that get missed most often when a team is prepping a submission:

• ▸Apple: human + automated review, typically 24–48 hours; apps handling payments, accounts, or health data get extra manual scrutiny and longer timelines
• ▸Google Play: mostly automated review, usually faster approval — but policy scanning continues AFTER launch, and suspension risk never really goes away
• ▸Apple: In-App Purchase is mandatory for digital goods or services; you can't link out to your own payment page
• ▸Google Play: more flexibility to use your own payment infrastructure, but the Data Safety form has to match the app's actual data behavior exactly
• ▸Both stores: a live privacy policy URL, specific usage-description text for every permission, and a working demo account for apps that require login

##A Real Scenario: Why First Submissions Get Rejected, and How They Get Fixed

A small team submits their booking app to Apple for the first time. Forty-eight hours later, two separate rejections come back: Guideline 5.1.1 — there's no account-deletion option in the app, and the support page just says "email us to delete your account"; Guideline 2.1 — on the iPad the reviewer tested, the onboarding carousel freezes and crashes on the second screen. The team is confused, because it never happened on their own simulators. The root cause is simple: the carousel animation was only ever tested on small-screen simulators, never on a real iPad running an older iPadOS version; the account-deletion requirement came from a 2022 policy update the team missed entirely, because the app had been designed before that change. The fix has two parts: a real "delete account" flow gets added to settings (in-app confirmation and irreversible deletion, not an email address), and the carousel component gets tested and fixed on an actual, older device where a memory leak turns out to be the cause of the crash. On the second submission, the team spells out exactly what changed in the reviewer notes, and approval comes back in 18 hours. The net effect on the calendar: launch slips four days — but because the whole checklist got walked through properly, there's no third rejection. For most teams, the real cost isn't any single rejection; it's the unpredictable string of them that eats the calendar one surprise at a time.

##The Technical Checklist That Prevents Rejection

Before you submit, every item below needs to be actually verified — "probably fine" doesn't count:

• ▸The privacy policy is live at a real URL and reachable through a tappable link inside the app
• ▸Every permission request — camera, location, notifications — has its own human-readable, request-specific explanation (a generic "we use your data" string isn't enough)
• ▸Every screen that requires login has a working demo account, with credentials included in the app review notes
• ▸Account and data deletion happens inside the app itself, not through a support-email redirect
• ▸The app has been tested on real devices at both ends of the support range: the oldest supported OS version and the newest
• ▸If there's an in-app purchase, the restore-purchase flow has been tested on its own, separately
• ▸The age-rating questionnaire was filled out consistently with what the app actually contains — violence, user-generated content, social features
• ▸Screenshots and store copy show what the app actually does right now, not a feature that hasn't shipped yet
• ▸Every crash and analytics SDK has been individually added to the privacy disclosure (Apple's privacy nutrition label, Play's Data Safety form)
• ▸Deep links and push-notification permission flows have been tested end to end on a real device

There are two more items that get skipped constantly because neither one produces a visible crash. Apple's Export Compliance question — whether the app uses encryption, and HTTPS alone usually counts even though it's typically exempt — gets asked again on every single version, and an inconsistent answer across versions can turn into a flag in a later review even though it won't fail the current one. Similarly, in-app purchases should be tested with a sandbox account, not a real card — the restore and cancellation paths both need to be verified working before real money is ever involved. Neither of these shows up as an obvious bug; they just cause quiet trouble a version or two later.

##Average Review Times and Delay Ranges

##After Launch: Versioning, Update Speed, and What to Do in a Crisis

Getting approved isn't the finish line — it's the start of the next risk. On Google Play, using staged rollout to release a new version to a small percentage of users first is the cheapest way to catch a critical bug before it reaches everyone. Apple doesn't offer that option, but it does let you request expedited review when a critical security issue or crash is found — it can jump the normal queue and get reviewed within hours, though that option is for real emergencies, not every release. Taking semantic versioning seriously makes it possible to trace a crash report back to the exact code behind it within minutes; keeping old build symbol files (dSYMs, mapping.txt) around means you can still debug a crash from a version that shipped three days ago. And keeping the previous build on hand is the only real guarantee that a rollback decision can be made in minutes instead of hours when something critical breaks.

##Frequently Asked Questions

>How long does App Store review actually take on average?

A first submission typically gets a result within 24–48 hours; apps that handle payments, accounts, or health data can take longer because of the extra manual scrutiny. Resubmissions land in a similar range, sometimes slightly faster since the reviewer can see the previous rejection notes.

>Why can an app get suspended on Google Play after it was already approved?

Because Play's policy scanning doesn't stop at launch. If the data-collection behavior declared in the Data Safety form stops matching what the app actually does — or an SDK update quietly adds new data collection that the form was never updated to reflect — the system can catch that days or weeks later and suspend the app. That's why the Data Safety form needs to be treated as a living document checked on every release, not a one-time checkbox.

>Does resubmitting a rejected app put it back at the end of the queue?

Usually not. The reviewer can typically see the previous rejection notes, which often speeds up verifying that the specific issue got fixed. But a resubmission still goes through the same review pipeline, so there's no guaranteed fast lane outside the ranges above — the real advantage is simply that clearly explaining what changed makes the review easier to complete.

>How do I submit an app that requires login if I don't have a demo account?

In practice, you can't — or rather, you can submit it, but the reviewer will get stuck at the login screen and you'll almost certainly get a Guideline 2.1 rejection. The right move is adding a working username and password (or a demo login link) to the app review notes; some teams keep a dedicated test account, isolated from real user data, just for reviewers to use.

Most of this checklist gets discovered not while building the product, but while filling out the submission form a week before launch. If you want a technical review of whether an app is actually ready for the store, or want to plan a launch together, you can reach out through /contact; how I work and what the process looks like is on /process-pricing, and I covered a related post-launch topic — what happens to a "finished" app afterward — in /blog/software-maintenance-retainer-cost-after-launch.