App Store Guideline 2.1 Rejection: How to Fix App Completeness and Demo Account Issues

When an App Store Guideline 2.1 email lands, don't rush a new build out of panic. Instead, follow this order so you don't get the same rejection twice.

1. Open the App Review section of your app in App Store Connect and read the full message.
2. Write down any screenshot, device model, or OS version the reviewer mentions.
3. Decide what kind of problem it is: sign-in, crash, missing content, or purchases.
4. Test the demo account yourself on a clean install.
5. Confirm your production backend is live and will stay live during review.
6. If needed, upload a new build, update App Review Information, and send a short reply to the message.

What does Guideline 2.1 actually require?

The rule lives in the App Completeness section of Apple's App Review Guidelines. It asks that everything you submit be a final version. In other words, metadata must be complete, URLs must work, and temporary content must be gone. It also expects you to test the app on a real device for bugs and stability before you submit.

In short, the guideline boils down to these points:

• Remove placeholder text, empty websites, and temporary content before you submit.
• If your app has a login, include demo account details and keep your backend service on.
• If legal or security obligations prevent a demo account, you may use a built-in demo mode, but only with prior approval from Apple.
• A demo mode must show the full features and functionality of the app.
• Incomplete bundles and builds that crash or show obvious technical problems will fail review.
• In-app purchases must be complete, up to date, visible to the reviewer, and functional.

So App Store Guideline 2.1 is not a single bug type. It covers both missing information and real technical defects. That's why you should pin down which sub-problem your message points to before you change any code.

How do you read the clues in the rejection message?

Apple's message usually names the guideline, gives a short explanation, and often lists the device the reviewer used. Some messages also attach a screenshot. Those details are the most useful data you have, because they let you reproduce the problem.

In practice, you'll see two broad groups. With the first, the reviewer simply needs information: the demo account fails, or it isn't clear how to reach a feature. In the second, the app crashes, a screen loads empty, or a button does nothing. The first group often needs no new build. The second almost always does.

If the message names a device and OS version, repeat your test under exactly those conditions. For example, if the reviewer tested on an iPad, check how your app launches there even if you designed it for iPhone only. Also compare the time of the message with your server logs to look for errors at that moment.

Why are demo accounts the top cause of App Store Guideline 2.1 rejections?

Because the reviewer opens your app from scratch, in an environment you never planned for. On your own phone, you stay signed in, so a login problem can hide for weeks. On the reviewer's device, it shows up in the first second. If they can't get past the sign-in screen, they can't see anything else, so the review stops.

From our field experience, demo account problems fall into a few repeating patterns:

• The password changed during development but nobody updated App Store Connect.
• The account exists on staging, not in the production database.
• Sign-in waits for email verification or a one-time code by text.
• The trial or subscription on the account has expired.
• No sample data exists for the reviewer to explore.
• The account lacks a role that needs admin approval.

If you can't solve one of these on your own, or your backend is split across several vendors, planning the submission with a partner that offers mobile app development services can save days. If you have your own team, the steps below are usually enough.

How do you fill in the App Review Information section?

This part of App Store Connect is your only official bridge to the reviewer. Apple's App Review Information help page defines three main fields: contact details, notes, and sign-in information. Customers never see this data, and you can edit it at any time, even for an approved version.

• Contact: the name, email, and phone number of someone App Review can reach. The phone number must use international format, starting with a plus sign and the country code.
• Notes: app-specific settings, test registration, or account details. The field has a byte limit, so check the current value on the help page. You can write notes in any language.
• Sign-in required: the demo account username and password. The account must not expire, and extra accounts belong in the notes.

Also, if your app uses a single sign-on service such as Facebook, the help page says to include the demo login for that service too. In practice, reread these fields for every release, because details from an old version can quietly stop working.

What should you write in the review notes?

The notes field is a short map that keeps the reviewer from getting lost. Skip the marketing pitch. Instead, tell them step by step what to do. For example, this skeleton works for most apps:

