mobile-app-builder

Mobile App Builder

A workflow for taking a mobile app from idea to a published, maintainable product — with Claude acting as the builder and the user acting as the product owner. It is grounded in the durable structure taught in Learning Mobile App Development (Iversen & Eierman): every app is the same set of capability modules assembled on top of a platform, and the work proceeds Plan → Design → Build → Test → Publish. The book's specific 2013 toolchains are obsolete; its architecture is not, and this skill carries the architecture forward onto modern stacks (Flutter, React Native/Expo, native SwiftUI/Compose).

The core idea

The book teaches one app twice — once for Android, once for iOS — and both versions implement the same capability modules: a navigation/interface layer, persistent data, list/table displays, maps and location, and hardware/sensor access. The lesson to carry forward: design the app once, platform-agnostically, then implement. In the modern world that means either implementing once in a cross-platform framework (the usual choice) or implementing per platform from a shared spec. Either way, the spec comes first and the capability modules are the reusable vocabulary you build with.

The agentic operating model (read this first — it governs everything)

How Claude behaves during a build matters more than any individual code snippet. Follow these principles in every phase:

1. Spec before code. Never start writing an app from a one-line idea. First produce a short, concrete spec: the screen inventory, the data model, the target platforms, the framework, and the must-have vs. later features. Use assets/app-spec-template.md. A non-coder especially needs this — it is the shared contract that keeps the build on track. Confirm it with the user before building.

1. Scaffold a runnable skeleton, then iterate. Get an empty-but-running app onto the emulator/simulator before adding features. A blank app that launches is worth more than a feature-complete app that won't compile, because every later step is verified against something that already works. Only after "it runs" do you add the first capability module.

1. Build capability-by-capability, verifying each. Add one module (navigation, then data, then a list, then maps…), run it, look at it, confirm it works, then move on. This mirrors the book's chapter structure for a reason: each module is independently testable, and incremental verification is the single biggest defense against the "everything broke and I don't know why" failure mode that derails non-coders.

1. Treat the user as product owner, not engineer. The user decides what the app does and how it should feel; Claude decides how to implement it and explains decisions in plain language. Surface product choices (offline behavior, monetization, which platforms) as questions; do not surface implementation trivia unless asked.

1. Care for the non-coder's environment explicitly. Toolchain setup (SDK installs, PATH configuration, emulator creation, signing) is where non-coders get stuck and quit. Give exact copy-paste commands, say briefly what each does, and verify the result before proceeding. See references/non-coder-playbook.md.

1. Keep a persistent project map. Maintain a short living document (in Claude Code: a file like PROJECT.md at the repo root; in Claude.ai: a running summary) listing the spec, what's built, what's next, and known issues. This is what lets work survive across sessions and context limits.

1. Respect the platform; don't fight it. Use platform-idiomatic navigation, controls, and conventions. An app that ignores platform idioms feels broken to users even when it technically works.

The agent team and orchestration

This skill is run by a small team of specialist agents coordinated by an orchestrator, because building, breaking, and judging an app are genuinely different mindsets — giving each its own "head" stops the builder from grading its own homework. Act as the orchestrator first (read agents/orchestrator.md), then delegate to the specialist charters in agents/ as each phase demands.

The roster:

• •Orchestrator (Build Manager) — owns the workflow: which agent runs when, the handoffs, the quality gates, and the shared state. agents/orchestrator.md.
• •Planner — scope and purpose; guards against feature creep. agents/01-planner.md.
• •Architect — framework, structure, screen graph, data model, constraint pass. agents/02-architect.md.
• •Interface Builder — screens, navigation, layout, platform feel. agents/03-interface-builder.md.
• •Data & Services Builder — persistence, network/sync, business logic, secrets. agents/04-data-services-builder.md.
• •Security Officer — defensive review: secrets, token storage, transport, permissions. agents/05-security-officer.md.
• •Red-Teamer — independent offensive pass against your own build to harden it. agents/06-red-teamer.md.
• •QA / Test Engineer — functional correctness, persistence, fragmentation, real-device. agents/07-qa-test-engineer.md.
• •UX & Accessibility Critic — feel, hierarchy, states, accessibility. agents/08-ux-accessibility-critic.md.
• •DevOps / Environment Engineer — toolchain, PATH, emulator, signing. agents/09-devops-environment.md.
• •Release Manager — store assets, testing tracks, submission, rollout. agents/10-release-manager.md.

How they run depends on the environment: in Claude Code the orchestrator can spawn agents as parallel subagents (the two Builders concurrently; QA/Security/Red-Team as independent passes against the finished build), which is what makes the build-then-attack pattern powerful. In Claude.ai there are no subagents, so the orchestrator plays each role in sequence by switching stance. Either way, keep the Security Officer and especially the Red-Teamer independent of the build context — a reviewer who also wrote the code grades gently.

Not every app needs all ten. The orchestrator runs lean mode (Architect → combined Builder → one QA-plus-security Reviewer, DevOps on-call) for a simple solo app, and escalates to full mode the moment the app handles real user data, auth, payments, or public release. See agents/orchestrator.md for the phase→agent map, the gates, and mode selection.

The five phases

