PhoneClaw: an on-device agent runtime for iOS, with a Mac gateway bolted on
PhoneClaw turns phones into local AI agent runtimes with on-device models, native mobile Skills, LiveLand, and optional Mac Gateway inference.
At a glance
- What is it?
- PhoneClaw packages Gemma 4 and MiniCPM-V inference, native iOS Skills, and an optional LAN Mac Gateway into one Swift app. The interesting part is the constraint: what you can run depends on how the IPA was signed.
- Who is it for?
- Adopt PhoneClaw if you want agent loops that touch Calendar, Reminders, Contacts, Clipboard and Health data without leaving the device, and you are willing to build from source in Xcode rather than install a sideloaded IPA. Skip it if you need Android, or if your task depends on a model larger than Gemma 4 E4B, because the README states that sideload-signed builds cannot run E4B on GPU at all.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 41 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem PhoneClaw targets: agent loops that never leave the handset
Most mobile agent demos are thin clients. The phone captures a request, ships it to a hosted model, and renders whatever comes back. PhoneClaw inverts that. The README describes it as a local AI agent framework for phones and edge devices, running Gemma 4 E2B and E4B through LiteRT and MiniCPM-V 4.6 on device, with a fully offline local path. The audience is narrow and specific: iOS developers and technically comfortable users who want an agent that reads Calendar and Reminders, writes Contacts, touches Clipboard and Health data, and does all of it without a per-call token bill. The 2026-06-23 notes state that LiveLand runs on local models by default and that local execution is free of per-call token billing. That framing tells you who this is for. If your agent tasks are cheap and your privacy tolerance is high, a hosted model is simpler. PhoneClaw exists for the case where the data being read is the user's own health and schedule history, and where sending it to a third party is the thing you are trying to avoid. The project also carries an explicit disambiguation note: it is unrelated to the Android automation repo rohanarun/phoneclaw and to the phoneclaw GitHub organization, and app-store searches may surface a separate app with the same name. That matters when you are trying to find the right issue tracker.
Skills, routing and the tool-call chain inside the agent loop
The mechanism is a Skill layer. PhoneClaw exposes native mobile capabilities as Skills: Calendar, Reminders, Contacts, Clipboard, Health data, image understanding, voice, and LiveLand. A model does not call iOS frameworks directly. It emits a tool call, the framework routes it to the matching Skill, and the Skill result is fed back into the loop. The 2026-06-05 update describes a rebuild of that framework around Skill result semantics, Skill routing, tool-call chains, contextual follow-ups, and multi-step task handling, with the stated goal of letting the model decide whether to answer directly, call a tool, or continue from a previous result, while reducing accidental tool triggers and repeated calls. That is the honest description of where agent frameworks usually fail. The hard part is not invoking a calendar API. It is deciding not to invoke it, and knowing when a follow-up question refers to the previous tool result rather than starting fresh. Health range reports show the same pattern at a higher level: the README says PhoneClaw can summarize steps, distance, active energy, heart rate, sleep, workouts, weight and HRV across a selected range, then generate a local summary with trends and metric explanations. That is a multi-step read over a data store, not a single API call. The documentation does not publish routing accuracy figures or latency numbers, so treat the reliability claims as design intent rather than measured behaviour.
Running it: TestFlight, Xcode source builds, or a sideloaded IPA
There are three installation paths and they are not equivalent. The simplest is TestFlight, via the join link in the README. The second is building from source in Xcode. The third is a sideloaded IPA, and this is where the constraints bite. The 2026-04-23 notes carry a warning that sideload-signing imposes a memory cap, that under that cap the E4B model only works on CPU and fails on GPU, and that E2B is the recommended choice as fully featured and more stable under the cap. The same note says Xcode-signed builds are not subject to the sideload memory cap, so E2B and E4B can both run with GPU enabled. A 2026-04-23 release also added a settings toggle to choose between GPU and CPU inference backends, with CPU as the default specifically to fit within Sideloadly-signed memory limits. So the backend setting is not a performance preference you tune freely. It is downstream of how the binary was signed. Model downloads are handled by a module refactored in v1.3.0 for resumable downloads, background downloads, and automatic fastest-mirror selection based on current network conditions. Two model families are named in the README: Gemma 4 E2B and E4B via LiteRT, and MiniCPM-V 4.6 for image Q&A and real-time camera recognition in LIVE mode. An MTP speculative decoding toggle exists but is marked experimental, and the notes state it only speeds up Gemma 4 E4B with short replies.
Mac Gateway: Bonjour discovery, explicit pairing, and where your data goes
The Mac Gateway is the escape hatch for tasks the phone cannot handle. The mac-gateway-v0.1.1 release ships PhoneClawGateway-macOS-v0.1.1.zip. Per the README you unzip it, open PhoneClawGateway.app, grant Local Network permission, then pair from the Mac Remote page in iPhone settings. Discovery is over Bonjour on the same LAN, pairing is approved on the Mac side, and you then select a Mac-side model and use it from the normal chat screen. The Mac can front Ollama, Codex CLI, or Antigravity CLI as a remote inference source. The README is unusually direct about the consequence: remote models are only used after you explicitly pair a Mac and select one, and with Ollama inference stays on your Mac, while with CLI or other upstream providers data handling follows that provider's behaviour. Read that sentence as the actual boundary of the privacy claim. The offline local path is real when you stay on-device. The moment you route through a CLI provider, PhoneClaw is a client and the provider's terms apply. There is no claim in the material about transport encryption beyond the LAN pairing step, and the gateway is at v0.1.x, two releases in, which is early for anything you would put in a dependency chain.
LiveLand and the confirmation layer that keeps destructive Skills in check
LiveLand is the Dynamic Island surface, added 2026-06-23. It lets you launch the agent from Home Screen widgets, Lock Screen widgets, Shortcuts, Control Center widgets, or inside the app, and the notes state it also works on non-iOS 27 systems. Progress is reported in stages: command received, understanding, querying or executing, preparing the result, done. That staging exists because an agent that runs from a widget has no chat transcript to glance at. The more consequential addition is the confirmation layer. The same release notes state that unclear times, titles, contacts, deletes, and bulk operations ask for clarification or confirmation before running. This is the correct place to put a guardrail. A local model that misparses a date should ask, not schedule. A bulk delete should never be one inference away from execution. The release also fixed a LiveLand widget bug where the app could incorrectly show a download-model-first or model-loading state after the model was already installed, which is the kind of state-synchronisation failure that makes a widget feel broken even when the model is fine. Health range reports, added 2026-06-05, sit alongside this. The README does not describe how confirmation state is persisted across a LiveLand session that is dismissed and reopened, so that is worth checking yourself.
Where PhoneClaw is the wrong tool
Start with the signing constraint, because it is the one that will waste your afternoon. If your distribution path is a sideloaded IPA, the README states that E4B fails on GPU and that E2B is the recommendation. You are not running the model you read about in the headline. Second, this is iOS 17+ and Swift, per the badges, with no Android target described anywhere in the material. If your fleet is Android, the project offers nothing. Third, the local models are small by design. Gemma 4 E2B and E4B and MiniCPM-V 4.6 are on-device models, and the README makes no claim that they match a hosted frontier model on reasoning-heavy tasks. The Mac Gateway exists precisely because some tasks exceed what the phone can do, which is an admission that the on-device path has a ceiling. Fourth, the gateway itself is at v0.1.1. Two releases, both in June 2026, is not a track record. Fifth, the offline claim is conditional. The README's own wording limits it: remote models are used only after explicit pairing, and upstream provider data handling applies once you leave the local path. Anyone repeating the offline framing without that caveat is misreading it.
How this differs from Ollama and from hosted mobile assistants
The obvious comparison is Ollama, which PhoneClaw can actually use as a Mac-side backend rather than replace. The difference is where the loop lives. Ollama serves models over an HTTP API and leaves the agent scaffolding to whoever is calling it. PhoneClaw owns the loop: Skill routing, tool-call chains, contextual follow-ups, and the confirmation step for destructive operations are inside the app, on the phone. In the PhoneClaw arrangement, Ollama is a model server behind the gateway and the iPhone holds the agent state. The second comparison is hosted mobile assistants, where the model is remote and the device is a view layer. PhoneClaw's default is the opposite: inference on the handset, with the network used only for Web Search, webpage reading, or a paired Mac. That inversion is the whole product. It also explains the awkward parts. On-device inference forces model-size ceilings, which forces the signing constraint, which forces the gateway. A hosted assistant has none of those problems and pays for it with per-call billing and a copy of your health data on someone else's machine. PhoneClaw is a deliberate trade in the other direction, and the Mac Gateway is the pressure valve for when the trade stops being worth it.
Maintenance cost, licensing, and what to verify first
PhoneClaw is Apache-2.0, which permits commercial use and modification with the usual attribution and notice requirements. That is a permissive licence, and it does not by itself settle anything about the models you download through the app. Gemma and MiniCPM-V carry their own terms, and those terms are not covered by the repository's licence. Check them separately before shipping anything. On maintenance, the release cadence in the material is dense: v1.2.2, v1.3.0, v1.3.1 and v1.4.0 between 2026-04-23 and 2026-05-12, then the Mac Gateway at 0.1.0 and 0.1.1 in June, with the last push recorded 2026-08-06. Fast iteration on an agent framework means the Skill routing behaviour you tune against can shift between versions, so pin a release rather than tracking main. The gateway is the component with the most upgrade risk, since it is pre-1.0 and its whole job is talking to third-party CLIs and Ollama, any of which can change their interface. Before adopting, confirm three things: whether your signing path leaves you on E2B or lets you reach E4B with GPU, which model files you are licensed to redistribute if you ship a build, and whether the Mac Gateway is actually needed for your task list or whether the offline path covers it. The README's own disambiguation note is a useful reminder to file issues against kellyvv/PhoneClaw and not the unrelated Android project of the same name.
Editorial conclusion
Adopt PhoneClaw if you want agent loops that touch Calendar, Reminders, Contacts, Clipboard and Health data without leaving the device, and you are willing to build from source in Xcode rather than install a sideloaded IPA. Skip it if you need Android, or if your task depends on a model larger than Gemma 4 E4B, because the README states that sideload-signed builds cannot run E4B on GPU at all. Verify two things before committing: whether your signing path leaves you in the E2B-only tier, and whether your workflow actually needs the Mac Gateway, since pairing a Mac moves inference off the phone and into whatever upstream provider you point it at.
Community notes