Guideline 2.2
Guideline 2.2 - Performance: Beta Testing - Concept Demonstration App
Our Take
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 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.
Resolution Guide
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Example Rejection Email
Consider Appealing
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
App name is "Acme Platform (Beta)" with a subtitle reading "A preview of our upcoming workforce tool" and version 0.9.4.
App name is "Acme Platform," subtitle is "Schedule shifts and track team hours," and the version is 1.0.0.
What changed: Removing pre-release vocabulary and sub-1.0 versioning eliminates the clearest signal that the build is not intended for public distribution.
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.
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.
What changed: Replacing placeholder data and a sales CTA with a working product action proves the app delivers value to a downloader rather than generating leads.
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.
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.
What changed: Guaranteed full access removes the reviewer's only basis for assuming the app is a shell with nothing behind it.
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."
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.
What changed: Store assets that show a working product rather than a pitch prevent the reviewer from forming the concept-demo conclusion before launching the build.
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.
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.
What changed: 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.
Community Solutions · 0
Sign in to share your solution.
More Guideline 2 (Performance) rejections
- Guideline 2.1 - App Completeness: App Crashes During Review
- Guideline 2.1 - App Completeness: App Requires External Hardware Not Provided for Review
- Guideline 2.1 - App Completeness: Crashes on Launch
- Guideline 2.1 - App Completeness: Demo Account Not Working
- Guideline 2.1 - App Completeness: IAP Products Not Found in Binary
- Guideline 2.1 - App Completeness: Missing App Icon