Apple AppDev Workflow

Deterministic Codex orchestration for iOS and macOS—from SwiftUI scaffold through review, debugging, and release readiness.

Comment

Inspiration

I already really enjoyed the general Codex experience. My frustration was with the Apple-specific development flow: constant drift, weak ambiguity resolution, and lost context across large codebases or several repos and worktrees. Even when individual answers were useful, the overall effort could feel disjointed and unfocused.

I had worked with orchestration frameworks such as crewAI the previous year, but the models were not yet capable enough to fulfill the promise. I also knew another orchestration model firsthand. I have worked in commercial kitchens, trained formally in culinary arts, and owned and operated a successful establishment. Escoffier's brigade de cuisine gave me the insight: clear ownership, specialized stations, disciplined handoffs, and escalation might be an effective way to coordinate a multi-skill workflow in Codex.

Apple AppDev Workflow is my attempt to adapt that system into a deterministic orchestration harness for end-to-end Apple-platform development. It is not the full expression of the idea, but it is a promising first result—built around one simple promise: one Apple prompt, the right workflow.

What it does

Apple AppDev Workflow is a public Git-marketplace Codex plugin that turns Codex into a coordinated Apple-development team. Its 44 skills cover SwiftUI app bootstrap and project adoption, architecture, implementation, interface design, persistence, accessibility, testing, review, debugging, security hardening, App Store preparation, and release readiness.

Its primary interface is broad, natural language—not manual skill selection. The user can simply ask, “Review this iOS app and tell me if it is ready for release.” They do not need to know the skill names, choose a release workflow, or manage the handoffs themselves.

The defining feature is deterministic, pre-sampling ownership. Before the model responds, a trusted UserPromptSubmit hook infers the Apple-development intent and assigns the top-level workflow owner. That owner discovers the real repository, project, branch, and available tools; resolves the request as release-readiness work; and coordinates the release owner and its review, testing, manual-validation, and release-operations stations. Explicit skill invocation remains a reliable fallback, not the normal user experience.

The result is an auditable workflow: route evidence shows what owns the turn; focused brigades coordinate the work; and final reports distinguish automated evidence, conditional execution, guidance, and required human validation.

How it works

  1. The developer states the outcome naturally—for example, “Review this iOS app and tell me if it is ready for release.” No skill name is required.
  2. A small Node.js router runs before model output. It evaluates broad Apple prompt signals and nearby Apple project markers.
  3. The router injects an auditable top-level owner contract. Unrelated prompts and foreign plugins are left alone, and explicit focused skills still take precedence when a user intentionally chooses one.
  4. Discovery grounds the turn in the actual checkout before planning or edits.
  5. The top-level owner resolves the domain intent and activates the appropriate implementation, review, debugging, product-surface, persistence, accessibility, or release orchestrator.
  6. Host-appropriate providers perform builds, tests, Apple documentation lookup, simulator or Xcode work, and continuity support when available.
  7. The final response reports evidence, gaps, manual checks, and the next safe action instead of presenting guidance as proof.

What I changed during Build Week

Apple AppDev Workflow existed before the submission period. During Build Week, I converted it from a workflow bundle with a custom-runtime routing dependency into a portable, hook-native stock-Codex product and published version 0.2.0.

The release-defining work completed after the July 13 submission-period start:

  • implemented a trusted, fail-closed UserPromptSubmit router for natural prompts and plugin or skill invocations;
  • added the routing policy, top-level owner kernel, trust boundaries, explicit fallback, negative cases, resume behavior, and post-compaction behavior;
  • proved the routing payload across a 12-case signed stock Codex Desktop matrix;
  • proved the same carry-free routing payload across a separate 9-case live Xcode CodingAssistant compatibility matrix;
  • removed the fork-only router-selection carry from the product path;
  • added release gates that separate public Marketplace behavior, Xcode host compatibility, and private harness evidence;
  • rendered and published the clean Apache-2.0 public Git Marketplace release;
  • verified public Git marketplace registration, app-server read and install, runtime provisioning, and plugin-owned MCP attribution.

The dated source record contains 25 post-cutoff commits (21 non-merge commits). Compared with the pre-window baseline bfcfb8d, the published qualification train changed 79 files with 10,499 insertions and 1,004 deletions. Key commits include 9f6f39e (hook-native router), a9ee341 (stock Desktop matrix), 1745a10 (live Xcode compatibility), c86b477 (carry removal), 952f2a5 (public-release qualification), and public release commit c3702d9.

How I used Codex and GPT-5.6

