Guideline 2.1: How to Fix Crash & Bug Rejections
I'll never forget opening that rejection email at 2am. "We found that your app crashed on iPad Air 2 running iOS 16.4." My app. The one I'd tested for weeks on my own devices. Dead on arrival because of a device I didn't own.
If you're here, you probably just got the same gut-punch. Let me help you fix it.
The TL;DR on Guideline 2.1
Your app crashed or froze during review. Apple's reviewers test on devices you probably don't have, with fresh installs and demo accounts. They found something broken, and now you need to fix it. The good news? Crash rejections are usually quick to resolve once you know what happened.
What is Guideline 2.1, Actually?
Apple's Legalese
"App completeness: Submissions to App Review, including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included. All placeholder text, empty websites, and other temporary content should be scrubbed before submission."
Translation: If your app crashes, shows a blank screen, has a button that goes nowhere, or does anything that makes a reviewer go "huh?"—you're getting bounced. Apple reviewers aren't patient debuggers. They tap around for maybe 5-10 minutes. If something breaks, they screenshot it and hit reject.
What Triggers 2.1
- • App crashes on launch
- • App crashes during normal use
- • Features that don't work
- • Broken links or buttons
- • Network errors without handling
- • Placeholder content ("Lorem ipsum")
What Apple Expects
- • Zero crashes during review
- • All buttons and features work
- • Proper error handling
- • Loading states for slow content
- • Graceful offline behavior
- • Real, final content
The Usual Suspects: What Causes 2.1 Rejections
After seeing hundreds of 2.1 rejections across dev forums and my own painful experiences, here are the scenarios that get developers every single time:
1 The Launch Crash (a.k.a. The Career-Ender)
App doesn't even open. The reviewer taps your icon, sees the splash screen, and boom—crash. They can't test anything else. Instant rejection, no questions asked.
Why this happens:
- • Force-unwrapping nil in Swift (the classic
!that bites everyone) - • Your backend is down or slow to respond during the review window
- • Missing Info.plist keys that iOS 17+ requires
- • Asset catalog missing fonts or images you reference in code
- • Memory pressure on older devices (iPad Air 2 has 2GB RAM)
2 The Demo Account That Doesn't Work
You gave Apple a demo account. But did you actually test it right before submitting? Did you type it correctly? Did it expire? I've been burned by this more than I'd like to admit.
The ways this goes wrong:
- • Typo in credentials (copy-paste from a notes app that added invisible characters)
- • Demo account got auto-deleted by your cleanup job
- • Your auth service has rate limiting that blocks Apple's IP range
- • Sign in with Apple is configured but you never actually tested the Apple ID flow
- • 2FA is required but you forgot to provide codes or disable it for the test account
Pro tip: Test your demo account from a different network (like mobile data) right before you hit submit. And screenshot yourself logging in—helps if you need to argue the credentials worked.
3 The Backend That Picked the Worst Time to Die
Murphy's Law loves app reviews. Your server that's been rock solid for months will choose the exact 10-minute window when Apple's reviewer opens your app to throw a 500 error. And if your app shows a blank screen or a cryptic error? That's a 2.1.
How servers betray you:
- • Scheduled deployment happened to run during review
- • Rate limiting kicked in because the reviewer's IP looks suspicious
- • Your free tier Heroku dyno went to sleep
- • API times out and your app just shows... nothing
- • SSL cert expired (or worse, your cert pinning is rejecting Apple's proxy)
Real talk: Always show something when the network fails. A friendly error message, a retry button, cached data—anything but a blank screen or spinner that spins forever.
4 The "I'll Finish This Later" Features
We've all done it. Ship the MVP, worry about that settings page later. Except the reviewer found your "TODO: implement this" comment or that button that does nothing.
Things you forgot to hide or remove:
- • "Coming Soon" buttons that lead nowhere
- • Lorem ipsum text you used for layout testing
- • A settings tab that's completely empty
- • Navigation items that crash when tapped
- • Profile picture placeholder that never gets replaced
If a feature isn't ready, remove it entirely. Don't show a grayed-out button with "Coming Soon"—Apple hates that.
5 The iPad You Forgot Existed
Your app runs on iPad by default unless you specifically opt out. And guess what? Apple reviewers love testing on iPads. If your layout goes haywire on a 12.9" screen or crashes in landscape mode, 2.1 rejection incoming.
iPad gotchas:
- • UI elements overlapping or off-screen on larger displays
- • Buttons so tiny they're impossible to tap (Apple's HIG says 44pt minimum)
- • Hardcoded widths like
width: 375that don't scale - • Landscape mode crashes because you never tested it
- • Split View and Slide Over causing layout chaos
Don't have an iPad? The Simulator works. Or set your app to iPhone-only in Xcode if iPad support isn't part of your plan.
OK, I Got Rejected. Now What?
Deep breath. You can resubmit as soon as you fix it—there's no penalty or waiting period. Here's how to handle it:
Step 1: Actually Read the Rejection Message
I know, sounds obvious. But Apple's messages contain gold. They'll tell you exactly what broke:
"We were unable to review your app as it crashed on launch on iPad running iOS 17.2. Please see attached crash logs."
Parse this like code:
- • "iPad" — Did you test on iPad? Do you even have one?
- • "iOS 17.2" — Are you testing on this version or still on 16?
- • "on launch" — This is a startup crash, not a deep feature bug
- • "attached crash logs" — They gave you the stack trace. USE IT.
Step 2: Reproduce the Issue
Try to recreate exactly what Apple experienced:
- Test on the same device type and iOS version mentioned
- Do a fresh install (delete and reinstall)
- Test with a new user account (not your developer account)
- Test with VPN to simulate different network conditions
Step 3: Fix the Specific Issue
For Crashes:
- • Analyze the crash log using Xcode's Organizer
- • Add proper nil-checking and error handling
- • Test on low-memory conditions
- • Verify all required frameworks are linked
For Login Issues:
- • Verify demo account still works
- • Test all login methods (email, social, Apple)
- • Provide clear instructions in Review Notes
- • Consider creating a fresh demo account
For Network Errors:
- • Add loading indicators and timeouts
- • Show user-friendly error messages
- • Implement retry mechanisms
- • Add offline mode or graceful degradation
Step 4: Resubmit with Confidence
Before resubmitting:
- Confirm the fix works on the exact device/OS mentioned
- Test the entire user flow, not just the broken part
- Update Review Notes explaining what you fixed
- Increment build number and submit new binary
Debugging Crashes
Reading Crash Logs from Apple
Apple sometimes attaches crash logs. Here's how to read them:
- 1 Download the .crash or .ips file from the Resolution Center
- 2 Open Xcode → Window → Devices and Simulators
- 3 Drag the crash file into the device logs
- 4 Xcode will symbolicate it if you have matching dSYM files
Using Crash Reporting Services
Integrate crash reporting to catch issues before Apple does:
Firebase Crashlytics
Free, real-time crash reporting with stack traces and user data.
Sentry
Error tracking with context, breadcrumbs, and release health.
Bugsnag
Stability scoring and automated issue prioritization.
Xcode Organizer
Free crash reports from TestFlight and App Store users.
Prevention Checklist
Use this checklist before every submission to avoid 2.1 rejections:
Stability Testing
- Fresh install on physical device works
- Tested on oldest supported iOS version
- Tested on iPad (if applicable)
- Tested in airplane mode / poor network
- Memory warnings don't cause crashes
User Flow Testing
- All buttons and links work
- Login/signup flow tested with demo account
- All screens have real content (no placeholders)
- In-app purchases complete successfully
- External URLs open correctly
Backend Readiness
- API servers are stable and monitored
- Demo account credentials are current
- No rate limiting on reviewer IPs
- SSL certificates are valid
Error Handling
- Network errors show helpful messages
- Loading states for slow operations
- Empty states handled gracefully
- Retry options for failed requests
Related Guides
How to Handle Rejection
Step-by-step guide to responding to App Store rejections and getting approved.
Guideline 4.2: Minimum Functionality
Another common rejection reason - learn how to add enough value to pass review.
Review Times 2025
Current App Store review times and what to expect after fixing your rejection.
Questions I Get Asked All the Time
"But it works fine on MY phone!"
This is the #1 thing developers say after a 2.1. Here's the thing: Apple tests on devices you don't have, iOS versions you might not be running, with fresh installs and zero cached data. They might be on iOS 17.4 beta. They might use an iPad Air 2 with 2GB RAM. They definitely don't have your development environment's configuration.
Can I resubmit immediately?
Yes! No waiting period, no penalty. Fix it, bump your build number, submit again. Resubmissions after a rejection usually get reviewed faster too—often within 24 hours vs. the 24-48 hours for first submissions. Apple prioritizes developers who are actively fixing issues.
Am I going to get banned for multiple rejections?
No. Apple doesn't ban developers for 2.1 rejections—they just want working apps. I've seen developers get rejected 5+ times on the same app and eventually get approved. Now, if you keep submitting the exact same broken build? That's suspicious. But legitimate iteration is fine.
What's the difference between 2.1 and 2.3?
2.1 = your app is broken (crashes, bugs, incomplete). 2.3 = your app works but your metadata is misleading (screenshots show features you don't have, description promises things you can't deliver). A crash is always 2.1. Fake screenshots are 2.3.
Should I use App Review Board to escalate?
For a 2.1 crash rejection? Almost never. The crash happened. Arguing won't make it un-crash. Save the appeal board for subjective rejections like 4.2 or 4.3 where you genuinely disagree. For 2.1, just fix it and resubmit.
Avoid 2.1 Rejections Before You Submit
Our AI-powered review tool simulates Apple's testing process, catching crashes and bugs before they cause rejection.
Try AI Pre-Review