Guideline 2.1 Performance Crash Fix — Stop Getting Rejected

Guideline 2.1 is the single most common reason apps get rejected from the App Store. If you have received a rejection citing "Guideline 2.1 — Performance — App Completeness," you are not alone. Apple uses this guideline as a broad catch-all for anything that makes your app appear unfinished, broken, or incomplete during review.

The official text reads:

We found that your app crashed on launch, includes content or features that are not yet fully implemented, or contains placeholder content. We expect apps submitted for review to be fully functional.

What Apple really means: your app did not work correctly on the reviewer's device. That could be a hard crash, a blank screen, placeholder text, an unreachable server, missing demo credentials, or a debug menu still visible in your production build. The fix depends on which specific sub-issue triggered the rejection — and that is exactly what this guide covers.

What Triggers Guideline 2.1 Rejections

Guideline 2.1 rejections generally fall into five categories:

1. Crashes — The app crashed on launch or during normal use on the reviewer's device
2. Placeholder content — Lorem ipsum text, TODO markers, or test data visible in the app
3. Beta indicators — Text like "Beta," "Test," or "Debug" in the app name or UI
4. Broken features — Buttons that do nothing, screens that fail to load, features behind a paywall with no way to test
5. Demo account issues — The reviewer cannot sign in because credentials are missing, expired, or blocked by 2FA

Each of these has a different root cause and a different fix. Let us walk through them one at a time.

Crashes: The Most Common 2.1 Rejection

A crash on the reviewer's device is the most frequent trigger for Guideline 2.1. Your app may work perfectly on your development device but crash during review for reasons specific to the review environment.

Missing Entitlements

If your app uses push notifications, iCloud, HealthKit, Sign in with Apple, or any other capability that requires an entitlement, that entitlement must be configured correctly in both your provisioning profile and your Xcode project. A mismatch between your development and distribution profiles is one of the most common causes of launch crashes during review.

Check your entitlements file (.entitlements) and make sure every capability you use is listed. If you added push notifications during development but forgot to enable the capability in your App ID on the Apple Developer portal for your distribution profile, the app will crash at launch during review.

Missing Permission Prompts

iOS requires a usage description string for every protected resource your app accesses. If your code calls AVCaptureDevice.requestAccess(for: .video) but your Info.plist does not include NSCameraUsageDescription, the app will crash at runtime.

Here are the most commonly missed entries:

<key>NSCameraUsageDescription</key>
<string>This app uses the camera to scan documents.</string>

<key>NSPhotoLibraryUsageDescription</key>
<string>This app accesses your photo library to let you choose a profile picture.</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>This app uses your location to show nearby results.</string>

<key>NSMicrophoneUsageDescription</key>
<string>This app uses the microphone for voice messages.</string>

Every NS...UsageDescription key must have a human-readable string that explains why the app needs access. Generic descriptions like "This app needs camera access" may also trigger a separate metadata rejection. Be specific about how the permission is used.

Network Edge Cases

Apple reviewers may test your app in network conditions you never considered. Common scenarios that cause crashes:

• No internet connection — If your app immediately calls an API on launch and force-unwraps the response, a network timeout will crash the app. Always handle the offline case gracefully, even if your app requires a network connection to function.
• Unexpected API responses — Your staging server might return well-formed JSON, but if the reviewer's request hits a different endpoint, returns a 500 error, or your server is temporarily down during review, the app needs to handle it without crashing.
• SSL certificate issues — If your API uses a self-signed certificate or an expired certificate, the request will fail silently on some devices and crash on others depending on how you handle the error.

Architecture Issues

If you are submitting a build that does not include the arm64 architecture slice, it will not run on any device Apple uses for review. This happens most often when developers build with Rosetta translation enabled or submit a simulator build by mistake.

Verify your build architectures:

lipo -info YourApp.app/YourApp

The output must include arm64. If it only shows x86_64, you are submitting a simulator build.

Entitlement Signing Mismatches

A subtle but common problem: your debug configuration uses a development provisioning profile with one set of entitlements, and your release configuration uses an App Store distribution profile with a different set. The app works in development but crashes in production because the entitlements do not match.

In Xcode, compare your entitlements between Debug and Release build configurations. Make sure any capability you use in your code is present in your distribution provisioning profile.

Placeholder Content

Apple's reviewers manually inspect your app's screens. If they spot anything that looks unfinished, it triggers a 2.1 rejection.

