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.