App Store
Every app submitted to the App Store goes through App Review — a mix of automated checks and a human reviewer who actually installs and uses your build. First-time founders often imagine review as a formality, then get a rejection notice referencing a guideline number they've never seen. It's not arbitrary. Apple's App Review Guidelines are organized into five numbered sections, and the overwhelming majority of rejections we see trace back to the same handful of subsections.
2.1 is the workhorse rejection reason. It covers crashes, broken links, placeholder text ("Lorem ipsum" screenshots do happen), and — this one catches people constantly — a login-gated app with no working demo account in the review notes. If your app requires sign-in before a reviewer can see anything, and you haven't supplied a test account with the App Review Information section of App Store Connect, the reviewer can't get past your login screen and will reject on completeness grounds. It's an easy fix and an easy miss.
4.2 exists to keep the App Store from filling up with thin wrappers around a website. If your app is a WebView pointed at your marketing site with no native functionality, or if it duplicates dozens of other submissions using the same template with only branding swapped, expect a 4.2 rejection. This is also where "your app should feel at home on the platform" lives — an app that ignores standard iOS navigation and interaction patterns entirely can get flagged here, separate from any bug.
If your app unlocks digital content or services — a subscription, extra credits, premium features, digital goods of any kind — that transaction has to go through Apple's In-App Purchase system, not a link to an external checkout page. This is the rule that surprises founders coming from the web, where "just add a Stripe button" is normal. There are real exceptions (the Reader app exception for content consumed elsewhere, and physical goods/services consumed outside the app, like ordering food or booking a hotel room, are exempt), but digital content and functionality inside the app itself has to use IAP. Routing around it with a hidden web checkout is one of the fastest ways to get an app pulled entirely, not just rejected.
Your privacy policy has to be live at a public URL before you submit — a placeholder or a policy that 404s is an automatic hold. Since App Store Connect requires an App Privacy "nutrition label" — the questionnaire that declares which data types you collect and whether they're linked to identity or used for tracking — that questionnaire has to match what the app actually does. Apple has pulled apps post-launch when a later review found the declared label didn't match observed behavior. Since 2022, guideline 5.1.1(v) also requires that if your app lets users create an account, it has to let them delete that account (and the associated data) from inside the app, not just via an email to support.
Screenshots, the app description, and the app name have to reflect what the app actually does today, not what's on your roadmap. Screenshots of a feature that isn't shipped yet, or comparison language against a competitor, will get flagged during metadata review — which is a separate pass from the functional review and can bounce your submission back even after the build itself passes.
A rejection arrives in App Store Connect's Resolution Center as a specific guideline citation plus a short explanation, sometimes with a screenshot of exactly where the reviewer got stuck. It is not a form letter — reviewers reference the specific screen, flow, or piece of metadata that triggered the note. Reply in the same thread rather than resubmitting blind; you can ask a clarifying question if the note is genuinely ambiguous, and reviewers do respond. Resubmitting the identical build with no changes, hoping for a different reviewer, is a bad strategy — the same issue is still there, and it wastes a review cycle you could have used to actually fix it.
2.5 covers software requirements below the surface level: apps calling private, undocumented APIs, or built against SDKs old enough that Apple has stopped accepting them for new submissions. Static analysis catches most of this automatically before a human ever looks at your build, which means it's one of the few rejection categories you can usually rule out entirely just by building against a current SDK and avoiding anything you had to work around Apple's public APIs to access.
None of this is exotic. The pattern across almost every rejection we've helped clients resolve is the same: something that works fine on the developer's own phone, with the developer's own account, in the developer's own network conditions, fails the moment someone outside that context tries it. Review your submission the way an impatient stranger would use it, and most of Apple's rejection reasons stop being a mystery.
More from the journal
Launch
Launch day is the easy part. The work that determines whether it goes well happens weeks earlier — here's the sequence we actually follow.
Engineering
Cross-platform frameworks have closed most of the historical gap with native — but not all of it. Here's the actual decision framework, not a philosophy war.
Strategy
Most first-time founders overscope their MVP by two or three features. Here's how to find the smallest version that actually tests your idea.