Guideline 2.2: beta, demo and trial versions

A Guideline 2.2 rejection means your submission looks like a beta, a demo or a trial. Usually the app is finished and one word gave the wrong impression: a badge in the corner, "beta" in the app name, a description thanking testers.

Find every instance and remove it. If the app genuinely is unfinished, the answer is TestFlight, not better wording.

How it is usually worded

The header arrives as Guideline 2.2 - Performance - Beta Testing, and the body is normally close to:

"Your app appears to be a beta, demo or trial version."
"Your app or its metadata includes references to a beta or test version of your app."

The rejection often quotes the offending string; if so, that string is the whole task.

What it actually means

The guideline says demos, betas and trial versions of your app do not belong on the App Store, and points you at TestFlight instead.

Two separate objections live inside that. The first is factual: an unfinished app should not be for sale. The second is presentational: an app that describes itself as unfinished will be treated as unfinished, whether or not it is. The second one catches most developers, and it is the cheaper fix.

Every place the word hides

App name and subtitle. "Acme (Beta)", "Acme Preview".
Description, promotional text and What's New. "Thanks to our beta testers", "this early build", "during the trial period".
Keywords. beta, demo, test.
Screenshots and app preview art. A BETA ribbon baked into the artwork, a staging banner, a watermark.
In-app UI. A badge next to the logo, a "Beta" pill on a nav bar, a footer reading v2.0.0-beta.4.
Version strings. The marketing version and build number shown in App Store Connect and in your About screen. A pre-release suffix reads as exactly what it is.
Onboarding and empty states. "Welcome, tester", "This feature is in preview", "Coming in the full version".
Feedback plumbing. A shake-to-report gesture, a "Send feedback to the beta channel" row, a crash-report consent screen written for testers.
Demo modes. A "Try demo" entry that presents a fake dataset.
Sign-in screens. Placeholder credentials, a staging environment picker.
Localisations. The English copy gets cleaned and the German one keeps the word.

What is still allowed

A free tier. An app with limited free functionality that unlocks with a purchase is normal. Call it Free and Premium, not Demo and Full.
A subscription free trial. An introductory offer configured in App Store Connect is a real product feature, and describing it accurately is expected rather than prohibited. See 3.1.2 for the disclosures.
Pre-orders. Apple's own mechanism for shipping ahead of availability. That is not a beta.

An unfinished feature inside a finished app is a judgement call: reviewers differ, so prefer "Experimental" to "Beta" and make sure it works when tapped. There is no early-access channel on the App Store. TestFlight and pre-orders are the two supported answers, and dressing a store release as early access gets you here.

How to fix it, in order

Read the attachment or quoted string first. If the reviewer named the place, fix that before you go hunting.
Grep the codebase. beta, demo, trial, preview, staging, test build, early access, alpha, RC. Include localisation files, JSON copy decks and any Markdown you render in-app.
Clean the version numbers. Marketing version to something plain, 1.4.0, with no pre-release suffix in the build or the About screen.
Sweep App Store Connect, every localisation, including promotional text, which is easy to forget because it can be edited without a new build.
Re-cut any screenshot with a beta ribbon or staging banner, and check the preview video frame by frame.
Remove tester plumbing from release builds. Shake-to-report, feedback rows, environment pickers. Compile them out rather than hiding them, because a hidden one is 2.3.1.
Rename or remove demo mode. If it exists so people can look around without an account, keep the feature and call it a guest or sample workspace, with real functionality rather than screenshots of functionality.
Ask honestly whether the app is finished. If features are stubbed, screens are empty, or half the tabs say "soon", the rejection is correct and TestFlight is the right home for this build.

What to send back

Thank you for the review. This is a complete production release rather than a beta, and we have removed the wording that suggested otherwise. The app name is now "Acme Invoices" with no "(Beta)" suffix; the BETA badge is gone from every screen; the version string is 1.4.0 with no pre-release suffix; and the description no longer thanks beta testers, in any of the five localisations. Screenshot 1 has been re-cut without the beta ribbon, and the shake-to-report gesture is compiled out of release builds. All features listed in the description are complete and functional in build 140.

If the objection was a demo mode:

Thank you for the review. The "Try demo" option has been renamed and rebuilt. It is now "Explore a sample workspace", and it contains fully functional features operating on sample data rather than a limited preview: the user can create, edit, export and delete records exactly as in a signed-in account. No part of the app is time-limited, and the full feature set is available in build 140.

That reply works because it removes the word and shows the underlying feature is complete, which is the reviewer's actual concern.

When it is really a different guideline

Features that are visibly unfinished, crash, or do nothing is 2.1, app completeness.
An app that works but does very little is 4.2, minimum functionality.
Trial and renewal terms missing from the paywall is 3.1.2.

The habit that prevents a repeat: never let your release scheme be the one carrying the beta name. AppSubmit checks metadata and version strings for beta, demo and trial language before it submits, in every localisation, which is the same grep run at the moment it matters.

Source: Apple, App Store Review Guidelines, 2.2 (https://developer.apple.com/app-store/review/guidelines/#beta-testing)

Related: apple-guideline-2-3-1-hidden-features, apple-guideline-3-1-2-subscriptions, apple-guideline-4-0-design