# Guideline 2.2 - Performance: Beta Testing - Concept Demonstration App

**Guideline:** 2.2 · **Store:** Apple App Store · **Severity:** high · **Fix difficulty:** hard · **Typical turnaround:** 1-5 days

Canonical URL: https://appstorereject.com/rejections/apple/2/guideline-22-performance-beta-testing-concept-demonstration-app

## Description

Apple is saying your app reads as a pitch, prototype, or sales artifact rather than a finished product that a member of the public could download and actually use. 

Guideline 2.2 exists to keep the App Store free of demos, betas, trial builds, investor decks, and "here's what we could build for you" showcases. The "concept demonstration" variant is a specific flavor: the reviewer concluded that the app's purpose is to show someone what a product would be like — a potential client, an investor, an internal stakeholder — rather than to deliver working value to anyone who downloads it.

This rejection is seldom automated. A human made a judgment call in the first two to four minutes of review, and it is usually triggered by a small number of concrete signals: 
- The words "demo," "beta," "preview," "prototype," "MVP," "proof of concept," "sample," or "coming soon" appearing in the app name, subtitle, description, screenshots, or in-app copy
- Placeholder or lorem ipsum content and obviously fake sample data
- A login wall with no working credentials, so the reviewer only ever saw a marketing splash screen
- A single "Request a Demo" or "Contact Sales" call to action as the primary user action
- A empty states everywhere because the app has no real content yet
- Or an app that exists mainly to display screenshots, videos, or a feature tour of some other product or service. 

The template language you received is standard, but the reviewer chose it deliberately. They formed a specific impression that the build was not for public distribution.

The root cause splits into two very different situations, and you need to be honest with yourself about which one you are in. In the first, you have a real, functional product and the reviewer simply could not see it — blocked by a login, misled by "beta" branding you inherited from your internal roadmap, or confused by an onboarding flow that pushes toward a sales conversation before showing the app. That is a perception problem, and it is fixable in a day or two with copy and access changes plus a clear review note. 

In the second, the app genuinely is a demonstration vehicle: a white-label showcase, a client pitch tool, a portfolio of what your agency can build, or an unfinished shell you are hoping to validate. That is a distribution-channel problem, and the App Store is the wrong channel for it.

The fastest compliant path that preserves your business model depends on which situation applies. If you have a real product, the answer is to remove every demo signal from the metadata and UI, guarantee the reviewer full functional access with working credentials, and resubmit with reproduction steps — no business model change required. 

If the app truly is for a limited, known audience, the answer is not to argue with Apple, it's to move to the correct channel, whether that's TestFlight, Apple Business Manager custom app distribution, or Apple Developer Enterprise Program. Fighting a 2.2 concept-demo rejection with the same build rarely works.

## Common variations

- Your app is designed to demonstrate the app concept to potential customers. Apps on the App Store should be intended for public distribution.
- We noticed your app is intended to showcase or upsell a service rather than provide functionality to App Store users. Apps that primarily promote or preview a product are not appropriate for the App Store.
- Your app appears to be a demo, beta, trial, or test version. Demos, betas, and trial versions of your app don't belong on the App Store — use TestFlight instead.
- Specifically, your app includes placeholder content, sample data, or incomplete features that indicate it is not ready for public distribution.
- Your app appears to be intended for use by a specific business or set of clients rather than the general public. Consider distributing your app through Apple Business Manager as a custom app.
- The app's metadata and in-app content indicate that the app is a preview of an upcoming product. Please resubmit once the app is complete and intended for public release.

## Example rejection email

```
Guideline 2.2 - Performance - Beta Testing

Issue Description

Your app is designed to demonstrate the app concept to potential customers. Apps on the App Store should be intended for public distribution. Apps designed only to demonstrate, showcase, or upsell an app concept or service are not appropriate for the App Store.

Specifically, your app's primary functionality appears to be presenting a preview of a product or service to prospective clients rather than providing usable features to App Store customers. We noticed placeholder content and a "Request a Demo" call to action on the main screen.

Next Steps

To resolve this issue, please revise your app so that it delivers complete, working functionality to all users who download it from the App Store, and remove any references to demonstration, beta, preview, or prototype status from the app binary and metadata.

If your app is intended for a limited audience — such as a specific client, organization, or set of testers — please consider one of the following distribution options instead:

- TestFlight, for distributing pre-release builds to testers
- Custom app distribution through Apple Business Manager or Apple School Manager, for apps built for a specific organization
- Apple Developer Enterprise Program, for proprietary in-house apps distributed to your own employees

Resources

- Learn more about TestFlight beta testing.
- Learn more about distributing custom apps for business.

Please see Attachment for details.

If you believe your app does comply with the App Review Guidelines, you may submit an appeal. Alternatively, you may reply to this message in App Store Connect to provide any additional information that may be relevant to our review.
```

