Roughly 22 percent of App Store submissions were rejected in 2025, somewhere near 2 million out of 9.1 million. Almost none of that was about code quality.
The rejections cluster around a small number of guidelines, and every one of them is checkable before you submit. What makes them expensive is timing. A rejection costs you a review cycle, cycles run on Apple’s schedule rather than yours, and if your launch is tied to a campaign or an event then the cost is real money rather than a few days of annoyance.
Key Takeaway: Five guidelines account for most rejections: minimum functionality (4.2), data collection disclosure (5.1.1), missing in-app account deletion, Sign in with Apple where third-party login is offered (4.8), and privacy labels that do not match what your SDKs actually collect. All five are auditable before submission.
Guideline 4.2: Minimum Functionality
The most common rejection and the hardest to fix late, because it is a product problem rather than a code problem.
Apple rejects apps that read as a repackaged website, offer too little native value, or could reasonably have been a web page. A wrapper around your existing site with no native capability is the clearest case. So is an app whose entire function is displaying content you already publish elsewhere.
Cross-platform builds attract this scrutiny slightly more than native ones do, not because the frameworks are a problem but because thin apps are more often built quickly.
The fix is not cosmetic. Genuine native capability means something the platform provides and a browser does not: push notifications people actually want, offline access, camera or location use tied to the core job, widgets, biometric authentication. If your honest answer is that the app does nothing a website could not, address that before you write the code rather than after review tells you.
Guideline 5.1.1: Data Collection and Storage
Reviewers check your privacy policy against what the app actually does, and they check permission requests against apparent need.
Requesting contacts access for a feature that does not obviously require it gets flagged. So does requesting location when nothing in the interface explains why. The pattern that fails is asking for everything at launch in case you need it later.
Ask for permissions in context, at the moment the feature needs them, with a usage description string that explains the reason in plain language. The generic “we need this to improve your experience” placeholder is a reliable way to get rejected.
Missing Account Deletion
Any app that lets a user create an account must let them delete it from inside the app. Not by emailing support, not by visiting a web page, not by contacting you. In the app.
This one catches a lot of teams because it arrived as a requirement rather than a suggestion, and because plenty of backends were never built with deletion in mind. If your account system cannot currently delete a user and everything attached to them, that is backend work you need to schedule before submission rather than discover during it.
Guideline 4.8: Sign in with Apple
If your app offers login through Google, Facebook or another third-party service, you must offer Sign in with Apple alongside it.
Teams building Android first and porting to iOS hit this constantly, because the Android app quite reasonably ships with Google login and nobody thinks about the iOS requirement until submission. It is straightforward to implement and irritating to discover late.
Privacy Nutrition Labels
Your declared data collection has to match what the app genuinely does, including what your third-party SDKs do on your behalf.
This is where most teams get caught honestly rather than carelessly. Analytics packages, advertising SDKs and crash reporters collect more than developers assume, and the declaration is your responsibility rather than the vendor’s. Before submitting, go through every SDK in the project and check its documented data collection against what you have declared.
App Tracking Transparency sits alongside this. If you access the advertising identifier you need the ATT prompt, and Apple takes a dim view of interfaces that pressure users toward consent.
What a Pre-Submission Audit Looks Like
We run this before every submission because it is unglamorous work that saves weeks.
Walk the account creation flow and confirm deletion exists and works end to end. List every login method offered and confirm Sign in with Apple is present if any third party is. Open every SDK’s privacy documentation and reconcile it against your declared labels. Trigger every permission request and read the usage description as a stranger would. Check that the app does something a website could not, and be honest about the answer.
Then prepare the reviewer notes properly. If your app needs an account to be useful, supply working credentials. If a feature needs specific conditions to demonstrate, explain how to reach it. Reviewers work quickly and a confused reviewer rejects.
When You Get Rejected Anyway
It happens to everyone eventually. The response matters more than the rejection.
Read the actual guideline cited rather than the summary. Apple links to the specific rule and the wording usually tells you exactly what they saw.
If it is a genuine violation, fix it and resubmit. If you believe it is a misunderstanding, and sometimes it is, you can reply in Resolution Center with an explanation. Be specific and unemotional. Arguing rarely works; clarifying often does.
Expedited review exists for genuinely urgent situations and is worth saving for one. Using it for an ordinary rejection wastes the goodwill.
How This Differs on Google Play
Play review is a different experience. Google reviews largely by automation with spot manual checks, approves most apps within hours to a day, and rejects at a much lower rate.
That difference matters for launch planning. If you are shipping both platforms simultaneously, iOS is the critical path and should be submitted first. Teams that submit both on the same day and plan a coordinated launch discover this the hard way. Our Play Console setup guide covers the Android side, and app publishing costs covers what both stores charge.
Frequently Asked Questions
How long does App Store review take?
Most submissions get a decision within 24 to 48 hours, though it varies and slows around major OS releases. Plan for a week between submission and launch so a single rejection does not move your date.
Does a rejection hurt our developer account?
A normal rejection does not. Repeated attempts to circumvent guidelines, or anything Apple reads as deliberate deception, is a different matter and can escalate to account level.
Can we launch on Android while iOS is still in review?
You can, and plenty of teams do. Just decide deliberately rather than by accident, because a staggered launch changes your marketing and support planning.
Do cross-platform apps get rejected more often?
Slightly, but the framework is not really the cause. Guideline 4.2 targets thin apps, and thin apps are more often built quickly on cross-platform. A substantial React Native or Flutter product clears review the same as a native one.
Who fixes a rejection, us or our development partner?
It should be them, at no extra cost, because avoiding rejection is part of what you hired them for. Worth confirming before you sign that rejection handling is included rather than billed as a change request.
Getting It Right First Time
Most of this is process rather than skill, which is why it is worth asking any development partner how they handle it. Our iOS app development in India page covers the pre-submission audit and how we handle review correspondence. If you would rather have a Swift engineer inside your own team, hiring iOS developers covers that arrangement instead.