1. A one-sentence purpose of the app.
2. How to sign in with the demo account and which screen opens next.
3. The taps needed to reach the main feature, in order.
4. Features that need a specific role, location, or device, and how to test them.
5. Where in-app purchases appear, and why any of them might not.
6. Extra demo accounts, for example an admin and a standard user.

Guideline 2.3.1 also asks you to describe new features and product changes with specificity in the review notes and keep them accessible for review. It says generic descriptions will fail. Therefore, don't write a line like "all features work." Instead, state what the reviewer will see on which screen.

What if the demo account needs a text code or two-factor sign-in?

The reviewer can't see codes sent to your phone. So if your sign-in flow uses SMS, email confirmation, or an authenticator app, you need a compliant way for the demo account to pass that step. Otherwise, the account may be technically correct and still unusable.

Workable options include:

• Completing verification for the demo account on the backend ahead of time.
• Setting a fixed test code that only works for this account and listing it in the notes.
• Naming a contact in the notes who can relay a one-time code during review.

However, never open this exception to real users. Tie the fixed code to the demo account only, and make sure you can switch it off after review. In addition, the account must not expire; the help page says so plainly. For subscription apps, keep the demo account's subscription active for the whole review.

When can you use a demo mode instead of a login?

Guideline 2.1 offers an alternative for developers who can't provide a demo account because of legal or security obligations: a built-in demo mode. That route needs Apple's prior approval. In other words, adding a demo mode on your own and mentioning it in the notes is not enough.

For example, apps tied to real personal data, such as banking records or enterprise identity, may struggle to hand out a demo account. In that case, the demo mode should mirror the real flow and show every feature. A half-built showcase screen will simply trigger a new 2.1 rejection.

In practice, first ask whether you truly can't provide an account. Often a separate test tenant on the backend, or an account filled with sample data, creates far less friction than a demo mode. If you still need one, explain the reason clearly in your reply to the rejection and handle approval there.

Why does an offline backend during review lead to rejection?

Review runs on Apple's schedule, not your office hours. Apple's pre-submission checklist asks you to keep backend services live and accessible during review. A nightly maintenance window, a shut-down staging server, or an expired certificate shows up on the reviewer's screen as an empty list or an endless spinner.

Common backend traps we run into include:

• The build still points to a staging URL, and staging is down.
• The server blocks traffic from certain countries.
• A rate limit rule treats review traffic from one network as an attack.
• The API endpoint the new version needs hasn't shipped to production yet.

That's why you should test production end to end with your final build before you submit. If the backend side is new to you, our guide on what backend development means explains the link between an app and its server in plain language.

Does your app work on an IPv6-only network?

Apple's IPv6 support page states that all apps submitted to the App Store must support IPv6-only networks. If your app relies on IPv4-specific APIs or hard-coded IP addresses, it may fail to connect on such a network. The reviewer then sees a connection error or a blank screen.

This problem is sneaky, because everything works on your office network. So if your rejection mentions network errors or data that never loads, add IPv6 support to your checklist. Calling your servers by hostname instead of a raw IP address often fixes the issue on its own.

For a quick first check, our IPv6 test tool shows whether your domain answers over IPv6. Still, do the real check by running the app itself in an IPv6 environment; the tool only tells you about the server side.

How do placeholder content and broken links cause rejection?

The guideline explicitly rules out placeholder text, empty websites, and temporary content. A forgotten "lorem ipsum" paragraph, a button labeled "coming soon," or a sample image left over from a design template tells the reviewer the app isn't finished.

Links fall under the same rule. Your support URL, privacy policy, and in-app web views must all work. For instance, if your privacy policy link opens an empty domain, you can fail review even with a flawless app. For the other privacy requirements, see our guide on how to prepare App Store privacy labels.

