/omh-mobile-release

name: "omh-mobile-release"
description: "[omh] Releasing an iOS or Android app through the stores -- signing, the privacy manifest, a TestFlight or Play beta, a staged rollout, a hotfix: prepare each gate the store enforces, and plan the halt and the next build before the rollout starts, because a store release cannot be rolled back. Use when the user says: mobile-release, mobile release, mobile app release, ios release, android release, app store release, app store submission, submit to the app store."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, planning]
    category: planning
    phase: mobile-release
    role: planner
    quality_tier: store-gate-halt-planned

Mobile Release

This is a Hermes-native `mobile-release` workflow skill.

Why This Exists

`mobile-release` exists because store releases had no owner: `release-cut` decides a service release that can roll back, `deploy-and-monitor` watches a deploy, and `production-audit` audits readiness platform-neutrally, while signing, a privacy manifest, a TestFlight beta or a Play staged rollout had nothing that knew the store's gates.

First Steps

• Ask which platforms, which version and build number, and how signing is held today.
• Ask what halts the rollout, before planning any rollout step.

Do Not Use When

• The ask is a versioned release of a service or library -- what goes in, the tag, a canary, the rollback command; use `release-cut`.
• A web or backend deploy is already out and the ask is watching its health; use `deploy-and-monitor`.
• The ask is a readiness audit across observability, security, and operations before launch; use `production-audit`.
• The app crashes or misbehaves and the ask is finding the cause in the code; use `app-debugging`.

Examples

Good example:

• Prompt: we are shipping 3.2 to the app store and google play next week
• Expected behavior: Check the signing assets' expiry, compare the privacy manifest and data safety form against the shipped SDKs, run the TestFlight and Play closed-track beta, then roll out in phases with crash-free and ANR halt thresholds and the 3.2.1 build number reserved for a hotfix.
• Why: A store build cannot be pulled back, so the halt and the replacement have to exist before the first user gets it.

Bad example:

• Prompt: just release to 100% and roll back if it crashes
• Expected behavior: Refuse the full release: a store build cannot be rolled back; stage it behind halt thresholds and reserve the hotfix build first.
• Why: Users keep the crashing build until a new one is reviewed and installed.

Completion Checklist

• Every signing asset is named with its expiry and holder, and no secret is in the plan.
• The privacy declarations match the shipped SDKs, or each mismatch is named.
• The beta channel, its testers, and its exit checks are stated.
• Every rollout step names the threshold that halts it.
• The hotfix build number and the halt are planned, and OMH submitted nothing.

Recovery Notes

• If a signing certificate or upload key is lost or expired, recovering it is the first step; say so before any submission plan.
• If the crash figures are not observable yet, hold the rollout at its current step and mark the threshold unverified.

Workflow Lane

• Current lane: **Coding handoff** (`idea-to-deploy`, `llm-app-dev`, `cto-loop`, `deploy-and-monitor`, `code-review`, `build-failure-triage`, `verification-gate`, `security-safety-review`, `+28 more`) - coding owners, handoffs, review, CI, and merge evidence.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when an iOS or Android app is being released through the App Store or Google Play: code signing and provisioning, the iOS privacy manifest or the Play data safety form, a TestFlight or Play testing-track beta, a phased or staged rollout, or a hotfix for a build already in users' hands. The output is the signing plan, the privacy declaration check, the beta plan, the staged rollout with its halt thresholds, and the hotfix plan; OMH builds, signs, uploads and submits nothing.

Strong routing signals: `mobile-release`, `mobile release`, `mobile app release`, `ios release`, `android release`, `app store release`, `app store submission`, `submit to the app store`, `app store review`, `app store connect`, `testflight`, `play store`, `play store release`, `google play`, `play console`, `internal testing track`, `closed testing track`, `phased release`, `code signing`, `provisioning profile`, `signing certificate`, `distribution certificate`, `android keystore`, `upload keystore`, `upload key`, `play app signing`, `privacy manifest`, `privacyinfo.xcprivacy`, `required reason api`, `data safety form`, `expedited review`, `fastlane`

Catalog Metadata

Category: `planning` Phase: `mobile-release` Hermes role: `planner` Quality tier: `store-gate-halt-planned` Reasoning demand: `standard`

Quality bar:

• Name the halt and the replacement build before any rollout step.
• Load `references/mobile-release-method.md` for the per-platform signing, privacy, beta, rollout and hotfix table instead of recalling store rules.
• Check the privacy declarations against the SDK list the build actually ships, not the one in the plan.
• Keep iOS and Android steps separate wherever the stores differ.
• Keep prepared, submitted, approved, and released as separate states for every build.

Handoff policy:

Keep the signing plan, privacy declaration check, beta plan, staged rollout, and hotfix plan in Hermes. Build numbers, review outcomes, crash-free rates and rollout percentages are recorded only from store console, crash reporting, executor, or operator observed output; OMH never builds, signs, uploads, or submits a build.

Required inputs:

• the platforms, the app's bundle or package id, and the version and build number going out

-