App Store rejections are frustrating. You've spent weeks or months building something, you finally hit Submit, and then you wait, only to get a vague rejection email days later. Worse, each round of fixes and resubmissions costs you another 24–48 hours of review time.
Most rejections are preventable. Here are the most common reasons apps fail review, what Apple is actually looking for, and how to catch these issues before you submit.
1. Bugs and crashes
Guideline 2.1 (Performance: App Completeness)
This is the #1 rejection reason by a wide margin. Apple's review team will test your app on current hardware and OS versions. If it crashes on launch, freezes during a common flow, or has obviously broken UI, you're getting rejected.
What to do:
- Test on a real device, not just the simulator
- Test with no network connection, since many crashes happen when the app assumes connectivity
- Test on the oldest OS version you support
- Check for force-unwrapped optionals in Swift, as these are crash magnets
With FlightCheck: The Pre-Submit Audit flags if your minimum deployment target is outdated or mismatched, and the checklist reminds you to verify device testing before submission.
2. Placeholder and incomplete content
Guideline 2.1 (Performance: App Completeness)
Apple will reject your app if it contains placeholder text ("Lorem ipsum", "TODO", "Coming soon"), empty screens, or features that are advertised but not functional. This includes test data left in screenshots.
What to do:
- Search your entire codebase for "TODO", "FIXME", "lorem", "placeholder", "test"
- Check every screen in your app, including settings, onboarding, and error states
- Make sure every button does something or is hidden
With FlightCheck: The Rejection Risk scanner runs 30+ pattern checks across your metadata, specifically flagging placeholder text, "lorem ipsum", "test" content, and TODO markers in your description and What's New fields.
3. Broken or missing links
Guideline 2.1
Every URL in your app and metadata must work. This includes your privacy policy URL, support URL, marketing URL, and any links inside the app itself. Apple's reviewers click all of them.
What to do:
- Test every link in a private/incognito browser window
- Make sure your privacy policy is hosted on a live URL, not localhost
- Don't use URL shorteners, as Apple doesn't trust them
With FlightCheck: The checklist validates that your support URL, privacy policy URL, and marketing URL are all set and reachable. Missing or broken links are flagged as blockers in the Pre-Submit Audit.
4. Insufficient metadata
Guideline 2.3 (Performance: Accurate Metadata)
Your app name, subtitle, description, and keywords need to accurately describe what your app does. Apple rejects apps with misleading titles, keyword stuffing, or descriptions that don't match the app's actual functionality.
Common mistakes:
- Including competitor names in your keywords
- Using generic terms like "best", "free", or "#1" in your title
- A description that reads like an ad instead of explaining what the app does
- Duplicate keywords (wasting precious character limits)
- Exceeding character limits: 30 chars for name, 30 for subtitle, 100 for keywords
With FlightCheck: The Metadata Editor scores every text field in real time: name, subtitle, keywords, description, and What's New. It catches duplicate keywords, character limit violations, promotional language, and gives you an ASO (App Store Optimisation) quality grade with specific suggestions.
5. Screenshot issues
Guideline 2.3.1
Screenshots must show the app running on the device. Apple rejects screenshots that are misleading, show content not in the app, use excessive text overlays that obscure the UI, or don't match the device sizes specified.
What to do:
- Use real screenshots from a device or simulator, not mockups of features that don't exist
- Provide screenshots for every required device size
- Don't include status bars with incorrect carrier names or times
- If you add text overlays, keep them supplementary so the app UI should be clearly visible
With FlightCheck: The Screenshot Studio lets you design and preview screenshots with device frames, check that all required device sizes are covered, and export at the exact resolutions Apple expects, so you never get rejected for size mismatches.
6. Missing or inadequate privacy policy
Guideline 5.1.1 (Data Collection and Storage)
Every app on the App Store needs a privacy policy. Apps that collect any user data, use analytics, or require an account need a policy that specifically describes what data is collected, how it's used, and how users can request deletion.
What to do:
- Host your privacy policy on a public URL (not behind a login)
- List every type of data you collect, even if it's just analytics events
- If you use third-party SDKs (Firebase, AdMob, etc.), mention their data collection too
- Include a data deletion request mechanism if you collect personal data
With FlightCheck: The Privacy Label Builder walks you through Apple's privacy nutrition label categories, helps you identify what data your app collects based on your frameworks and SDKs, and flags if your privacy policy URL is missing from App Store Connect.
7. Missing demo account for review
Guideline 2.1
If your app requires a login, you must provide Apple with a demo account in the App Review Information section. This is one of the easiest rejections to avoid and one of the most common to forget.
What to do:
- Create a dedicated demo account with full access to features
- Make sure the credentials work at the time of review (not expired, not rate-limited)
- If your app uses two-factor auth, provide a way to bypass it for the demo account
- Note any special instructions in the Review Notes field
With FlightCheck: The rejection risk scanner detects whether your app likely requires authentication (based on entitlements and framework usage) and warns you if no demo account credentials are set in your submission metadata.
8. Guideline 4.3: Spam / copycat app
Guideline 4.3 (Design: Spam)
Apple rejects apps that are too similar to existing apps on the store, are essentially web wrappers with no native functionality, or are one of many nearly identical apps from the same developer.
What to do:
- Make sure your app provides unique value, not just a reskinned template
- If you're building a web wrapper, add meaningful native features (widgets, notifications, Siri shortcuts)
- Don't submit multiple apps that do the same thing
This one's harder to catch with tooling because it's a design and product decision. But it's worth knowing about because 4.3 rejections are notoriously vague and hard to appeal.
9. Export compliance (ITSAppUsesNonExemptEncryption)
Not a rejection, but a blocker
If your Info.plist doesn't declare ITSAppUsesNonExemptEncryption, you'll be asked about it manually during every submission. If you answer wrong, your build gets held up.
Most apps only use HTTPS (which is exempt). Set it to NO unless you're implementing custom encryption.
<key>ITSAppUsesNonExemptEncryption</key>
<false/>With FlightCheck: The Binary Analysis tool checks your Info.plist for this key and warns if it's missing, so you don't get stuck in the export compliance questionnaire on every upload.
10. Inadequate binary size or missing architectures
Less common but painful when it happens. If your app's binary is missing a required architecture (e.g. arm64 for Apple Silicon) or your IPA exceeds size limits, you'll be rejected at upload time, not even making it to review.
With FlightCheck: The Binary Size Analysis breaks down your IPA into segments (frameworks, assets, resources, localisations) with warnings for anything unusually large. It shows compressed and uncompressed sizes so you know what users will actually download.
The real cost of rejections
Each rejection costs you 1–3 days of review time. If you're trying to launch on a specific date, hit a seasonal window, or just ship fast, a single preventable rejection can blow your timeline.
The common thread across most of these rejections is that they're checkable before you submit. That's the whole point of FlightCheck: it runs through the same things Apple's reviewers check and gives you a confidence score before you upload. Think of it as a pre-flight checklist for App Store submissions.