Guideline 2.1 App Store rejection: what it means and how to fix it

Guideline 2.1 is the rule that sinks the most submissions. Apple says so itself on its App Review page: on average, over 40% of unresolved issues relate to 2.1, the guideline that covers crashes, placeholder content and incomplete information.

This article covers just that one rule: what it includes, its two variants, how the reviewer tests your app, and how to reply, with three rejections I got on my own apps. For the big picture on every rejection reason, read why Apple rejects an app instead.

What is guideline 2.1 App Completeness?

Guideline 2.1 requires the app you send to Apple to be a final, complete version: no crashes, no broken links, no placeholder text, a demo account if the app requires sign-in, and in-app purchases that are visible and working. If the reviewer can't get all the way through your app, that's a 2.1 rejection.

The official text is in the App Review Guidelines, section 2 "Performance". It's split into two parts.

2.1(a) requires every submission to be a final version, with all its metadata and working URLs. Placeholder text, empty websites and any temporary content must be gone before you submit. The app must have been tested on a real device for bugs and stability. If it requires sign-in, you provide a demo account and keep your server running. A built-in demo mode can replace that account, but only with Apple's prior approval, and it has to show every feature of the app. The sentence that sums it all up: "We will reject incomplete app bundles and binaries that crash".

2.1(b) is about in-app purchases: they must be complete, up to date, visible to the reviewer and working. If a purchase set up in App Store Connect can't be found in the app, you have to explain why in the review notes.

What guideline 2.1 actually covers

In practice, a 2.1 rejection happens for one of these reasons:

• A crash. At launch, after a denied permission, with no network. One is enough.
• A broken link. Privacy, terms of use, support: every URL you declare will be opened.
• An unreachable feature. A button that leads nowhere, a required screen you can't get past, an onboarding with no way out. The sneakiest form: invisible on your own phone.
• A missing or expired demo account. The reviewer gets stuck on the sign-in screen, or the account you provided no longer works, or the server is down.
• Filler content. Lorem ipsum, "Coming soon", empty screens, visible test data.
• In-app purchases that can't be found. The subscription exists in App Store Connect, but the reviewer can't find the screen that sells it, or the purchase fails in sandbox. The most common paywall mistakes are in iOS paywall: 7 beginner mistakes.

2.1 Information Needed vs 2.1(a): what's the difference?

Apple's messages don't all carry the same title, and the difference changes how you reply.

"Guideline 2.1 - Information Needed" means the reviewer couldn't finish the review and is asking you a question. A login is missing, an explanation, a way to reach a feature. It's not a bug report yet: it's a request. Sometimes a precise reply in App Store Connect is enough. But if the question reveals a real blocker in the app, you need a new build.

"Guideline 2.1(a) - Performance - App Completeness" means the reviewer found a problem: a crash, a bug, an unresponsive screen. The message usually names the device used and often includes a screenshot. In that case, you fix it, send a new build, then reply.

How Apple tests your app

Put yourself in the reviewer's shoes. Three things matter.

They test on a device you might not have. The rejection message often names the model. Guideline 2.4.1 says iPhone apps should run on iPad whenever possible, and an app designed for iPhone shows up there in compatibility mode, in an iPhone-sized window. My recent 2.1 rejections came from an iPad Air: if you only test on your iPhone, you don't see what the reviewer sees.

They start from a first launch. Fresh app, no cache, no session, no downloaded update.

The network has to work on IPv6 only. Guideline 2.5.5, next to guideline 2.5.4 on background modes, requires the app to work fully on an IPv6-only network, and Apple's IPv6 support page makes it a requirement for all apps submitted since June 1, 2016. The risk comes from a hardcoded IPv4 address: Apple recommends testing on an IPv6-only network with cellular data turned off.

To reproduce these conditions before submitting, TestFlight on several devices is still the easiest way: see TestFlight: testing your iPhone app.

Three rejections I got, and their real cause

Three recent rejections on my own apps, with their real cause.

Solys: a mini-game demo you couldn't win on iPad

Solys is my mini-game alarm clock. On August 18, 2026, a build was rejected with "2.1 Information Needed": Apple asked for a way to get past the game mission. The reviewer was testing on an iPad Air, with the iPhone app in compatibility mode.

The real cause was in the onboarding mini-game demo. Obstacle heights were hardcoded in fixed points. With the card height available on the iPad in compatibility mode, the gap became narrower than the character: the demo was impossible to win. And the "Continue" button only lit up after a win. No way out: the reviewer couldn't see the app.

The fix: geometry proportional to the card's measured size, and a "Skip demo" link that appears after a loss.

The lesson: any step gated by performance needs an unconditional way out. And every required screen gets tested on the smallest supported screen AND on iPad in compatibility mode.

Nolera: a fix the reviewer couldn't see