## Resolution steps

## Quick Assessment
- **Risk level:** High — Apple is questioning whether your app belongs on the public store at all, not just how a feature works.
- **Resolution path:** Fix & Resubmit for functional products misread as demos; Strategic Escalation or channel change if the app genuinely serves a limited audience.
- **Typical turnaround:** 1-5 days (1-2 days if it is purely a perception/metadata issue; longer if functionality must be completed)

## The Fix

01. **Decide honestly which situation you are in**
   Ask one question: could a random person who downloads this app today get real, complete value from it without contacting your sales team, without a code you hand out, and without an account you provision manually? If yes, this is a perception problem — continue to step 2. If no, skip to step 9 and change distribution channels. Answering this wrong costs you two or three more rejection cycles.

02. **Strip every demo signal from your metadata**
   Remove the words demo, beta, preview, prototype, MVP, proof of concept, pilot, sample, test, trial, early access, and coming soon from your app name, subtitle, promotional text, description, keywords, and screenshot captions. Also remove phrasing like "see what we can build," "explore our concept," "a preview of," and "request a demo" from all store metadata. Version numbers below 1.0 (0.9.x) reinforce the impression — ship as 1.0.0 or higher.

03. **Strip every demo signal from the binary**
   Search your codebase for the same word list and remove it from splash screens, onboarding copy, empty states, navigation titles, settings screens, about pages, and push notification copy. Remove any "Demo Mode" toggle, developer menu, or environment switcher that is reachable by an end user. Remove watermarks, "Internal Use Only" banners, and any client or agency logo that implies the app was built as a showcase for a third party.

04. **Replace placeholder and sample data with real content**
   Lorem ipsum, obviously fake user names, stock avatars named "User 1," empty feeds, and screens that say "Data coming soon" are the single strongest triggers for this rejection. Every screen a reviewer can reach must show real, plausible, populated content. If your app depends on user-generated content, seed the environment so it is not empty on first launch.

05. **Make the primary call to action a product action, not a sales action**
   If the main button on your home screen is "Request a Demo," "Contact Sales," "Book a Call," or "Learn More," the reviewer will conclude the app is a lead-generation brochure. Demote those to a secondary location such as a Support or About screen, and make the primary action something a user does inside the product.

06. **Guarantee full functional access for review**
   Provide a working demo account in App Store Connect with username and password, and verify it yourself on a clean device right before submission. If your app requires an organization, workspace, invite code, hardware pairing, or backend provisioning, pre-provision a fully populated review account with representative data. If a physical device or peripheral is needed, say so in review notes and offer a video walkthrough or hardware loan. Ensure the account does not expire, is not rate-limited, and is not wiped by a nightly reset job.

07. **Write review notes that pre-empt the concept-demo conclusion**
   In the App Review Notes field, state in three or four sentences: what the app does for a public user, who the public audience is, that the build is a complete production release with live backend services, the exact credentials to use, and a numbered path through the core flow. Explicitly state "This is a complete, production app available to all App Store customers," and name any prior demo language you have removed.

08. **Refresh screenshots and the App Preview**
   Screenshots must show real populated UI, not mockups, device frames with marketing headlines, or slides describing features. Remove any screenshot that is essentially a pitch slide. Apple frequently forms the concept-demo impression from screenshots before ever launching the build.

09. **If the app really is for a limited audience, change the channel — do not argue**
   Choose the correct route: TestFlight for pre-release testing with up to 10,000 external testers; custom app distribution via Apple Business Manager or Apple School Manager for apps built for named client organizations (this is the correct answer for white-label and client-pitch apps); Apple Developer Enterprise Program for proprietary internal-only employee apps; or a web app for prospect demos. You can pursue a genuinely public App Store product in parallel.

10. **Resubmit as a new build, not a metadata-only change**
   Even if your fixes were mostly copy, increment the build number and resubmit the binary so the reviewer sees a fresh submission. In the resubmission message, follow the 5-step structure: acknowledge the review, clarify what the app actually does, list the specific changes made, give reproduction steps with credentials, and request re-review.

11. **If rejected a second time with the same reasoning, escalate deliberately**
   Reply in Resolution Center once with a factual clarification and a link to a short screen recording of the full user journey. If that fails, file an appeal with the App Review Board articulating the public audience, the depth of functionality, the live backend, and evidence of real users on other platforms. Do not resubmit the same build repeatedly without new information.