Lorem Ipsum and Dummy Text

Search your entire codebase and all localization files for strings that should have been replaced before submission. Common offenders include:

• Lorem ipsum text in any language file or view
• TODO, FIXME, or HACK comments that leaked into user-visible strings
• Hardcoded strings like "test", "asdf", or "placeholder" in UI labels
• URLs pointing to example.com, localhost, or staging.yourapi.com

Run a simple search before every submission:

grep -ri "lorem\|todo\|fixme\|example\.com\|localhost\|placeholder" --include="*.swift" --include="*.strings" --include="*.plist" .

Default Xcode Assets

If your app still uses the default Xcode app icon (the blank white square) or includes default storyboard placeholder screens, Apple will reject it. Every asset in your app must look intentional and finished.

Test Data in Screenshots

If your App Store screenshots show test accounts, dummy data (like "John Doe" or "user@test.com"), or incomplete content, reviewers may flag the app as unfinished even if the binary itself is fine.

Beta Indicators Left in Production

Apple specifically looks for signs that you are submitting a beta or test version rather than a finished product.

Text Indicators

Search your app name, display name, and all user-facing strings for:

• "Beta"
• "Test"
• "Debug"
• "Dev"
• "Staging"
• "WIP"
• "Coming Soon" (on core features)

Any of these in your app's name, splash screen, or navigation will trigger a rejection. This also applies to your CFBundleDisplayName and CFBundleName in Info.plist.

Debug Menus and Logging

If your app has a hidden debug menu that can be accessed by tapping a certain area of the screen, shaking the device, or entering a special code, remove it or gate it behind a build flag that is disabled in your release configuration. Apple reviewers sometimes discover these.

Visible console output is another flag. If you are using print() statements or a logging framework that outputs to the console, it will not cause a rejection on its own, but visible debug overlays or log viewers will.

TestFlight-Only Code Paths

If your app has logic that checks for TestFlight distribution and enables or disables features based on it, make sure that logic does not accidentally hide core functionality in the App Store build. A common pattern is:

// Don't do this — it hides features during App Store review
if Bundle.main.appStoreReceiptURL?.lastPathComponent == "sandboxReceipt" {
    showBetaFeatures()
}

This check detects sandbox environments, which includes both TestFlight and App Store review. Features gated behind this check will be invisible to the reviewer.

Demo Credentials — Writing Review Notes Correctly

If your app requires a login, Apple's reviewers need a way to access the content behind that login. This is where many developers get rejected, not because their app is broken, but because the reviewer could not sign in.

When to Provide Credentials

You must provide demo credentials any time your app:

• Requires account creation or sign-in to access core functionality
• Uses a third-party login (Google, Facebook, etc.) as the only sign-in method
• Requires a subscription to access content
• Has location-restricted features the reviewer might not be able to access

How to Format Review Notes

In App Store Connect, there is a "Notes for Reviewer" field on the app version page. Here is a format that works reliably:

Demo Account:
Email: reviewer@yourdomain.com
Password: AppReview2026!

This account has full access to all app features including premium content.
No 2FA is enabled on this account.

If the app requires location access, please allow it — the app shows
nearby restaurants based on your current location. Sample data is
available in the San Francisco Bay Area.

For in-app purchases, use a sandbox Apple ID. All subscription tiers
are available for testing.

Common Mistakes

• Expired credentials — If you created the demo account months ago and your system has a password expiration policy, the password may no longer work when the reviewer tries it. Test the credentials yourself on the day you submit.
• 2FA blocking the reviewer — If the demo account has two-factor authentication enabled and the verification code goes to your phone, the reviewer cannot sign in. Disable 2FA on the demo account.
• Wrong environment — If your app points to a staging server during review but the demo account only exists on production (or vice versa), the login will fail.
• Social-only login — If the only way to sign in is via Google or Apple, the reviewer may not want to use their personal account. Provide an email/password alternative or explain clearly in the review notes.

Real Rejection Examples

These are patterns that show up frequently in developer forums and rejection reports:

"Unable to sign in" — An app with mandatory login was submitted without demo credentials. The reviewer tapped "Sign In," saw a login form, had no credentials, and rejected. The fix: add demo credentials in App Store Connect review notes.

