Most founders budget months for building an app and about an hour to think about app store submission. Then the rejection email arrives, and the launch timeline moves two weeks to the right.
Apple reviewed 1.7 million app submissions in 2021 and rejected roughly 34% of them at least once (Apple Transparency Report, 2021). That is not a minority edge case. That is one in three apps hitting a wall before a single user can download it. Understanding how the review process actually works, and where it breaks, is the difference between a launch that happens on schedule and one that does not.
How does the Apple App Store review process work?
When you submit an app to the App Store, it enters a queue where Apple's review team checks it against the App Store Review Guidelines. The team is partly human and partly automated. Automated checks run first and catch obvious issues like crashes and malware. Human reviewers handle policy questions, metadata, and anything that requires judgment.
Apple publishes a 90th percentile review time on its developer dashboard. As of mid-2022, that figure sits at 24–48 hours for most submissions. About 50% of apps get their decision within 24 hours (Apple Developer, 2022). This is genuinely faster than it was in 2016, when reviews routinely took 7–10 days.
The timeline changes when something triggers additional scrutiny. A reviewer who cannot reproduce the app's core features, finds a crash on their test device, or spots a policy conflict will put the review on hold and send a rejection notice. At that point, the clock resets. You fix the issue, resubmit, and join the queue again. Each cycle adds 2–5 business days.
There is also a middle path: Apple may request metadata or clarification without fully rejecting the app. This puts the review into a "waiting for developer" state, which can sit unresolved if you miss the notification. Check your registered email and your App Store Connect notifications daily during an active review.
Expedited review is available if you have a critical bug affecting live users or a time-sensitive launch tied to a real-world event. Apple does not guarantee approval speed, but most valid expedite requests get prioritized within 1–2 business days. The request takes about five minutes to file through the Resolution Center in App Store Connect.
What are the most common reasons for rejection?
Rejection categories from Apple's 2021 transparency data break down like this: performance issues (including crashes) caused 17% of rejections, privacy policy violations caused 14%, guideline violations around business and payments caused 11%, and spam or misleading metadata caused 8%.
Performance is the most fixable category. Apple tests apps on real devices, often older models that reviewers keep on their bench specifically because they expose memory problems and slow load times that newer phones forgive. If your app crashes on an iPhone 8 but works perfectly on an iPhone 13, it will be rejected for the crash. Test on older hardware before submitting.
Privacy disclosures trip up founders who treat the App Store privacy questionnaire as a formality. Apple requires you to accurately declare every type of data your app collects and how it is used. If your analytics library collects device identifiers and you declare that your app collects no data, that mismatch is a rejection. Check what every third-party SDK in your app actually collects, not just what your own code does.
The payments category catches apps that try to route around Apple's in-app purchase system. If users can buy digital goods or subscribe to premium features, that transaction must go through Apple's system. External payment links for digital goods will get the app rejected. Physical goods and services rendered outside the app are exempt.
Metadata rejections cover a lot of ground: screenshots that show an older version of the UI, a description that promises features not in the build, placeholder text left in the keywords field, or a support URL that returns a 404. These are fast to fix but embarrassing to trigger.
| Rejection Category | Share of 2021 Rejections | Fix Time |
|---|---|---|
| Performance / crashes | 17% | 1–3 days (rebuild and retest) |
| Privacy policy violations | 14% | 1–2 days (update disclosures) |
| Business / payments policy | 11% | 3–7 days (may require architecture changes) |
| Spam / misleading metadata | 8% | Hours (edit and resubmit) |
| Other guideline violations | 50% | Varies |
How does Google Play approval differ from Apple?
Google Play's review process is faster on average but less predictable in its timing. Initial reviews for new apps take 2–7 days, with the median around 3 days. Updates to existing apps often clear in 24 hours. Google relies more heavily on automated scanning, which means straightforward apps move quickly and apps with unusual patterns, certain permission combinations, or content flagged by their systems can take significantly longer.
The rejection rate at Google Play is lower than Apple's, partly because the guidelines are somewhat less prescriptive and partly because more automated tools pre-screen before human review. That said, Google's policy enforcement has tightened considerably since 2020. Apps targeting children, apps requesting sensitive permissions, and apps in health or financial categories face the same level of scrutiny as they would on the App Store.
One meaningful difference: Google allows you to publish to a closed testing track first, with up to 100 testers, and this track goes through a lighter version of the review process. Many teams use this to validate their build in a live environment before targeting open production review. Apple has TestFlight for beta distribution but it is a separate channel from App Store review.
The biggest practical difference between the two stores is how they communicate rejection reasons. Apple sends a detailed message through the Resolution Center explaining exactly what failed and which guideline applies. Google's rejection notices are often less specific. You may receive a policy citation without a clear explanation of where in your app the violation occurred, which makes debugging harder.
| Attribute | Apple App Store | Google Play |
|---|---|---|
| Average review time (new app) | 1–3 days | 2–7 days |
| Average review time (update) | 24–48 hours | 24–72 hours |
| Rejection rate (at least once) | ~34% | ~15–20% |
| Rejection explanation quality | Detailed, guideline-specific | Often vague |
| Pre-production testing path | TestFlight (separate) | Closed testing track (same review pipeline) |
| Payment policy enforcement | Strict, no workarounds for digital goods | Similar, with some nuances for subscriptions |
What should I prepare before my first submission?
A rejected submission is not just a delay. It is a signal that the app was not ready, and it creates a paper trail that reviewers can see on subsequent submissions. A clean submission history is worth protecting.
Start with the build itself. Test on at least three device types covering different screen sizes and at least one older model that represents the low end of your target audience. For iOS, that means testing on an iPhone SE or iPhone 8 alongside your newest phone. For Android, test on a mid-range device from 2019 or 2020. Crashes on review devices are the single most common rejection reason, and they are completely avoidable.
Fill out every metadata field as if a detail-oriented stranger is evaluating it. Your app description should accurately describe what the app does today, not what it will do after the next update. Screenshots must match the current UI. Your privacy policy URL must resolve and describe the data your app actually collects.
For privacy declarations, open each third-party library your app uses and read its data collection documentation. Analytics tools, crash reporting services, and advertising SDKs often collect data that founders do not realize is being gathered. Each category of data must be declared accurately in App Store Connect and in your Play Store data safety form.
If your app includes any of the following, budget extra time for review and have your justification ready: health or medical features, financial transactions, user-generated content, access to contacts or location data, features targeting users under 13, or any kind of subscription pricing. Each of these categories prompts additional scrutiny, and reviewers may ask clarifying questions before approving.
Building an app with a global engineering team speeds up the development phase considerably. A Timespade team delivers a production-ready mobile app in about 28 days. The review process is outside anyone's control, but a well-prepared submission, with correct metadata, clean builds, and accurate privacy disclosures, clears the queue in 1–3 days rather than cycling through 2–3 rejection rounds that add weeks to the timeline.
Western agencies routinely charge $50,000–$80,000 for a mobile app that a global engineering team delivers for $12,000–$18,000, and the review success rate comes down to submission quality, not budget size. The apps that get rejected are the ones submitted in a hurry, with untested builds and copy-pasted metadata.
If you are building your first mobile app and want to get it right before it goes anywhere near a review queue, the first step is a free discovery call where your entire idea gets pressure-tested for submission readiness before a line of code is written. Book a free discovery call
