Version information is documented or accessible

Version history documentation serves two concrete functions: it lets users understand what changed in an update before installing (reducing negative reviews from unexpected behavior changes), and it gives future maintainers a reliable source of truth for which version introduced which behavior. App stores surface "What's New" text in update prompts — an empty or generic "Bug fixes and improvements" entry significantly reduces update adoption rates, which matters for security patches that need broad uptake. ISO 25010:2011 maintainability quality attributes include changeability and testability, both of which depend on accurate version documentation. Without a CHANGELOG, diagnosing regressions across version boundaries requires git archaeology instead of a changelog lookup.

Create CHANGELOG.md at the project root using Keep a Changelog format and tag releases in git to link the changelog to deployable artifacts.

# Changelog

## [1.1.0] - 2026-03-15
### Added
- Push notifications for order status updates
- Dark mode support

### Fixed
- Login timeout on slow connections

## [1.0.0] - 2026-02-01
- Initial release

# Tag each release in git
git tag -a v1.1.0 -m "Order notifications + dark mode"
git push origin v1.1.0

Paste a condensed version of the current section into the App Store Connect "What's New" field and Google Play Console release notes field at submission time. Keep notes user-facing ("Fixed login timeout") not implementation-focused ("Refactored auth token refresh logic").