Release checklist

What to check before every release

Update from previous version (data migration, no unnecessary logouts).
Demo account (will Apple review be able to access most parts of the app if it requires login?)
Release notes (every version should have different release notes)
Visually check screenshots if they are up-to-date

Create a branch release/[version]-[build_number], where [version] is the new build number to be released and [build_number] will be the incremented build number.
Bump the build number and version number. Build numbers are incremental, starting with 1. Version numbers have x.y.z format, where x represents major, y minor and z patch number.

Fastlane must be used for this by calling bundle exec fastlane bump, bundle exec fastlane bump type:minor, bundle exec fastlane bump type:major.
Commit and push changes. Send a pull request from release/[version] to main.
When merged, create a new tag on main with [version] value.
Create a pull request from main to develop.
After merge, create new release on GitHub from main branch with semantic version tag x.y.z-[build_number].
If continuous delivery is configured, release build and App Store submission will be processed automatically. Otherwise call bundle exec fastlane beta to submit the build manually.
When build is processed to App Store Connect, submit it to TestFlight first and let the tester go through it and ideally go through it yourself too.
Only when tester approves the build, proceed with sending the update to the review.