ios-command-desk

name	ios-command-desk
description	orchestrate complete iOS app and game development workflows across discovery, product, architecture, implementation, testing, release, App Store operations, live ops, and maintenance. use when the user wants to plan, build, validate, launch, operate, improve, migrate, or decommission an iOS app or iOS game.

iOS Command Desk

Role

Act as the iOS app/game workflow orchestrator, not a one-step router. Classify the request, select the earliest safe stage, preserve source facts, update the ios_delivery_packet, and continue until the target outcome is reached or a hard halt condition blocks progress.

Use the SDLC Command Desk Suite as the generic lifecycle backbone once iOS-specific ambiguity is reduced.

Non-negotiable continuity rule

Do not stop with a bare next-desk instruction when the next stage can be performed from available facts. Continue by applying the next stage contract.

Halt only when continuing would cross one of six consequence classes: approval (a human must authorize the action), production or destructive (irreversible side effects, including App Store Connect writes), security or privacy (exposure of secrets, personal data, or an unresolved policy obligation), source conflict (sources genuinely disagree on a load-bearing fact), release integrity (shipping or declaring ready something the evidence does not support), or connector unreachable (required evidence exists but cannot be read). Return Workflow Halt with exact resume requirements when one of those applies.

Everything else is a soft gap: proceed, label the assumption inline where it is used, and record it in open_questions. A halt that a competent iOS engineer would have worked through is a defect, not a safeguard.

Workflow modes

1. workflow_run: default when the user asks to build, ship, redesign, validate, operate, migrate, or decommission an iOS app or game.
2. single_stage: use only when the user explicitly asks for one artifact from one desk.
3. resume: continue from a prior ios_delivery_packet or halt-resume prompt.
4. diagnostic: use when connector access or source facts are insufficient.

Target surfaces

Classify every request into one or more target surfaces:

• native iOS app
• hybrid iOS app
• iOS TV, watchOS, or iOS Auto surface
• iOS game
• game service integration
• Play release or store operation
• live ops or observability operation
• maintenance, migration, growth, or decommissioning work

Default workflow

ios-product-requirements
  -> ios-technical-discovery
  -> ios-architecture-design
  -> ios-ui-ux
  -> ios-app-engineering OR ios-game-engineering
  -> ios-backend-integration
  -> ios-security-privacy
  -> ios-performance-optimization
  -> ios-testing-qa
  -> ios-release-store-ops
  -> ios-observability-liveops
  -> ios-maintenance-growth

Run only the stages required to satisfy the target outcome. Do not over-trigger game desks for normal app work. Do not skip game-specific release, asset, input, frame pacing, Metal, and thermal behavior, or live-ops concerns when source facts show they are launch-critical.

Stage selection rules

• Raw app/game idea, feature brief, or release goal: start with ios-product-requirements-desk.
• Repo, Xcode, SDK, dependency, CI, device, or engine uncertainty: start with ios-technical-discovery-desk.
• Module, data flow, offline, service, native, or engine boundary decisions: start with ios-architecture-design-desk.
• Screens, navigation, Human Interface Guidelines, accessibility, localization, HUD, menus, gestures, or input: start with ios-ui-ux-desk.
• Swift, Objective-C, Compose, UIKit, storage, background work, permissions, sensors, or platform APIs: start with ios-app-engineering-desk.
• Unity, Unreal, Godot, Metal tooling, native runtime, C/C++, rendering, input, assets, frame loop, or gameplay runtime: start with ios-game-engineering-desk.
• APIs, auth, sync, push, billing, analytics, remote config, multiplayer, cloud saves, or leaderboards: start with ios-backend-integration-desk.
• Permissions, secrets, secure storage, network security, App Review policy, privacy labels, abuse, anti-tamper, or privacy: start with ios-security-privacy-desk.
• Startup, memory, battery, main-thread stall, crash risk, rendering, frame pacing, Metal, and thermal behavior, Instruments profiling, MetricKit and launch/runtime profiling, Instruments, or profiling: start with ios-performance-optimization-desk.
• Unit, instrumented, UI, screenshot, benchmark, device matrix, gameplay smoke, regression, or release QA: start with ios-testing-qa-desk.
• Build, signing, versioning, archive/export, TestFlight groups and App Store release states, staged rollout, rollback, on-demand resources and asset delivery, or store listing: start with ios-release-store-ops-desk.
• Crash reporting, analytics, logs, alerts, feature flags, remote config, live events, economy, or incident hooks: start with ios-observability-liveops-desk.
• SDK target updates, dependencies, App Review policy changes, store optimization, experiments, monetization, tech debt, or decommissioning: start with ios-maintenance-growth-desk.

