No "beta," "test," "preview," or pre-release language visible in the production build

Apple guideline 2.1 requires that submitted apps be complete and production-ready — 'Beta Features' tab labels, '0.9.x' version numbers, and visible debug overlays signal to reviewers that the app is not ready for the store. This is one of the most mechanical rejection causes: automated pre-review scanning flags 0.x version numbers and common pre-release strings before a human reviewer sees the app. The allowFontScaling={false} anti-pattern from AI code generation frequently co-occurs with beta labels for the same reason: the AI scaffolds placeholder-quality code that ships to review without cleanup.

Update the app version to 1.0.0 or higher in app.json before first submission:

// app.json
{
  "expo": {
    "version": "1.0.0",
    "ios": { "buildNumber": "1" },
    "android": { "versionCode": 1 }
  }
}

Search for pre-release labels: grep -r '"Beta"\|"Alpha"\|"Preview"\|"Staging"' src/ --include="*.tsx". Gate all debug components behind __DEV__:

// Correct — invisible in release builds
{__DEV__ && <DebugPanel />}

Flutter: set debugShowCheckedModeBanner: false in MaterialApp. Remove any tab, navigation label, or screen title that contains 'Beta', '(Beta)', or 'Preview' — these strings are visible to reviewers and trigger rejection.

• ID: no-beta-language

• Severity: low

• What to look for: Count all relevant instances and enumerate each. Search all UI source files, string constants, screen components, navigation labels, and tab bar labels for pre-release language that would be visible in a production build: "Beta", "(Beta)", "[Beta]", "Preview", "Alpha", "Test" (as a standalone label), "Staging", "Dev Build", "Canary", "RC" (release candidate). Also check: (1) Version numbers — Does the user-visible version number show 0.x.x? Both stores reject apps displaying 0.x as the user-facing version. (2) Debug overlays — Search for React Native dev menu components, Flutter debugShowCheckedModeBanner: true, or Xcode build configuration banners that survive into release builds. (3) Environment indicators — Look for environment name displayed in the UI: "[DEV]", "[STAGING]", "Environment: production" text shown in the app header or status bar. (4) TestFlight-specific UI — Look for UI elements that check IS_TESTFLIGHT or TESTFLIGHT_ENVIRONMENT and render extra content — ensure these are properly gated. This check is distinct from the App Store Review Blockers audit's beta-indicators check in scope: that audit focuses on obvious unfinished UI; this check focuses on policy-violating pre-release labels that suggest the app is not production-ready.

• Pass criteria: No pre-release labels, beta indicators, or staging environment markers visible in production-bound source. At least 1 implementation must be verified. App version is 1.0.0 or higher for first submission. Debug overlays are gated behind __DEV__ / kDebugMode / #if DEBUG.

• Fail criteria: Any visible beta, alpha, preview, test, or staging label in production UI; version number showing 0.x.x to users; debug overlay rendered without a debug-mode gate.

• Skip (N/A) when: Never.

• Detail on fail: "Tab bar label 'Beta Features' visible in src/navigation/TabNavigator.tsx — this string will be visible to App Store reviewers" or "User-facing version displayed in About screen shows '0.9.2' — must be 1.0.0 or higher for store submission"

• Remediation: Reviewers reject apps that appear to be pre-release submissions.

  1. Remove all beta/alpha/preview labels from production UI. Gate any experimental feature sections with __DEV__ checks that are false in release builds
  2. Update the app version to 1.0.0 or higher in app.json (expo.version) before submission
  3. Wrap all debug components: {__DEV__ && <DebugPanel />} (React Native) or if kDebugMode { DebugView() } (Swift)
  4. Use environment-specific build configurations rather than runtime environment labels visible to users

  Review the configuration in src/ or app/ directory for implementation patterns.