On September 17, 2026, Nolera was rejected after a review on an iPad Air. The message combined 2.1(a) with other issues. The fix for the reported problem had been shipped through an over-the-air (OTA) update, with no new build.

The problem: on the very first launch, the reviewer sees the code bundled in the build, not the update downloaded afterward. For them, the fix didn't exist.

The lesson: a fix meant for review has to be in the binary you send to Apple.

Clic: the cause wasn't in the app

On September 16, 2026, Clic was rejected. The app itself was up to date. The real cause was elsewhere: the privacy policy published online wasn't up to date about the AI provider being used. This rejection is more of a privacy issue than a 2.1 one, but it shows the same thing: the real causes aren't always what the message suggests.

The lesson: check what's live, not what's in your repo. Open every declared URL on the day you submit.

How to reply in the Resolution Center

After a rejection, your submission moves to "Unresolved Issues" and the conversation with Apple happens in your app's App Review section, still commonly called the Resolution Center. The official process to reply to App Review allows a message of up to 4,000 characters, with one attachment.

Write in English, keep it simple. The reviewer wants three things: what was blocking, what changed, how to check it. Here's the template I use (swap in your own build number and fix):

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

A few rules:

• Answer the question you were asked. On an "Information Needed", lead with the exact answer, not the context.
• Name the build and give the path to the fixed screen, in three or four steps.
• Attach proof. A short video on a device close to the reviewer's saves another round trip.
• Don't plead your case. You can appeal to the App Review Board, but on a deserved 2.1 rejection, it only makes the wait longer. Timelines are covered in App Store review time.

If the reason is still unclear after reading it, the full process is on the app rejected by Apple page.

Review notes and demo account

The App Review Information section of your version, in App Store Connect, is your best defense against 2.1. According to the official reference for these fields, it includes:

• Sign-in required: the username and password for a demo account. This account must not expire. If your app uses a third-party login, provide the credentials for that service.
• Notes: up to 4,000 bytes, in the language of your choice. Anything that helps with testing.
• Contact: a name, an email and a phone number in international format.

What I always put in the notes:

1. The path to each in-app purchase, as guideline 2.1(b) requires.
2. Non-obvious features: a gesture, a permission, time-based content.
3. The demo account's state: subscribed or not, prefilled or empty data.
4. Known limitations: for hardware or an environment that's hard to reproduce, Apple asks you to be ready to provide a video.

And one rule outside the form: keep your server running for the entire review. A test server that's down means a demo account that doesn't work, so a 2.1 rejection.

The 2.1 checklist before submitting

The one I run before every submission, built on my rejections:

• App installed from scratch on the smallest supported iPhone, the largest, and an iPad in compatibility mode
• Onboarding gone through end to end, deliberately failing every step that requires performance
• Every required screen has an unconditional way out
• No fix meant for review shipped only through an over-the-air update
• App launched in airplane mode, then on an IPv6-only network
• Every declared URL opened that same day: privacy, terms, support
• No placeholder text, empty screen or visible test data
• Demo account tested on submission day, no expiration date, server running
• Every in-app purchase found from inside the app and tested in sandbox, restore included
• Review notes that say where the purchases and non-obvious features are

If this is your first release, every earlier step is in publishing an app on the App Store.

Send your submission with someone who's already taken these rejections

The Apple Review Kit brings together my pre-submission checklist, review note templates for the tester, and Claude Code skills that check your project before you submit it.

Just got a 2.1 rejection? The kit also helps you find the cited rule, what it requires, and an example fix and reply. If you want us to go over your submission together right now, book an hour with me on a video call.

Nobody can guarantee Apple will accept your app. What I can do is help you avoid the 2.1 rejections I've already paid for with a review cycle.

Haven't submitted your app yet? The free diagnostic sends you my Apple anti-rejection checklist, guideline 2.1 included, and tells you what's left to do before you submit. If you're still building it, the homepage shows how to create a mobile app with review in mind from day one.

Frequently asked questions

What does "Guideline 2.1 - Information Needed" mean?

The reviewer couldn't finish the review and is asking you a question: a login, an explanation, a way to reach a feature. Reply precisely in App Store Connect. If the question reveals a real blocker in the app, like with Solys, fix it and send a new build.

Do you need a new build after a 2.1 rejection?

For a crash, a bug or a blocking screen, yes: the fix has to be in the binary. An over-the-air update isn't enough, because the reviewer sees the bundled code on first launch. For simple missing information, a reply may be enough.

My app requires sign-in: what should I give the reviewer?

A demo account that doesn't expire, entered in the App Review Information section, and a server that stays up for the entire review. A built-in demo mode can replace that account only with Apple's prior approval, and it has to show every feature.

Can a 2.1 rejection come from something other than the app?

Yes. A dead URL in the listing, an expired demo account, a server that's down or a misconfigured in-app purchase is enough. And sometimes, like with Clic, the real cause is online, not in the code: check everything the reviewer can open.