Before you submit, run this sweep: visit every screen, read every string, tap every button once, and open every link. Rather than hiding a feature that isn't ready, remove it from this release entirely. That way, both the reviewer and your users get a consistent product.

How do you catch crashing screens before you submit?

Apple's App Review page asks you to submit only items that are complete and ready to publish, and to test thoroughly on devices running the latest software. An app that runs fine in the simulator can still crash on a real device because of memory, permissions, or network conditions.

Therefore, test the final build on real devices with a clean install. Beta testing an iOS app with TestFlight is the most practical route here, since it ships the build to outside testers in the same form review will get. Also, make sure you try these scenarios:

• First launch with no permissions and no data.
• Every permission denied: camera, location, notifications.
• A weak or dropped internet connection.
• Different screen sizes, especially iPad.
• Signing out and signing back in.

If you have a crash report, use Apple's documentation on acquiring and analyzing crash reports; the App Review page points there after a rejection too.

How do in-app purchases fall under Guideline 2.1?

The second part of the guideline asks that in-app purchases be complete, up to date, visible to the reviewer, and functional. If the reviewer can't find or review a product you configured in App Store Connect, you need to explain why in your review notes.

Here's a typical scenario. You add a new subscription tier in App Store Connect, but the paywall only appears for a certain user segment. The reviewer isn't in that segment, so they never find the product. The fix is to state in the notes which screen and which condition reveal it, or to set up the demo account so it meets that condition.

If you haven't settled the payment model yet, our article on in-app purchase vs web payment compares the two paths. Also, if your purchase flow relies on server validation, make sure the backend stays up during review.

What should you do if the app needs hardware, a location, or a QR code?

Some apps depend on something the reviewer doesn't have: a smart device, a physical store, a specific city, or a QR code on a table. Apple's pre-submission checklist asks you to provide any hardware or resources review needs, such as login credentials or a sample QR code.

The App Review page also suggests being ready to provide a demo video or the hardware itself when a feature needs an environment that's hard to replicate. In practice, these approaches work well:

1. Attach the sample QR code as an image and explain in the notes where to scan it.
2. Lock location-based features to a fixed test region for the demo account.
3. Record a short screen capture of the device pairing steps.
4. List the screens the reviewer can open without the hardware.

As a result, the reviewer can judge the app's logic without getting stuck on a physical dependency.

How do you prepare a demo account for review?

From an App Store Guideline 2.1 point of view, a good demo account does more than sign in. After signing in, the reviewer should see the value of your app within a few minutes. An empty home screen, a "no content yet" banner, or an endless onboarding wizard can make the app look unfinished.

So fill the demo account as if a real user had used it for a few weeks. For example, a booking app should show past and upcoming appointments, a shopping app should show a cart and order history, and a team app should show sample messages. Use fully fictional content instead of personal data.

In addition, if your app has several roles, create one account per role. Put the main account in the sign-in fields and the rest in the notes. Finally, make sure nobody changes the demo account during review; if a teammate resets the password, all that prep goes to waste.

How do you split submission duties within a team?

Many Guideline 2.1 rejections come from communication gaps, not code. The mobile developer uploads the build, the backend team migrates the server that night, and the product owner copies notes from the last release. Everyone did their own job right, yet the reviewer sees a broken app.

To prevent that, treat submission day like a small release process:

1. Name one person who owns the submission.
2. Ask the backend team to freeze changes during review.
3. Keep the demo account password in a shared password vault.
4. Rewrite the notes for every release instead of copying old text.
5. Check the contact inbox regularly until approval arrives.

That way, you can answer a reviewer's question within hours instead of stretching the process out.

App Store Guideline 2.1 rejection types and fixes at a glance

The table below maps the symptom in your message to a likely cause and a first step. Treat it as a starting point, and confirm the diagnosis with your own logs.

In short, separating an information issue from a code issue keeps you from uploading needless builds and losing time in the review queue.

How do you reply to App Review after a rejection?

