Release notes written for each version update

Release notes reading "Bug fixes and improvements" signal abandonment to returning users and erode update-opt-in rates, which App Store Connect surfaces in your analytics and uses indirectly in ranking. Worse, release notes that describe features not present in the shipping build violate App Store Review Guideline 2.3.1 (Accurate Metadata) and can trigger rejection on a point release that would otherwise pass review.

Write release notes in user-facing language describing what actually changed: "Fixed crash when uploading images over 10 MB," "Added dark mode," "Sync is 40% faster." Keep it to 2-5 bullets. Store the file at fastlane/metadata/ios/<locale>/release_notes.txt and the matching fastlane/metadata/android/<locale>/changelogs/<versionCode>.txt so each submission ships with accurate, version-specific copy.

• ID: app-store-metadata-listing.listing-content.release-notes-present
• Severity: low
• What to look for: Check fastlane/metadata/ios/<locale>/release_notes.txt (App Store — used for "What's New" field, max 4000 chars). For Google Play, check fastlane/metadata/android/<locale>/changelogs/<versionCode>.txt. Also check for a CHANGELOG.md or RELEASE_NOTES.md in the project root. Evaluate the content quality: (a) generic placeholder release notes ("Bug fixes and improvements", "Performance improvements", "Various updates") — these are not policy violations but are a missed opportunity and reviewers notice, (b) the release notes describe features not present in the current codebase (inaccurate), (c) release notes mention competitor app names, (d) for the initial 1.0.0 release, release notes may be omitted or set to a welcome message — this is acceptable. For fastlane, also check that the release_notes.txt file is present in the correct locale directory (the locale must match the app's primary language listing). Count all instances found and enumerate each.
• Pass criteria: Release notes file exists and contains substantive content (not "Bug fixes") for non-initial releases; content is accurate to the version being submitted. At least 1 implementation must be confirmed.
• Fail criteria: Release notes for a non-initial version contain only "Bug fixes and improvements" or equivalent generic placeholder; release notes claim features not present in the codebase.
• Skip (N/A) when: This is the initial 1.0.0 / first submission (release notes are optional for first release); or no fastlane/metadata directory is present in the repository.
• Detail on fail: "fastlane/metadata/ios/en-US/release_notes.txt contains only 'Bug fixes and improvements' — users and reviewers both notice uninformative release notes".
• Remediation: Meaningful release notes improve user retention and signal active maintenance.
  1. Describe what actually changed in user-facing terms: "Fixed crash when uploading images larger than 10MB", "Added dark mode support", "Improved sync speed by 40%"
  2. Keep it concise — 2-5 bullet points is ideal for most updates
  3. Avoid developer jargon; write for users, not engineers
  4. For fastlane users, the release notes file must be at fastlane/metadata/<platform>/<locale>/release_notes.txt Store release notes in fastlane/metadata/ directories or src/store-metadata/release-notes.txt. Update before each submission.