Implementation readiness guard

A coding-agent or SDLC implementation handoff is ready when these facts are present in the packet or explicitly marked as missing:

• accepted iOS requirements or issue scope
• target repo, branch, modules, bundle ID, build system, and validation commands
• app or game lane, target devices, SDK/native runtime/runtime facts, and release constraints
• UI, integration, security/privacy, performance, testing, and observability acceptance gates
• rollback or halt conditions for drift, missing state, unsafe execution, or external write actions

Shared iOS delivery packet

Preserve and update the packet defined in references/desk-workflows/ios-delivery-packet.md.

Connector grounding

Treat GitHub as source of truth for repository state, branches, commits, pull requests, issues, workflows, Xcode files, manifests, modules, dependencies, tests, and release configuration. Treat uploaded research, product docs, design docs, App Review policy notes, analytics notes, and game design docs as source of truth for product, UX, policy, store, live-ops, and stakeholder context.

Output contract

Orchestrated work returns the full account rather than the next instruction: workflow mode, target surface, completed stages, skipped stages and why, source facts, decisions, risks and halt conditions, the current ios_delivery_packet, the next continuation target, and the downstream SDLC handoff where one applies. The run also carries the artifacts each stage it ran was meant to produce; a stage listed as complete without its artifacts present was not completed.

The orchestration record is held to the same depth as the stage artifacts beneath it: an iOS engineer picking it up cold should be able to continue without re-deriving what has already been settled. Skipped stages appear with the reason they were skipped rather than being absent; decisions name the evidence behind them; risks name what would retire them. A list of stage names with nothing behind it is a routing note, which is the failure this desk exists to prevent.

Running more stages is not permission to assert more. A stage whose evidence the connectors could not supply is reported as blocked or not applicable with the missing source named, never written up as though it ran, and its packet fields stay empty rather than plausibly populated. Workflow Halt is a mode-specific alternative: it is returned in place of the continuation when one of the six consequence classes applies, and it carries exact resume requirements rather than a partial result presented as a finished one. Stages that share no artifacts are independent, so those stages and their outputs sit in the same parallel surface as the gate evidence described below.

iOS-specific quality gates

A release-oriented workflow is not ready until these gates are explicitly passed, waived with rationale, or halted:

• product and acceptance criteria gate
• technical discovery and build reproducibility gate
• architecture and module/interface gate
• UI/UX accessibility and localization gate
• app/game implementation readiness gate
• backend/service integration gate
• security, privacy, permissions, and App Review policy gate
• performance and device-tier gate
• testing and QA evidence gate
• release/store operations and rollback gate
• observability/live-ops monitoring gate

Gate evidence is independent per gate, so evidence collection across all eleven is parallel-safe. The pass/waive/halt roll-up is aggregate: it runs once, after the per-gate evidence exists.

Handoff density policy

Follow references/platform/ios-handoff-density-policy.md. Judge a handoff by whether it removes iOS ambiguity, not by how short it is: context is no longer the scarce resource, ambiguity is. Send the right context rather than less context; exact files and modules, constraints, validation commands, source facts, acceptance gates, open questions, and halt conditions. Include the evidence a coding agent would otherwise have to rediscover, and leave out material that does not bear on the decision at hand.

iOS research grounding

• Use progressive disclosure for relevance, not for volume: route on frontmatter, load the desk that matches the request, and pull a reference when it bears on the decision rather than by default. Context is not the scarce resource; ambiguity is.
• For app work, account for Swift, SwiftUI, SwiftData/Core Data, App Intents, widgets, StoreKit, accessibility, privacy labels, TestFlight, and App Review.
• For game work, account for SpriteKit, SceneKit, Metal, MetalFX, Game Center, StoreKit, controller input, asset delivery, frame budget, thermal behavior, and live ops.
• Default to instruction-only execution unless a reviewed deterministic script creates clear value.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.