Most of the experimental product development happened in Codex with GPT-5.5. Later in Build Week, I used the experimental plugin itself with GPT-5.6 for the expensive release task: remove the custom-runtime dependency, coordinate the private source and clean public release, qualify the product in a stock Codex environment, and publish v0.2.0. It was not a release train I would have attempted with GPT-5.5. GPT-5.6 handled the long context, ambiguity, and cross-repository coordination with relative ease.

I used one long-running GPT-5.6 Codex thread to preserve the causal chain from product decision to implementation and release evidence. Codex accelerated repository archaeology, cross-worktree coordination, router implementation, hostile-input tests, stock-host validation harnesses, carry-removal analysis, release-gate code, documentation, and public packaging.

My key product decisions stayed explicit throughout: deterministic top-level ownership and pre-sampling injection were non-negotiable; hooks had to fail closed when untrusted or restricted; explicit skill invocation had to remain a safe fallback; and Desktop, Xcode, private-harness, and public-distribution proof could not be blended into one inflated claim. GPT-5.6 helped stress-test those boundaries, trace failures across a large repository, and turn each decision into executable tests and release contracts.

Primary Codex session ID: 019f6e9b-331e-7e62-b7fc-85340818ae86.

Challenges

The hardest problem was not adding more skills. It was making ownership reliable before the model begins answering. Earlier routing depended on a custom runtime projection that could not be the basis of a portable public product. Replacing it required a trusted plugin hook, deterministic precedence rules, clear behavior when hooks are declined, and evidence that could distinguish genuine pre-sampling routing from a model merely naming the right skill later.

The second challenge was proof across different hosts. Stock Desktop, Xcode CodingAssistant, the private engineering harness, and the public Git artifact expose different execution providers and trust surfaces. The release work therefore treats them as separate evidence lanes and publishes only the claims each lane actually proves.

Accomplishments

  • Broad natural-language Apple requests route without requiring explicit skill invocation or user-managed orchestration.
  • A public, installable v0.2.0 Git Marketplace release.
  • Deterministic natural-prompt routing that no longer requires a fork runtime.
  • 12/12 stock Desktop routing cases, including trust failures, resume, compaction, and negative cases.
  • A separate 9/9 live Xcode host-compatibility matrix.
  • 17 hook-router tests and 110 plugin-contract tests recorded at qualification.
  • 44 coordinated Apple-development skills behind one discoverable workflow.
  • A fail-closed trust model with explicit, fully qualified skill invocation as the fallback.

What I learned

The brigade idea transfers surprisingly well, but the kitchen metaphor is only the source of the design. In the product, it becomes concrete engineering contracts: explicit ownership, focused stations, bounded handoffs, escalation, and evidence requirements. The useful interface, however, stays simple: the developer describes the outcome in ordinary language and never has to operate the brigade themselves. Reliable agentic software needs that ownership plane as much as it needs capable models. The best specialist is not useful if the host cannot select it consistently, and a polished final answer is not proof that routing happened at the correct time.

I also learned that distribution proof and behavior proof are different artifacts: a clean install proves transport and attribution, while a host matrix proves runtime behavior.

What's next

  • qualify the separate public plugin-portal path only after that portal proves it retains and installs the trusted hook payload;
  • simplify installation and first-run trust guidance;
  • add independent evaluation fixtures and more compact judge-friendly demos;
  • continue deepening focused Apple workflows without weakening the deterministic owner hierarchy or evidence boundaries.

Try it

Add the public Git Marketplace with a plugin-capable Codex CLI:

codex plugin marketplace add jkaunert/apple-appdev-workflow --ref main

In Codex Settings, open Plugins, find Apple AppDev Workflow by Joshua Kaunert, and install Apple AppDev Workflow. Review and trust the routing hook and approve the declared MCP servers when prompted. Start a fresh chat in an Apple project and enter:

Review this iOS app and tell me if it is ready for release.

The response should show route ownership before continuing into discovery and the release-readiness workflow. The user should not need to name either owner. If hooks are disabled, declined, changed, or restricted, use the explicit fallback:

$apple-appdev-workflow:apple-app-orchestrator Review this iOS app and tell me if it is ready for release.

Supported platform: macOS with a plugin-capable Codex build. Node.js and npm are needed for npm-backed MCP providers; Xcode is needed for project build, simulator, and full Apple-platform execution. The separately provisioned Xcode CodingAssistant companion is compatible with the routing payload but is not included in the public Marketplace archive.

Built With

Share this project:

Updates