Surviving App Review: 5 rejections we learned from
We've shipped 48 apps. We've also 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 - Spam (template-based apps)
The first time we shipped a second Simplio app (Notepad, after Routines), it was rejected under guideline 4.3 with a vague 'this app appears to be a spam submission.' Apple's automated detection flagged the visual similarity.
Resolution: we wrote a detailed reply explaining that Simplio is a brand of small focused tools, listed the differences in functionality, and pointed to the unique value of the Notepad app. Manual review approved it within 48 hours.
Lesson: if you're shipping multiple apps with similar visual identity, expect to write a reply on each new one. Have a template ready.
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.