Your iOS app passes internal testing, but Apple rejects it under Guideline 2.1. The rejection message mentions a crash, incomplete functionality, or an issue the reviewer encountered.
What should you do next?
Apple's Guideline 2.1, also called App Completeness, requires submitted applications to be stable, complete, and accessible during review. Rejections commonly involve crashes, broken features, unfinished content, or inaccessible accounts.
Instead of immediately uploading another build, developers should identify and reproduce the exact issue Apple reported.
What Does Apple Guideline 2.1 Mean?
Guideline 2.1 focuses on whether an application is ready for public release.
Apple expects developers to submit a complete application that works on supported devices and provides access to its intended functionality.
Common problems include:
-Application crashes during startup or navigation.
-Login credentials that prevent reviewers from accessing features.
-Buttons or screens that don't work.
-Placeholder text or unfinished functionality.
-Backend services that are unavailable.
-In-app purchases that reviewers cannot access or test.
Not every rejection requires extensive code changes. Some can be resolved by correcting review information or enabling the necessary services.
For a broader explanation of these issues, see this guide covering why Apple rejects apps and how developers can fix them.
Step 1: Read the Exact Rejection Message
Start by opening the rejection details in App Store Connect.
Apple may provide screenshots, descriptions, device information, or crash reports showing what went wrong.
Look for three important details:
- Which feature failed?
- What device or iOS version was involved?
- What actions did the reviewer take before the failure?
For example, a reviewer might report that the application closes after selecting the profile screen.
That is much more useful than treating the rejection as a general stability problem.
Record the reported behavior and investigate that specific workflow first.
If Apple's explanation is unclear, ask for additional details through App Store Connect.
Step 2: Reproduce the Issue Using the Release Build
A common debugging mistake is testing only the latest development build.
The code running locally may be different from the version Apple reviewed.
Install the submitted release build through TestFlight or another appropriate distribution method and reproduce the reviewer's steps.
Test the affected workflow on a physical device, preferably matching the device and iOS version mentioned in the rejection.
For example, if Apple reports a crash while opening a user profile:
- Install the submitted build.
- Launch the application with a fresh session.
- Sign in using the review account.
- Navigate to the profile screen.
- Repeat the actions described by Apple.
- Capture logs when the failure occurs.
If the issue cannot be reproduced, investigate differences in network conditions, account permissions, device settings, and backend responses.
Step 3: Examine Crash Logs in Xcode
When a rejection involves a crash, logs can help identify the failing code.
Open Xcode Organizer and inspect available crash reports. Apple's attached diagnostic files may also provide useful information.
Look for the exception type, crashed thread, and relevant application stack frames.
For example, an application might crash because code assumes an API response always contains a valid username.
let username = response["username"] as! String
If the API returns a missing or unexpected value, this forced cast can terminate the application.
A safer approach is:
guard let username = response["username"] as? String else {
// Handle the missing or invalid value
return
}
This doesn't solve every possible API problem, but it prevents this particular unsafe cast from crashing the app.
After fixing the defect, verify the expected behavior and run regression tests on the affected workflow.
Step 4: Check Login and Backend Access
Sometimes the application works for the development team but fails during Apple's review because the reviewer cannot access it.
Possible causes include:
- Expired demo account credentials.
- Mandatory OTP verification.
- Region-based access restrictions.
- Disabled test accounts.
- Backend downtime.
Missing permissions for specific features.
Try signing in from a fresh installation using the exact credentials provided to Apple.
Test from a different network and confirm that no internal account settings are required.
Ensure the review account can access all relevant features and that required backend services remain available during review.
Step 5: Remove Incomplete Features and Test Purchases
Guideline 2.1 also covers incomplete application experiences.
Look for unfinished screens, placeholder content, broken navigation, and features that appear available but cannot be used.
For applications offering in-app purchases, verify that products are configured correctly and accessible to reviewers.
Use Apple's sandbox environment to test purchase flows, entitlement activation, and restoration behavior.
If a feature requires special instructions, document them clearly in the App Review notes.
Step 6: Retest Before Resubmitting
Fixing the reported issue is not enough if the new build introduces another defect.
Before resubmitting, run a focused regression test covering:
Application launch and onboarding.
- Login and logout.
- Primary navigation.
- Previously rejected functionality.
- API error handling.
- In-app purchases, where applicable.
- Application behavior on supported devices.
Confirm whether your changes require a new binary or whether updated review information can resolve the issue.
Once the appropriate fix is ready, reply to Apple with a short explanation of the problem, the changes made, and how the reviewer can verify the result.
Final Thoughts
An Apple Guideline 2.1 rejection doesn't always mean your entire application is unstable.
The problem might involve one crash, an inaccessible account, incomplete content, or a backend configuration that works only in your testing environment.
The most effective debugging process is to examine the rejection details, reproduce the issue on the submitted build, identify the root cause, and verify the fix before resubmission.
Thorough release-build testing can help developers catch these problems before they reach Apple's review team.
Top comments (0)