According to Apple's page on how to reply to App Review messages, you can correspond with Apple and include attachments such as screenshots and supporting documents until you resubmit. If the rejection was only about metadata, you can resubmit the same build once you fix the issue.

The reply steps look like this:

1. In App Store Connect, go to Apps and select your app.
2. Click the link at the top of the page that points to unresolved issues.
3. Next to the submission in progress, click Resolve.
4. Click Reply to App Review and type your message.
5. If needed, use Attach File to add a screenshot or document, then send the reply.

Keep your reply short and concrete: say what you fixed, which screens you tested with the demo account, and which steps the reviewer should follow. A helpful tone, rather than a defensive one, also speeds things up.

When does an App Review Board appeal make sense?

Apple's App Review page says that if you believe review misunderstood your app's concept or functionality, you may appeal to the App Review Board. However, the same page asks you to answer any requests for more information first and to submit only one appeal per rejected submission.

For App Store Guideline 2.1, an appeal is rarely the first move. These rejections usually reflect a real access or stability issue. If you can reproduce the problem, fix it instead of appealing. On the other hand, if you've verified everything and the same rejection keeps coming back, reply to the message in detail first, and consider an appeal only if that fails.

The App Review page also mentions video appointments with App Review to discuss the guidelines. If your sign-in flow is complex, that conversation can be more productive than an appeal.

What should you avoid after a Guideline 2.1 rejection?

The biggest mistake is trying to get around review instead of fixing the problem. The following moves make things worse:

• Uploading the same app under a different developer account or a new bundle ID.
• Hiding a problem feature during review and turning it on remotely after approval.
• Writing notes that don't reflect reality.
• Resubmitting the same build again and again without changes.

Hidden features and misleading information can trigger other guidelines and may even lead to account-level action. For a look at how linked-account workarounds play out on the Android side, see our article on a terminated Google Play developer account. Likewise, if you also got a data collection rejection, read our guide to the Guideline 5.1.1 data collection rejection; the two often arrive together.

Which other rejections get confused with Guideline 2.1?

Guideline 2.1 sometimes shows up in the same message as other rules. For example, if your app lets users create an account but offers no way to delete it, a separate rule applies; see our post on Apple’s mandatory account deletion rule. If you use third-party login, also check whether Sign in with Apple is required.

For a broad look at every rejection reason, our guide on the most common app rejection reasons is a good start. On Android, closed testing and policy removals work differently; see our posts on the Google Play 12 testers requirement and on a Google Play policy violation appeal.

This distinction matters, because each rule needs a different fix. Listing every guideline number in the message and handling each one separately lowers the risk of another rejection from a partial fix.

A final checklist before you submit

Run this list for every release, right before you hit submit:

• The demo account exists in production, the password is current, and it doesn't expire.
• The demo account holds sample data for the reviewer.
• Verification code steps work for the demo account.
• The build uses the production server URL, and the backend stays up during review.
• Your app connects on an IPv6-only network.
• No screen shows placeholder text or a dead button.
• The privacy policy and support links work.
• Reviewers can find every in-app purchase, or the notes explain why not.
• Your notes include a step-by-step test path and current contact details.

This list takes five minutes but can save you several days of review cycles. Also, if different people handle submissions on your team, keep the list in a shared document so the process stays consistent.

When should you get professional help?

Most App Store Guideline 2.1 rejections are fixable by your own team with the steps above. Still, an outside view helps in some cases: when the same rejection repeats, when the crash only happens in review, or when backend and mobile sit with different vendors and nobody can tell where the issue lives.

At Talha Aslan and team, we start such cases by reviewing the rejection message, the demo account, and the production environment together. Then we fix what's missing and rewrite the submission notes. The approval decision always belongs to Apple, so nobody should promise you a guaranteed approval.

If you want to build a new app that's ready for review from day one, or bring order to your current submission process, see how we handle iOS and Android app development and get in touch.