Keep a changelog on main and the store copy in fastlane

[andiwand]

Adds a changelog, and puts the two kinds of release text where each one belongs.

Why not a release branch

The tempting shape is a long-lived branch holding versioned notes, since main
deliberately knows nothing about versions — project.pbxproj holds 0.0.0 and
the version reaches the build from the tag. But a changelog records what
changed, which is a property of the commits, so separating it costs more than
it saves:

• It puts back the release commit Take the version from the git tag instead of project.pbxproj #127 removed. release.yml says it outright:
  the tag reaches xcodebuild as MARKETING_VERSION, "so a release needs no
  commit". A release branch makes every release a commit again.
• A tag's own tree would not contain its notes. Tags point at main, so
  git show 1.36:CHANGELOG.md would fail and "what shipped in 1.36" would stop
  being answerable from 1.36.
• Entries would be reconstructed afterwards from git log instead of written
  with the change. That is the process that produced the empty 1.17 release
  body.
• GitHub renders CHANGELOG.md from the default branch, so on a side branch
  contributors would not find it.

Keep a Changelog already solves the version-awareness part with Unreleased:
entries land under that heading in the pull request that causes them, and
cutting a release renames the heading and adds the compare link. Main knows
versions historically, never as a build input.

What moved

CHANGELOG.md covers 1.35 through 1.37 and keeps only the developer-facing
record. The App Store "What's New" copy that was appended to it moves to
fastlane/metadata/en-US/changelogs/<version>.txt, one file per marketing
version, mirroring OpenDocument.droid.

The mirror is not exact, and the README in that directory says why. On droid,
supply reads the directory and Play retains every version's notes as
user-visible history. On iOS, deliver reads a single release_notes.txt per
locale and App Store Connect keeps only the notes for the submission in flight.
So here the directory is the history the store does not keep, and the notes are
pasted in by hand at submission — which leaves promoting a build the deliberate
step it already is.

Files are named by marketing version rather than build number because the build
number is a live query of what TestFlight already has: it is not known until a
release run starts, so it cannot name a file committed ahead of it.

Risk

None to the release path. No tracked file changes — Fastfile, release.yml
and project.pbxproj are untouched, skip_metadata stays true, and nothing
new can reach App Store Connect. Everything here is additive.

Left alone deliberately: fastlane/metadata/en-US/release_notes.txt still
reads "Add search functionality for ODF documents", which is years stale. It is
inert while skip_metadata is true, but it is the file deliver would read
first if that ever flips. Syncing or deleting it touches a tracked 10-locale
metadata set, so it seemed worth deciding separately.

🤖 Generated with Claude Code