How to Avoid App Store Review Demo Account Rejection

When you submit your app, an `app store review demo account rejection` can delay your launch. This rejection occurs when Apple or Google reviewers cannot access your app's full functionality due to missing or incorrect login credentials. Addressing this common issue promptly can prevent delays in the app review process. This guide provides concrete steps to set up and submit the necessary demo accounts for a smooth approval.

The Core Problem: Guideline 2.1 and App Functionality

The primary reason for a demo account rejection is that app stores must verify your app functions as advertised. For Apple, this requirement falls under App Store Review Guideline 2.1 - Information Needed. This guideline states, "Provide an active demo account and login information, as well as any other hardware or resources that might be needed to review your app." Google Play has a similar requirement in the Play Console under "App access," which mandates providing full access for review. Reviewers need to test every feature, especially those behind a login, subscription, or complex setup. If they cannot log in or navigate to key sections, they cannot confirm your app meets all guidelines. This leads to an automatic rejection, as the accessibility and functionality of your app cannot be verified.

Create a Dedicated, Persistent Demo Account

To prevent rejection, provide a dedicated demo account with a clear username and password. This account must be stable, always active, and should not expire or be deleted. It serves as the reviewer's access key to your app's complete feature set. For **Apple App Store Connect**, locate the field under `My Apps > [Your App] > App Store tab > App Store > App Review Information > Sign-in Information`. This field allows up to 250 characters for notes. For **Google Play Console**, navigate to `App content` in the left menu, then select `App access`. Here, you specify if all or some parts of your app are restricted and provide access instructions. For an app like a habit tracker called "Mindful Day," create a specific user, such as `reviewer@mindfulday.app`. Assign a strong, yet simple password like `MindfulDay123!`. This account should grant full access, including any premium features offered by your app. Ensure this account is robust and not tied to any personal data.

Handling Two-Factor Authentication (2FA) for Reviewers

Two-factor authentication (2FA) enhances user security but can impede app reviewers. If your app enforces 2FA for all logins, reviewers will become blocked and unable to proceed, resulting in rejection. Reviewers will not attempt to contact you for a 2FA code. The most effective solution is to create a special condition that bypasses 2FA specifically for your demo account. Implement an internal flag in your backend to disable 2FA for accounts from a specific email domain, such as `@review.yourdomain.com`, or for a hardcoded email like `reviewer@yourdomain.com`. This "skip 2FA" mechanism must activate only for the designated demo account and never for regular users in production. If disabling 2FA is not an option, provide a static 2FA code *within the review notes* that remains valid for the demo account. However, this method is less secure and more prone to error. The best practice is to design your system so the dedicated review account does not require 2FA for login. Clearly state your 2FA bypass method in the `Sign-in Information` notes in App Store Connect or the `App access` notes in Google Play Console. For instance, write: "The `reviewer@mindfulday.app` account has 2FA disabled for review purposes."

Pre-populate Test Data for Feature Showcase

An empty app provides little insight into its functionality. Reviewers operate under time constraints and need to quickly grasp your app's features. An account without pre-populated data makes this assessment difficult, even if login is successful. For your "Mindful Day" habit tracker, pre-populate the demo account with 3-5 active habits, including some completed and some overdue, along with a couple of custom habit categories. For a social app, pre-fill some friend connections, a few posts, and some notifications. This mock data allows the reviewer to immediately see how the app works, how it displays information, and how users interact with its core features. This pre-populated data must be persistent and not reset upon app launch or server updates. Mention the inclusion of pre-filled data in your review notes. For example: "The `reviewer@mindfulday.app` account includes several pre-configured habits (e.g., 'Drink Water', 'Meditate') and some historical data to showcase core tracking and progress features." Seeing your app fully functional with data can also help you visualize how your listing will appear to users. You can check this using a tool like the LaunchShots App Store Listing Preview.

Checklist: Submitting with Confidence

Before submitting your app, review this checklist to minimize demo account-related rejections:

1. Create a dedicated demo account: Use a clear, memorable username and password specifically for review.
2. Ensure persistence: Verify the demo account and its data will not expire or be deleted.
3. Grant full access: Confirm the demo account can access all features, including any premium content or in-app purchases.
4. Bypass 2FA: If your app uses two-factor authentication, ensure the demo account can log in without it, or provide a static code in the notes.
5. Pre-populate data: Fill the demo account with realistic, persistent test data to showcase all key features.
6. Document clearly: Add the username, password, and any special instructions (like 2FA bypass or premium feature access) to the `Sign-in Information` field in App Store Connect or `App access` in Google Play Console. Remember Apple's 250-character limit for sign-in notes.
7. Test before submission: Perform a fresh install of your app and try logging in *only* with the provided demo account credentials. Verify you can access all features.
8. Review Privacy Labels: If your app collects any data, ensure your App Privacy Labels accurately reflect what the demo account (and real users) experience.

FAQ

What if my app requires specific hardware or permissions (like camera, location)?

If your app requires special hardware (e.g., an external sensor) or specific permissions beyond the usual (like constant background location), clearly explain this in the App Review Information notes. If a video demonstration or screenshots are necessary to show functionality without the hardware, include a link to an unlisted video or attach relevant screenshots. Reviewers do not have every possible device configuration.

Can I use a temporary or disposable email for the demo account?

While technically possible, using temporary or disposable email services is not advised. These often expire quickly or have strict rate limits, potentially rendering the demo account inaccessible. Use a stable, dedicated email address that you control and ensure it remains active for the lifetime of your app.

Do I need to resubmit demo credentials with every app update?

It is good practice to always verify and resubmit your demo credentials with each major app update, even if the account details have not changed. This confirms to the reviewer that the information is current and valid for the specific build they are reviewing. Minor bug fix updates typically do not require re-verification unless the login flow itself has changed.

My app has in-app purchases. How do reviewers test those?

For in-app purchases, provide instructions for accessing premium features without requiring actual payment. This often involves either using a demo account that automatically has premium access enabled, or providing specific instructions in the review notes on how to trigger a test purchase (e.g., "Tap 'Upgrade to Pro' and use the `iaptest@example.com` Apple ID in the sandbox environment").

What happens if I forget to include demo credentials, or they are incorrect?

If you forget to include credentials or they are incorrect, your app will almost certainly be rejected under App Store Review Guideline 2.1 (Apple) or a similar Google Play policy. You will receive a message explaining the rejection. You must then correct the information in App Store Connect or Google Play Console, upload a new build if necessary, and resubmit your app for review. This introduces unnecessary delays to your launch timeline.

One Practical Next Step

Before your next submission, create your dedicated, persistent demo account with pre-filled data. Then, use the LaunchShots editor to generate screenshots that clearly highlight the features a reviewer would see, ensuring your app's core functionality is obvious from the moment they log in.