We've written before about what we test before every submission — this is the other half: the rejections that made it past our own QA and came back from Apple anyway. Across twenty-plus submissions, the same handful of guidelines account for almost every one of them. None of these are exotic; they're the ordinary ones that get you if you treat App Review as a formality instead of a second set of eyes.
Guideline 4.2 — "Minimum Functionality" finds content-heavy apps first
Our Legi & Amenzi series — Rutiera, Mediu, Alegeri, Ordine Publică — is text-and-quiz content by design, and the first version of one in that series read to a reviewer as too close to "static content in a wrapper." The fix wasn't cosmetic — it was adding real app behavior on top of the content: search, progress tracking, offline quiz scoring, bookmarking. The lesson that generalizes: if an app's core value is information, the interaction layer around that information has to be substantial enough that removing the app and reading a PDF instead would be a genuinely worse experience.
Guideline 2.1 — crashes that only show up on review hardware
A build that's rock solid on the device you tested on can still crash for a reviewer on an older device model, a region setting you didn't test, or with VoiceOver on. We've had a rejection trace back to a date-formatting call that behaved correctly under our locale and threw under theirs. The actual fix was procedural as much as technical: our pre-submission checklist now explicitly runs the build against at least one non-default region and one older supported device, every time, not just when a feature "seems risky."
Guideline 5.1.1 — the privacy label has to match the code, not the intent
This one's less about malice and more about drift. A feature gets removed, the data collection behind it doesn't get removed from the App Privacy nutrition label, and now the label overstates what the app does. The reverse happens too — a new feature ships and the label undersells it. Either direction gets flagged. The only fix that actually holds over time is treating the privacy label as part of the diff for any PR that touches data collection, not as a one-time form filled out at first submission and forgotten.
Guideline 3.1.1 — subscription screens get read literally
On our subscription apps, reviewers read the paywall copy the way a regulator reads fine print, not the way a user skims it. Ambiguous trial language, a price that isn't visible before the purchase sheet, a "restore purchases" button that's hard to find — any of these can trigger a rejection even when the underlying StoreKit implementation is correct. The fix is writing paywall copy as if it will be read adversarially, because for one reader, it will be.
Guideline 2.3 — screenshots are a contract, not a preview
Metadata rejections are the easiest to prevent and the easiest to get lazy about. A screenshot showing a feature that shipped in a later build than the one currently under review, or UI text that doesn't match what's actually on screen, reads to Apple as misrepresentation even when it's just a stale asset. We now regenerate screenshots as part of the release checklist for every submission, not only for releases that "changed the UI enough to matter" — that judgment call is exactly where staleness sneaks in.
None of these rejections cost us a launch — they cost a review cycle, which on a bad week is two or three days of delay. Budgeting for that buffer, and treating each rejection as a checklist item instead of bad luck, is what turned "unpredictable App Review" into a fairly predictable step in our schedule.