Fixes & Rescues
App Rejected by Apple? Guideline 4.2 and Other Rejections, Explained and Fixed
What App Store rejection emails actually mean — especially Guideline 4.2 'minimum functionality' — and the exact steps that get apps approved on resubmission.
The rejection email from Apple is short, quotes a guideline number, and explains almost nothing. If your app was just rejected, here's what the common guidelines actually mean in practice, what reviewers are really checking, and how we fix rejections for apps we take over.
First: rejection is normal, not fatal
A large share of first submissions get rejected — including apps from experienced teams. Apple's review is a checklist process, not a judgment of your business. Most rejections are resolved in one or two focused resubmissions once you address the actual guideline instead of guessing.
Guideline 4.2 — 'Minimum Functionality', decoded
Guideline 4.2 means the reviewer believes your app doesn't do enough to justify existing as an app. The classic trigger is a website wrapper: if the app looks and feels like a mobile browser showing your site, Apple asks why a user wouldn't just use Safari.
The second trigger is an app that looks unfinished or empty at review time — placeholder screens, features behind 'coming soon', or an interface with no sample data so every screen renders blank.
How to actually fix a 4.2 rejection
Working fixes we apply on rescued apps, in order of impact:
• Add genuinely native capabilities — push notifications, offline mode, camera/photo integration, widgets — so the app does things the website can't
• Seed the review build with realistic sample data so no screen appears empty
• Record a short demo video showing complete real flows and attach it in App Review notes
• Remove every placeholder, 'coming soon' label, and dead button before resubmitting
• In the Notes for Review field, state specifically what changed and where to find it
The other rejections we see constantly
Beyond 4.2, four guidelines cause most of the rejections in apps we take over:
• 2.1 App Completeness — the app crashed or a flow failed during review; test on a clean device, not your dev machine
• 2.3 Accurate Metadata — screenshots or descriptions showing features that don't exist
• 5.1 Privacy — missing privacy policy URL, undeclared data collection, or login without account deletion
• 3.1 Payments — digital content sold outside Apple's in-app purchase system
Reviewer notes: the most underused fix
The Notes for Review field is read by a human. Give the reviewer a test account with data in it, tell them exactly which guideline you addressed and how, and point them to the flows that demonstrate it. A clear note routinely turns a third rejection into an approval.
If written communication stalls, you can request an App Review appointment and talk to a reviewer directly — few developers know this exists.
One more underused lever: respond in the Resolution Center instead of silently resubmitting. A reply that asks exactly which screen or flow triggered the guideline often gets a specific answer, and a specific answer converts your next submission from a guess into a fix. Reviewers are process-bound, not adversarial — apps that communicate clearly move through review measurably faster.
When rejection reveals a deeper problem
Sometimes 4.2 is Apple telling you the truth: the MVP genuinely doesn't do enough yet. And sometimes the crash in 2.1 is one symptom of a codebase with no error handling anywhere. If your app has been rejected three or more times, the pattern is usually the product, not the paperwork.
That's the point where a takeover audit is worth more than another resubmission attempt — it identifies whether you're one fix or one milestone away from approval.
Play Store rejections work differently
Google's review is faster and more automated than Apple's — which means different failure patterns. Play Store rejections cluster around policy declarations: the Data Safety form not matching what the app actually collects, missing or unreachable privacy policies, target API level requirements, and permission usage (especially location, SMS, and accessibility) without visible justification in the app.
The fix pattern is also different: Apple responds to reviewer notes and demo videos; Google responds to making your declared metadata match observable app behavior exactly. Apps that pass Apple routinely fail Google on the Data Safety form alone — treat the two submissions as separate projects with separate checklists.
The pre-submission checklist that prevents most rejections
Before every submission we run apps through the same gate. It catches the majority of rejections before Apple can:
• Fresh-install test on a real device — not a simulator, not your dev phone with cached state
• Every button leads somewhere; zero placeholders, zero 'coming soon'
• Demo account prepared, pre-filled with realistic data, credentials in Notes for Review
• Privacy policy URL live and matching actual data collection; account deletion available if you have login
• Screenshots show real current screens — not designs, not older versions
• Payments audit: any digital content sold must use in-app purchase (guideline 3.1)
• Crash-free session on a low-end device and on the newest OS version
Timelines: how long this actually takes
Typical App Store review runs 24–48 hours in 2026; Play Store from hours to a few days for established accounts (longer for brand-new developer accounts, which get extra scrutiny). A rejection therefore costs you two things: the days per round trip, and — the part founders underestimate — momentum, when each resubmission is a guess rather than a targeted fix.
That's the calculus for getting help: three guessed resubmissions cost two weeks. One diagnosed fix costs days. If a launch date matters, diagnose first.
And once you're approved, keep the checklist: every update goes through review again, and the most common post-launch rejection is an app that drifted out of sync with its own privacy declarations. Passing review isn't a one-time gate — it's a discipline that gets cheap once it's part of your release routine.
Founders also ask
How many times can Apple reject my app? There's no limit and no penalty count — apps get approved after five rejections all the time. The cost is your time and launch momentum, which is why targeted fixes beat guess-and-resubmit.
Will rejection hurt my future submissions? No. Review history isn't a reputation score. The exception is fraud-adjacent behavior — misleading metadata, hidden features, repeated policy evasion — which can escalate to account-level action. Honest functional rejections carry zero lasting damage.
Can I talk to a human at Apple? Yes — request an App Review appointment from the rejection screen in App Store Connect, and a reviewer will discuss your case on a call. Few developers use this; it regularly unsticks apps that written replies couldn't.
My app works perfectly for me — why did it crash for the reviewer? Reviewers test on clean devices, fresh installs, and sometimes IPv6-only networks. Your dev phone has cached auth, seeded data, and forgiving network conditions. Test a fresh install on a device that's never seen the app before every submission.