## Prevention
- Never use demo, beta, preview, prototype, or pilot language in any App Store-bound build or metadata — keep that vocabulary in TestFlight, where it belongs.
- Treat the first launch experience as the entire review: assume the reviewer sees only your splash screen, onboarding, and home screen before deciding.
- Ship with seeded, realistic content so no reviewable screen is ever empty.
- Maintain a permanent, monitored review account with production-grade data, and test it on a fresh device before every submission.
- Decide the distribution channel before you build: client-specific and white-label products belong in Apple Business Manager custom apps, not on the public store.
- Keep review notes as a living document that states plainly who the public audience is and how to reach core functionality in under 60 seconds.

## Appeal guidance

Appealing or replying in Resolution Center is a viable FIRST step only when your app is genuinely complete and publicly usable and the reviewer's impression came from something they could not get past — most commonly a login wall with credentials that failed, an invite-code or workspace requirement, hardware dependency, or a region-locked backend. In that scenario, do not change the product; reply in Resolution Center with (1) a one-sentence statement that the app is a complete production release intended for all App Store customers, (2) working credentials verified minutes before you send, (3) a numbered 5-8 step path through the core functionality, and (4) a 60-90 second screen recording of the full journey on a clean device. Also state what your public user base is and, if applicable, that the same product is live and in active use on Android or web. If any part of your app is genuinely a pitch, showcase, or client demo — or if placeholder content, 'Request a Demo' CTAs, or beta branding are present anywhere — do not appeal first. Fix those signals and resubmit, because an appeal on those facts will fail and will cost you five to ten days. Reserve the formal App Review Board appeal for after one clarification attempt and one fixed resubmission have both been rejected on identical grounds.

## Before / after examples

**Before:** App name is "Acme Platform (Beta)" with a subtitle reading "A preview of our upcoming workforce tool" and version 0.9.4.
**After:** App name is "Acme Platform," subtitle is "Schedule shifts and track team hours," and the version is 1.0.0.
**Why it works:** Removing pre-release vocabulary and sub-1.0 versioning eliminates the clearest signal that the build is not intended for public distribution.

**Before:** Home screen shows three empty cards labeled "Sample Project A/B/C" with lorem ipsum body text and a large "Request a Demo" button as the primary CTA.
**After:** Home screen shows the user's real projects (seeded with representative content for new accounts), and the primary CTA is "Create Project." A "Contact Support" link lives in Settings.
**Why it works:** Replacing placeholder data and a sales CTA with a working product action proves the app delivers value to a downloader rather than generating leads.

**Before:** App opens to a login screen requiring an organization invite code; App Review Notes were left blank, so the reviewer never got past the first screen.
**After:** App Review Notes contain a pre-provisioned account with username, password, and invite code, plus eight numbered steps to reach the core workflow and a link to a 90-second screen recording.
**Why it works:** Guaranteed full access removes the reviewer's only basis for assuming the app is a shell with nothing behind it.

**Before:** Screenshots are marketing slides with headlines like "Imagine your business, reimagined" over device mockups, and the description ends with "Book a call to see the full platform."
**After:** Screenshots are real captures of populated in-app screens with short functional captions, and the description explains what a user can do in the app today with no sales invitation.
**Why it works:** Store assets that show a working product rather than a pitch prevent the reviewer from forming the concept-demo conclusion before launching the build.

**Before:** The app is a white-label showcase built to pitch a specific retail chain, with that chain's branding and a catalog of fictional stores.
**After:** The showcase build is distributed to the client organization as a custom app through Apple Business Manager, while a separate, genuinely public product is submitted to the App Store.
**Why it works:** Matching the audience to the correct distribution channel resolves the rejection permanently instead of repeatedly re-submitting an app the public store was never meant to host.

## Common questions

**Can you appeal a 2.2 rejection?**

Appealing or replying in Resolution Center is a viable FIRST step only when your app is genuinely complete and publicly usable and the reviewer's impression came from something they could not get past — most commonly a login wall with credentials that failed, an invite-code or workspace requirement, hardware dependency, or a region-locked backend. In that scenario, do not change the product; reply in Resolution Center with (1) a one-sentence statement that the app is a complete production release intended for all App Store customers, (2) working credentials verified minutes before you send, (3) a numbered 5-8 step path through the core functionality, and (4) a 60-90 second screen recording of the full journey on a clean device. Also state what your public user base is and, if applicable, that the same product is live and in active use on Android or web. If any part of your app is genuinely a pitch, showcase, or client demo — or if placeholder content, 'Request a Demo' CTAs, or beta branding are present anywhere — do not appeal first. Fix those signals and resubmit, because an appeal on those facts will fail and will cost you five to ten days. Reserve the formal App Review Board appeal for after one clarification attempt and one fixed resubmission have both been rejected on identical grounds.

**How long does this typically take to fix?**

Typical turnaround is 1-5 days (difficulty: hard). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-22-performance-beta-testing-concept-demonstration-app*