"App crashed on launch" — A developer enabled the push notifications entitlement in their Xcode project but forgot to enable it in the App ID on the Apple Developer portal. The distribution provisioning profile did not include the aps-environment entitlement. The app launched fine with the development profile but crashed immediately with the distribution profile. The fix: regenerate the provisioning profile after enabling the capability in the Developer portal.

"Placeholder content detected" — A to-do list app shipped with pre-populated sample tasks including "Test task 1," "Fix this later," and "Lorem ipsum." The reviewer flagged these as placeholder content. The fix: either ship with an empty state and a clear onboarding prompt, or use realistic sample data that looks intentional.

"App does not load content" — An app that fetches all content from a remote API was submitted while the API server was undergoing maintenance. The reviewer opened the app, saw a blank screen with a spinner that never resolved, and rejected. The fix: implement proper error states, retry logic, and timeout handling.

15-Point Prevention Checklist

Run through this checklist before every App Store submission to catch Guideline 2.1 issues before Apple does.

1. Test on a clean device or fresh install. Delete the app and reinstall from the archive build. Cached data and keychain items from development can mask issues that a first-time user (or a reviewer) would hit.

2. Test without network connectivity. Enable airplane mode and launch the app. It should not crash. Display an appropriate error message or offline state instead.

3. Verify all entitlements match between dev and prod. Compare your development and distribution provisioning profiles. Every capability in your Xcode project must be enabled in your App ID on the Apple Developer portal.

4. Search your codebase for "TODO," "lorem," and "test." Run a project-wide search for placeholder strings. Check localization files, storyboards, and SwiftUI previews. Remove or replace everything that looks unfinished.

5. Check that all NSUsageDescription keys are present. For every protected resource your app accesses (camera, microphone, location, photos, contacts, calendars, health data), confirm the corresponding usage description key exists in your Info.plist with a specific, human-readable explanation.

6. Remove all debug and beta UI indicators. Search for "beta," "debug," "test," "staging," and "dev" in your app's display name, bundle name, and all user-facing strings. Remove or replace them.

7. Test on the minimum supported iOS version. If your deployment target is iOS 16, test on an iOS 16 device or simulator. APIs that are available on iOS 17+ will crash on older versions if you are not using availability checks.

8. Provide demo credentials if login is required. Add working credentials to the App Store Connect review notes. Test them yourself on submission day. Ensure 2FA is disabled on the demo account.

9. Test with a new Apple ID (not your developer account). Create a fresh Apple ID and test the full onboarding flow. Your developer account may have special entitlements or data that masks issues.

10. Verify push notification entitlement matches. If your app registers for push notifications, confirm the aps-environment entitlement is set to production in your distribution profile. A mismatch here is one of the most common crash causes during review.

11. Test on both iPhone and iPad if your app is universal. Even if you only target iPhone, if your app runs on iPad (which it does by default unless you restrict it), test the iPad layout. Broken layouts on iPad trigger rejections.

12. Check that all API endpoints are production URLs. Search for localhost, 127.0.0.1, staging, and any development domain names in your codebase. Replace them with production URLs.

13. Remove TestFlight-only code paths. If you have logic that detects sandbox receipt environments, make sure it does not hide features from the App Store review build. Reviewers run your app in a sandbox environment.

14. Verify the app launches within 5 seconds. If your app takes too long to launch, the system watchdog will terminate it. This shows up as a crash in Apple's logs. Defer heavy initialization to after the launch screen disappears.

15. Test all in-app purchase flows end-to-end. If your app includes subscriptions or one-time purchases, test the full flow in the sandbox environment. Broken IAP flows are a common 2.1 rejection trigger because the reviewer cannot access paywalled content.

Final Thoughts

Guideline 2.1 rejections are frustrating because the rejection message is often vague. Apple tells you the app "crashed" or "includes placeholder content" but rarely points to the exact screen or code path. The best defense is a systematic pre-submission process that catches these issues before the reviewer does.

Most 2.1 rejections come down to one thing: the app was not tested in the same conditions the reviewer experiences. They use a clean device, a fresh install, a sandbox Apple ID, and a potentially unstable network connection. If you replicate those conditions in your own testing, you will catch the majority of issues before they become rejections.

If you have already been rejected, read the rejection notes carefully, check the crash logs in App Store Connect (under the Resolution Center or the Crashes tab), and address the specific issue before resubmitting. Resubmitting without fixing the root cause will result in the same rejection and may delay your review times further.