There is a careful distinction inside this question. Helping a reviewer reach your real app, with a demo account or clear notes, is not only allowed but encouraged. Showing a reviewer a different app than your users get is bait-and-switch, and it is one of the fastest ways to lose your developer account. The two look similar from the outside but are opposites in intent: one reveals the real experience, the other hides it. Here is where the line sits and what to do instead of faking content for review.
Short answer
No, you cannot show App Review a different experience than your users receive; that is a bait-and-switch and a serious violation that can lead to removal and developer account termination. What you can and should do is help reviewers access your real app, by providing a demo account, enabling a demo mode, or writing review notes, per Apple's guidance on providing demo information. The distinction is access versus deception: giving a reviewer the credentials or steps to see the genuine functionality is fine, while serving a sanitized or different version based on detecting that they are a reviewer violates Guideline 2.3.1. Show the real app, just make sure review can reach it.
What you should know
- Different content for reviewers is banned: it is a bait-and-switch under 2.3.1.
- Helping access is encouraged: demo accounts and review notes are expected.
- Reviewer-detection is the violation: serving a sanitized version based on detecting review.
- Consequences are severe: removal and developer account termination.
- Show the real app: the goal is access to genuine functionality, not a fake one.
Is it allowed to show reviewers different content?
Only if "different" means easier to access, not genuinely different. Apple expects the app a reviewer sees to be the app your users get, so deliberately presenting altered, restricted, or sanitized content to review while serving something else to the public is prohibited. This is bait-and-switch, and Apple treats it as deception rather than a metadata slip, because the approval no longer reflects the real product. The acceptable kind of "different" is purely about access: an app behind a login needs a demo account, a region-locked feature needs notes explaining it, and a hardware-dependent feature needs a description or video. In those cases the reviewer sees your true functionality; you have only removed the barrier to reaching it.
Different content versus a demo account
The table separates the deceptive practice from the sanctioned one.
| Practice | Allowed? | Why |
|---|---|---|
| Demo account so review can log in | Yes | Gives access to the real experience |
| Review notes explaining a feature or region lock | Yes | Helps the reviewer reach genuine functionality |
| Demo mode that shows the real features with sample data | Yes | Same functionality, just seeded data |
| Detecting a reviewer and serving sanitized content | No | Hides the real app; bait-and-switch under 2.3.1 |
| Different backend or feature set for reviewers only | No | The reviewed app is not the shipped app |
The dividing line is whether the reviewer ends up seeing what your users see. Access aids keep the experience genuine; reviewer-detection replaces it. The first is expected practice, the second risks your account.
What should you do instead?
Make the real app easy to review. If your app requires sign-in, create a working demo account and put the credentials in the App Review Information section, and refresh them so they do not expire mid-review. If a feature is gated by region, hardware, or an external event, explain it in review notes and include a short video if it helps. If live data would be empty or sensitive, a demo mode that loads representative sample data into the real features is fine, since the functionality is unchanged. The principle in every case is that you are lowering the barrier to seeing the genuine app, not constructing a substitute for it, which keeps you compliant and usually speeds the review along.
What to watch out for
The first trap is building reviewer-detection, by IP, account flags, or geolocation, to serve a tamer version, which is the exact behavior that gets accounts terminated. The second is letting a demo account lapse, which causes a legitimate rejection for a reason unrelated to deception, so keep it current. The third is confusing demo data with different functionality; sample data in the real features is fine, a different feature set is not. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces the endpoints and conditional logic in your build, which helps you confirm there is no reviewer-detection or hidden conditional backend before you submit. Showing the real app is both the compliant and the simpler path.
What to take away
- You cannot show reviewers a different experience than users get; that bait-and-switch violates Guideline 2.3.1 and risks account termination.
- You can and should help reviewers access the real app with a demo account, demo mode, and review notes.
- The line is access versus deception: lowering the barrier to genuine functionality is fine, serving a sanitized version based on detecting a reviewer is not.
- Keep demo credentials current, use sample data rather than different features, and use a pre-submission scan such as PTKD.com to confirm no reviewer-detection logic ships in your build.
