Verify the release toolchain end-to-end: ASC API credentials, mac-app directory, fastlane, xcodebuild, and (if creds are present) that the app record exists in App Store Connect. Run this first in any release session.

Snapshot of the app's release state: latest App Store versions with their review states, and recent builds with processing states. Use this to answer 'where is the release right now?'

List recent uploaded builds and their processing states (PROCESSING → VALID before they can be submitted). Use after an upload to watch for the build becoming VALID.

Bump the local app version before a build. Increments the build number (CURRENT_PROJECT_VERSION) and optionally sets a new marketing version. Updates every .xcodeproj/project.pbxproj in the project dir, plus project.yml if the project uses xcodegen, so all sources stay in sync.

Archive, sign, and upload the app to TestFlight via the configured fastlane lane (default: fastlane beta; see ASC_FASTLANE_* / ASC_UPLOAD_CMD env vars). Runs asynchronously (5–15 min) — returns a job ID immediately; poll with asc_job_status. Note: if the lane calls increment_build_number you do NOT need asc_bump_version first unless changing the marketing version.

Check a build/upload job started by asc_upload_build. Returns status (running/succeeded/failed) and the tail of the log.

Update App Store listing metadata (description, keywords, what's-new, promotional text) on the currently editable version via the ASC API. If no editable version exists, pass create_version to open a new one.

Submit the editable App Store version for review: optionally attach a build, then create and submit a review submission. The build must have processingState VALID (check asc_list_builds). This is the point of no return for a release — confirm with the human first.