Each phase has a detailed playbook in references/workflow-phases.md. Read that file when you begin a build or when the user is squarely inside one phase. The phases in brief:

1. Plan

Clarify why the app exists and who it's for, then turn that into scope. Decide the target platforms, pick the framework (see "Choosing a framework" below), and list the features as must-have-now vs. later. Output: the filled-in assets/app-spec-template.md.

2. Design

Convert scope into a concrete, buildable shape before any code:

• •Screen inventory — enumerate every screen and how the user moves between them (the navigation graph). The book introduces its example app purely as a list of screens (Contact, Contact List, Map, Settings); do the same.
• •Data model — what entities exist, their fields, and which persistence tier each needs (see capability modules).
• •Platform-constraint pass — walk the design against the mobile realities the book foregrounds: screen size & orientation, intermittent connectivity, battery cost, hardware that may be absent, and device fragmentation. Each of these can change the design, so do it before building.

3. Build

Scaffold the runnable skeleton, then implement capability modules one at a time (see "Capability modules" below and references/capability-modules.md). Pick the framework reference file and follow it. Verify on an emulator/simulator after every module.

4. Test

Run on emulator/simulator continuously during the build; run on at least one real device before publishing (the book is emphatic on this — the simulator hides real-world behavior). Test against fragmentation: different screen sizes, OS versions, and missing hardware. See the testing section of references/publishing.md.

5. Publish

Prepare store assets, configure signing, submit through the correct store process, and use staged testing tracks (internal/closed/open on Google Play; TestFlight on iOS) before public release. Decide the monetization model. See references/publishing.md.

Choosing a framework

Resolve this during Plan, because it shapes everything after. Quick guidance:

• •Flutter — strong default for a single team/person shipping to both iOS and Android with a custom look; one Dart codebase, excellent tooling, good for non-coders working with an agent because the build/run loop is fast and the widget model is uniform. (This is the stack behind apps like NutriGuide.) Detailed guidance: references/framework-flutter.md.
• •React Native / Expo — best when the user or team already knows JavaScript/React, or wants to share logic with a web app. Expo dramatically lowers the setup burden for non-coders. Detailed guidance: references/framework-react-native.md.
• •Native (SwiftUI / Jetpack Compose) — choose when targeting a single platform, when you need the absolute latest OS features or deepest hardware integration, or when platform-perfect feel is the priority. Detailed guidance: references/framework-native.md.

If the user has no preference and wants both platforms, default to Flutter (or Expo if they know React) and say why in one sentence.

Capability modules

These are the reusable building blocks every app is assembled from — the same set the book implements once per platform. When the user asks for a feature, map it to a module and follow references/capability-modules.md, which translates each one to all three stacks:

• •Navigation & interface — the screen graph plus per-screen layout, then wiring behavior (the book's Activities/Layouts/Intents and iOS storyboard equivalents).
• •Persistent data — three tiers: preferences (small key-value settings), files (blobs/media), and a database (structured, queryable data). Choosing the right tier per entity is a core design decision.
• •Lists & tables — displaying collections and navigating into detail, via the data-source-and-adapter pattern (RecyclerView/UITableView → ListView.builder/FlatList).
• •Maps & location — obtaining location from multiple sources (geocoding an address, GPS, network) with their accuracy/battery/permission tradeoffs, and displaying maps.
• •Hardware & sensors — camera, accelerometer, and other sensors accessed through managers, always with feature-detection and runtime permissions because the hardware may be absent.

Reference index

Read the file that matches where you are; don't load them all at once.

• •references/workflow-phases.md — the detailed per-phase playbook (Plan/Design/Build/Test/Publish).
• •references/capability-modules.md — each capability module mapped to Flutter, React Native, and native.
• •references/framework-flutter.md — Flutter project setup, run loop, structure, gotchas.
• •references/framework-react-native.md — React Native/Expo setup, run loop, structure, gotchas.
• •references/framework-native.md — SwiftUI and Jetpack Compose setup and structure.
• •references/publishing.md — testing on real devices, fragmentation, store submission, monetization.
• •references/non-coder-playbook.md — environment setup, working with Claude Code as a non-coder, the safe iteration loop.
• •assets/app-spec-template.md — the planning artifact to fill in during Plan/Design.
• •agents/orchestrator.md — the build manager: phase→agent map, gates, shared state, lean vs. full mode, execution mechanics. Read this when starting a build.
• •agents/01-planner.md … agents/10-release-manager.md — the ten specialist charters; read the one for the agent you're delegating to.

Where this could extend into an MCP server

Publishing is the one phase with mature external APIs (App Store Connect API; Google Play Developer API). A future MCP server could wrap those to let Claude upload builds, manage testing tracks, and read review status directly. That is optional, advanced scope — build it only when a user specifically wants store-publishing automation, using the mcp-builder skill.

Red flags to watch for

• •The user wants to "just build the whole thing" from a vague idea → slow down, produce the spec first.
• •A build is failing and the cause is unclear → stop adding features; get back to a known-running state, then change one thing at a time.
• •A non-coder is stuck on setup → the blocker is almost always environment (PATH, SDK, emulator, signing), not the app code. Diagnose there first.
• •Choosing a database/file when preferences would do (or vice versa) → revisit the persistence tier.