Shape: Mobile App

A mobile app ships to the App Store (iOS), the Play Store (Android), or both. The release surface is store-side review followed by phased rollout -- not a deploy you trigger from CI. GAIA models this with kind: distribution-only + channel: mobile-app + three required sub-fields: platform, store_id, review_required.

STUB caveat

The publish-mobile-app adapter ships as a STUB in this iteration. The adapter validates the configuration and emits the App Store Connect / Play Console submission payload, but the actual API integration (TestFlight upload, Google Play Internal Track, screenshot metadata propagation) is deferred to a follow-up iteration.

What works today: schema validation, /gaia-publish dispatch, the channel appears in /gaia-help Phase 5 routing as a publish-primary suggestion. What requires manual follow-up: actually pushing the binary to the store after the release_workflow CI run completes.

project-config.yaml

environments:
  - id: appstore
    kind: distribution-only

distribution:
  channel: mobile-app
  registry: https://itunesconnect.apple.com   # or play.google.com/console
  manifest: ios/MyApp.xcodeproj/project.pbxproj
  release_workflow: gaia-release.yml
  platform: ios            # ios | android | both
  store_id: com.example.myapp
  review_required: true

All three sub-fields (platform, store_id, review_required) are required by the mobile-app if/then allOf branch in project-config.schema.json. Missing any one is rejected by /gaia-config-validate. For a dual-platform release, set platform: both; provide a store_id that resolves on both stores (bundle identifier).

Phase 5 routing

With kind: distribution-only + a distribution: block, the Phase 5 router emits publish-primary and suggests /gaia-publish. Mobile-app deploys don't have a staging URL, so /gaia-deploy and /gaia-post-deploy both refuse with the canonical use /gaia-publish instead guidance.

Publish to the app stores

/gaia-publish

The orchestrator dispatches publish-mobile-app (the STUB adapter), which validates the per-channel sub-fields and emits the submission payload. The release_workflow handles the actual store-side push -- typically a CI workflow that runs fastlane against App Store Connect + Play Console. review_required: true blocks the release on store review approval; set false only if you're targeting internal-track / TestFlight beta groups.

You'll know it worked when

  • /gaia-config-validate exits 0 with all three mobile-app sub-fields present.
  • /gaia-help suggests /gaia-publish on the Phase 5 row.
  • A /gaia-publish run validates the schema and writes the submission payload (STUB phase -- store-side integration deferred).
  • Your CI workflow at release_workflow picks up the payload and posts to the App Store / Play Console via fastlane (or your store-side tool of choice).