Surviving App Review: 5 rejections we learned from
We've shipped a lot of apps, and we've been rejected by App Review enough times to learn the patterns. None of the rejections were dramatic - most were 24-hour fixes - but each taught us something we now build into our preflight. Here are the five that mattered.
Rejection 1: 4.3 - each app has to stand on its own
Guideline 4.3 asks every app to be a distinct product, not a variation of another one. Our second Simplio app (Notepad, after Routines) was questioned under it because the two shared a visual style.
Resolution: we explained what Notepad does that Routines does not, and the app was approved. Since then every app gets its own look, its own onboarding and its own reason to exist before we write a line of code.
Lesson: design each app around its own job. If two of your apps could swap screenshots, one of them needs more work.
Rejection 2: 5.1.1 - privacy disclosure
Submitted an app with a sign-up form that asked for an email address. Privacy policy didn't explicitly mention email collection. Rejected.
Resolution: updated the privacy policy URL to a page that explicitly listed email as a data collection point, with retention policy. Re-submitted. Approved within hours.
Lesson: your privacy policy must enumerate every data type you collect. Generic 'we may collect personal information' language fails review now.
Rejection 3: 2.5.4 - multitasking misuse
Built a focus timer with background audio (a quiet white-noise sound during sessions). Rejected for misusing background audio capability - Apple's reviewer noted the audio wasn't 'integral' to the app function.
Resolution: we added a clear UI explaining that white noise is the user's chosen tool for focus sessions, made it impossible to enable background audio without explicitly starting a session, and re-submitted with notes. Approved.
Lesson: background modes get scrutinized. Make the user's choice explicit and the connection between background activity and user intent unambiguous.
Rejection 4: 4.2 - minimum functionality
We submitted a single-purpose calculator app. Rejected: 'we found that the usefulness of your app is limited.' This is the dreaded 4.2 rejection that hits a lot of indie utility apps.
Resolution: we added 3 secondary features (history, sharing, custom presets), updated the screenshots to show them, and resubmitted with notes acknowledging that we'd improved the breadth. Approved.
Lesson: a single-action calculator looks 'too simple' to App Review even when it's useful. Two or three orthogonal features cross the bar without bloating the app.
Rejection 5: 4.7 - limited reasons (tip jar)
Tried to add a 'leave a tip' IAP outside of any subscription. Rejected. Apple's tip-jar guidelines have softened over time, but in 2025 the bar was still 'must enable a specific feature.'
Resolution: we removed the tip jar and built it as a 'Pro features' purchase (custom themes + an early-access flag). Approved.
Lesson: Apple wants IAPs tied to features. 'Buy me coffee' as a pure donation gets rejected. Wrap it in something that unlocks even a small piece of UI.
Our preflight checklist
Before every submission, we run through:
- Privacy policy URL works and lists every data type
- Privacy nutrition label matches the binary's actual behavior
- Restore Purchases button is visible from the paywall
- Background modes are tied to explicit user actions
- App Store screenshots show real functionality, not aspirational mockups
- Demo account credentials provided if any sign-in is required
- App Review Notes explain anything non-obvious
Most rejections we still see are caught here. The ones that aren't are useful learning.