You survived development. The bug fixes, the merge conflicts, the more bug fixes. Your app finally works, and you're ready to ship it to the world.
Then App Review says no.
Here's the part we tell every client up front: getting through Apple's review is the step you control the least. Your app gets looked at by different reviewers on different days, each with a slightly different read of the same rulebook. Walk in expecting at least one rejection for something small, and a clean pass feels like a bonus instead of a gut punch.
There are roughly two flavors of rejection - technical and content. Here's what actually trips teams up, and how to clear each one before you submit.
Technical Reasons Apple Rejects Apps
1. Crashes and broken builds
Guideline 2.1 covers app completeness, and it's the most common rejection there is. Incomplete bundles, binaries that crash, obvious technical failures - all instant no's. Test on real devices, not just the simulator. If your app falls over on launch or chokes halfway through a core flow, Apple will find it, because that's literally the first thing a reviewer does.
2. Sluggish performance
It doesn't matter how slick your app looks if it stutters. Slow loads, janky navigation, a home screen that confuses people on first open - Apple treats a bad experience as a reason to reject, not just a reason to leave a one-star review. Profile your app under real conditions, on older hardware, on a weak network. Smooth is a requirement, not a nice-to-have.
3. Privacy and data handling
Guideline 5.1.1 is strict, and it's gotten stricter. Every app needs a privacy policy link in App Store Connect and inside the app itself, somewhere a user can actually find it. You also need to fill out the App Privacy "nutrition label" honestly - what you collect, why, and whether it's tied to identity. Let users withdraw consent. If you collect anything, App Tracking Transparency and GDPR aren't optional. Reviewers cross-check your label against what your binary actually does, so don't guess.
4. Broken or placeholder links
Every URL you ship has to work. Support links, privacy links, in-app links - all of them. Placeholder text, empty landing pages, "coming soon" screens, and lorem ipsum need to be gone before you submit. Apple calls out broken links constantly as a top rejection reason. Tap every link in your build like a suspicious QA lead, because that's exactly who's about to.
5. Device and OS compatibility
Guideline 2.4.1. Your app has to run on current hardware and the current OS - and yes, that includes iPad, which Apple weights heavily. It also can't hammer the device: no runaway battery drain, no overheating, no memory it never gives back. Test across a real spread of screen sizes and iOS versions, not just the one phone on your desk.
6. Payments that route around Apple
Guideline 3.1.1. If people buy digital content or unlock features inside your app, that money goes through Apple's in-app purchase system. Full stop. We've watched an app get flagged for a single link to an outside site that sold seminar tickets - content that had nothing to do with the app's core function. Anything that looks like money changing hands outside Apple's rails draws attention. Sometimes you can appeal and win. Sometimes the feature has to change. Physical goods and services are a different lane, but if it's digital, assume Apple takes their cut.
7. Not enough there there
Guideline 2.2. Apple rejects apps that read as demos, trials, or thin wrappers. If your whole app is a contact form and nothing else, there's no reason for it to exist as an app - and Apple agrees. Every screen needs real, final content. No test data, no "we'll fill this in later." The app has to be genuinely useful on the day it ships.
Content Reasons Apple Rejects Apps
8. It looks like a copycat
Guideline 4.1. Ride the latest trend with a near-identical clone and Apple sees clutter, not a contribution. There's a subtler version of this too - white-label apps. If an app is built once and rebranded for multiple companies, each company has to submit under its own account with its own certificates. One developer can't push the same app for a dozen clients. We built a white-label product for a client planning to resell it, and once the per-client certificate reality set in, we reworked the whole distribution approach with them. Worth knowing before you architect around it.
9. A description that oversells
Your store listing has to match what the app actually does. Promise features that aren't there, or describe it as something it isn't, and you get rejected for misleading users. Keep it short, specific, and true. The screenshots have to match the current build too - stale marketing shots count against you.
10. Interface that ignores the guidelines
Read Apple's Human Interface Guidelines before you design, not after you get dinged. They're the baseline for how iOS is supposed to look and feel. Off-platform patterns, mystery-meat navigation, and tap targets built for ants all read as sloppy to a reviewer trained on Apple's own conventions.
11. Confusing to use
The first question during testing: is this actually easy to use? Walk the navigation, the core journey, every custom feature you invented. If it fights standard iOS behavior - swipes that do the wrong thing, gestures nobody expects, flows that dead-end - it's back to the drawing board. Reviewers are users too, and they bail fast.
12. Missing metadata
The quiet one. Apple rejects submissions where the review info is thin or out of date. Give them what they need: real contact details, an accurate title and description, correct category, any configuration notes, and a demo account or video if a reviewer can't reach your app's value without one. Behind a login? Hand over working test credentials. The more complete your submission, the less back-and-forth you buy yourself.
The Real Takeaway
None of these are exotic. They're the boring, checkable things that slip when you're racing to ship. Build a submission checklist from the twelve above and run it before every release, and a rejection stops being a mystery and becomes a line item you already handled.
We've been shipping mobile apps since 2016 and pushed 100+ products through this exact gauntlet, so we've collected our share of rejection emails and learned how to answer them. If you'd rather spend your energy building the app than decoding App Review, let's talk.