What this series is about
The MacBook is not available. Can the development of a web app with Claude continue from an iPad?
This series answers that question. It does not argue that an iPad should replace an everyday machine. It describes how the work can continue during a trip, a meeting lasting several days, or a visit.
Developers on MacBook, Windows and Linux machines develop web apps with the help of Claude. The developer talks to Claude in a chat, runs Claude Code in a terminal, and watches a hosting service build the result.
The series starts with the MacBook workflow, then shows how the same work is done from an iPad. Windows and Linux may be covered in later articles.
This first article gives an overview of the MacBook workflow and names its parts. Later articles use these names so that each detail, such as the setup of a browser on an iPad, can be traced to its place in the workflow.
The three roles
The work is shared between three roles. These roles are an anchor of the series: later articles refer back to them.
The developer decides. The developer approves every plan, every change and every merge, and is the only person who touches keys and passwords.
Claude, in the chat, plans and reviews. Claude writes the specification of each task, reads each report, and tells the developer what is waiting.
Claude Code builds and checks. It writes the code, runs the tests, opens the pull request, and writes the report.
These are responsibilities assigned in this workflow, not limits of the tools. Claude Code can make many decisions about code, but it does not decide what is built or merged. Claude explains what the reports mean, and the developer remains responsible for every approval.
The aim is that the developer can follow progress without reading every line of code. Reports and explanations support that judgment. They do not guarantee that a change is correct.
The parts of the workflow
These are the anchors. Each has one meaning throughout the series.
Planning and coordination
Chat: the conversation with Claude (claude.ai).
Task: one numbered unit of work.
Specification: the written description of a task, produced by Claude and approved by the developer.
Summary of the suggested steps: one browser page, kept by Claude, with only the steps the developer must do now.
Implementation and review
Claude Code: the tool that builds. On the MacBook it runs in the Terminal app, inside the repository folder.
Repository: the home of the app's code and its history on GitHub.
Branch: the place where Claude Code builds a task, away from the main branch.
Pull request: a proposal to merge a branch into the main branch.
Checks: the automatic tests that GitHub runs on a pull request.
Preview: a temporary copy of the app, built from the pull request by the hosting service, where the change can be looked at before it is merged.
Report: the summary Claude Code writes after each task. On the MacBook it is saved in a reports folder, where Claude reads it.
Release
Merge: the step that adds the branch to the main branch.
Production: the live app. It is deployed automatically when a merge reaches the main branch.
The loop
Every task, large or small, follows the same ten steps.
The developer tells Claude what is wanted, in plain words.
Claude writes the specification and the developer approves it.
Claude gives the developer one short message for Claude Code.
The developer pastes the message into Claude Code.
Claude Code builds on a branch, runs the tests, and opens a pull request. It does not merge.
GitHub runs the checks and the hosting service builds the preview. The developer looks at both.
Claude reads Claude Code's report and the result of the checks, and says whether the task is ready.
The developer approves, and a second short message tells Claude Code to merge.
Claude Code merges, which deploys Production, and reports the result.
The developer deletes the finished branch.
Only one task is in the loop at a time. The next one starts when the current one is done.
Rules that keep it safe
Keep secrets out of prompts. Keys and passwords never go into the chat or into a message to Claude Code. They live in a password manager and in the app's own key settings.
Keep production database access with the developer. Claude Code never holds the database's service key, and never touches the Production database. When a database change is needed, Claude reviews it and the developer runs it by hand.
Require approval before merging. Nothing is merged without the developer's word.
Review every report. Every report is read by Claude, and what the developer must do is stated in plain steps.
These rules depend on how permissions and settings are configured, not only on instructions given to the tools. The later articles cover that configuration.
When the MacBook is not available
On an iPad, the loop stays the same. What changes is where the work runs and where its records are kept.
Claude Code runs in the browser, in a remote environment, instead of in the Terminal. The reports are written to a repository instead of to a folder on the MacBook. The code and the reports are kept on GitHub. Secrets stay in their secure settings and never go into the repository.
The later articles describe the iPad setup, the switch from the MacBook to the iPad, and the switch back, step by step. They end with a complete sample app built from an iPad. The detailed steps come after the workflow and its parts are familiar.
An iPad is usually also a media device. The setup therefore treats the iPad as having two modes, media and development. It gives a way to enter development mode each time, without assuming that the browser has kept its tabs.
What comes next
Would this be useful when the primary development machine is not available? Which part should the next article cover? The comments decide whether the series continues.
Top comments (0)