AppReviewFix
Guideline library
Apple App Store — App Quality

2.2 — Beta testing

Official source: App Store Review GuidelinesTopic overview: The review process, app quality and enforcement
What this guideline means

A submission has to be the finished, production-ready version of your app; builds with debug menus, "coming soon" placeholders, or obvious beta labeling belong in TestFlight, not the App Store review queue.

Why apps actually get flagged

Common when a team submits a build meant for internal TestFlight testing to the wrong review track by mistake, debug UI and all.

A real example

"Your app appears to be a beta, demo, or trial version and is not appropriate for the App Store, per guideline 2.2. Please use TestFlight for beta distribution."

The short version, in more detail

Guideline 2.2 says that the version submitted for review should be the finished product. Beta, demo and trial builds belong in TestFlight, not in the App Store review queue. Reviewers find submissions that still look like internal builds, with debug menus, placeholder labels or unfinished features visible to the user.

What this guideline covers

  • The difference between a production release and a beta build.
  • Debug menus, test labels and placeholder content visible in the submission.
  • TestFlight as the venue for pre-release testing.
  • Demo or trial versions presented as regular releases.

What usually triggers this rejection

  • A build submitted by mistake that was meant for internal testing.
  • Visible debug options or test buttons in the interface.
  • Labels such as beta, alpha or demo in the app or listing.
  • Placeholder screens or sample data left in the product.
  • Features that are clearly unfinished and shown to users.

How reviewers evaluate it

  • Reviewers notice debug UI and beta labelling during normal use.
  • They compare the build with the way the listing presents it.
  • They look at whether the app appears ready for the public.
  • They may not distinguish an accident from an intentional beta.

Common misunderstandings

  • A beta label does not make an unfinished app acceptable for release.
  • TestFlight is intended for testing, and release builds are expected to be complete.
  • Hiding debug options behind a gesture does not guarantee they go unnoticed.

Common questions

Can I release an early version and improve later?

Apps can be updated, but the submitted version should be complete and working.

What is TestFlight for?

Distributing pre-release builds to testers, with its own limited review.

Does 2.2 apply to updates?

Yes. Each submission is expected to be a finished, production-ready version.

Platform rules change often. This page is a plain-language explanation written by AppReviewFix, not official guidance. Check the current App Store Review Guidelines for the exact wording.

Got this exact rejection?Paste it in and get a diagnosis specific to your app, free.
Decode my rejection
Related guidelines
Functionality — Functionality, content and user experienceTarget API Level — Target API level requirements2.1 — App Completeness2.3.1 — Hidden or undocumented features4.2 — Minimum functionality
AppReviewFix
ProductDecoderPricingGuideline library
CompanyAboutFAQContact
ResourcesGuidesTopic overviewsCommon rejection reasons
LegalTermsPrivacy
© 2026 AppReviewFixBuilt by a developer, not a committee.