App description accurately represents functionality

Apple Guideline 2.3.3 and Google Play's Misleading Apps policy both treat an inaccurate description as grounds for rejection — no appeal, no second chance on that submission cycle. Beyond rejection, a description that promises features the codebase doesn't deliver generates one-star reviews from users who installed expecting 'AI-powered recommendations' and found none. App stores use conversion rate and review velocity as ranking signals; a misleading description poisons both. The damage compounds: each failed submission adds days to your launch, and each negative review permanently anchors your rating.

Remove or rephrase every unsubstantiated feature claim before resubmission. Work from the store description file directly:

# Verify the store description exists and review it
cat fastlane/metadata/ios/en-US/description.txt

For each claim in the description, confirm a matching implementation exists in src/. If the codebase has no socket or messaging library, remove 'real-time messaging.' Replace superlatives ('the #1 app') with verifiable specifics ('syncs in under 3 seconds'). Store the canonical description in fastlane/metadata/ and version-control it alongside the codebase so feature claims stay synchronized with shipped code.

• ID: description-accurate
• Severity: critical
• What to look for: Read all description text available in the repository: fastlane/metadata/ios/<locale>/description.txt, fastlane/metadata/android/<locale>/full_description.txt, or any store-metadata/ equivalents. Cross-reference the description against the actual app's screens, features, and navigation structure. Flag descriptions that: (a) claim features not present in the codebase (e.g., "AI-powered recommendations" with no AI integration, "real-time messaging" with no socket or messaging implementation), (b) use marketing superlatives without substantiation ("the #1 app", "best-in-class", "most powerful"), (c) describe a planned or future version rather than the version being submitted, (d) copy-paste boilerplate from a template without customization (generic phrases like "This app will revolutionize the way you...", "Experience the future of..."), or (e) are entirely absent — the description field is empty or contains a placeholder like "App description goes here." In Expo, also check app.json's description field, though this field is primarily for internal use and may not be the store description. Count every feature claim in the store description and enumerate each. For each claim, classify as substantiated (feature exists in codebase) or unsubstantiated (no matching implementation found). Before evaluating, extract and quote the first paragraph of the store description and identify the primary feature claims made.
• Pass criteria: The description accurately reflects the app's actual functionality as seen in the codebase. Features mentioned in the description have corresponding screens, components, or integrations present in the source. Report even on pass: "X feature claims found in description. X of X substantiated by codebase analysis." At least 1 implementation must be confirmed.
• Fail criteria: Description claims features not present in the codebase; uses "coming soon" or future tense for features; is entirely placeholder; contains obvious template text that was never customized; is absent when metadata files are present. Do NOT pass if the description claims features that do not exist in the codebase — app stores reject apps for misleading descriptions.
• Skip (N/A) when: No store description text is present anywhere in the repository — not in fastlane, not in store-metadata/, not in app.json. (Skip rather than fail: absence of metadata files doesn't mean the description is wrong, just that it isn't checked into the repo.)
• Cross-reference: The keywords-no-stuffing check verifies the description validated here does not overuse keywords at the expense of readability.
• Detail on fail: Cite the specific discrepancy. Example: "fastlane/metadata/ios/en-US/description.txt claims 'real-time push notifications' but no push notification library is present in package.json" or "Description is a template placeholder: 'Describe your amazing app here.'".
• Remediation: An inaccurate description is a rejection trigger under both Apple Guideline 2.3.3 and Google Play's Misleading Apps policy. It also permanently damages user trust through negative reviews.
  1. Read your description aloud and ask: "Does this match what the app actually does right now?"
  2. Remove or rephrase any feature claim that is not fully implemented in the current build
  3. Replace superlatives ("the best", "#1") with specific, verifiable claims ("Syncs in under 3 seconds", "Supports offline mode")
  4. Write the description for a first-time user who has never heard of your app — explain what it does, not what it aspires to be
  5. For App Store: the description is not indexed for search — use the Keywords field for discoverability. The description should be for conversion, not keywords. Maintain store descriptions in fastlane/metadata/ or src/store-metadata/. Cross-reference claims against the codebase in src/ before each submission.