PhoneClaw: a local AI agent runtime for iPhone, built in Swift
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 runs Gemma 4 and MiniCPM-V 4.6 on-device through LiteRT, exposes native iOS Skills for Calendar, Reminders, Contacts, Health and more, and optionally routes inference to a Mac over the LAN. This is what the repository documents, and where it stops.
- Who is it for?
- PhoneClaw fits iOS developers and tinkerers who want an on-device agent loop they can extend with their own Skills, and who are willing to build from source with Xcode rather than rely on a sideloaded IPA. It does not fit anyone who needs an Android build, a supported App Store release, or a documented public API: the README points to TestFlight and source builds only, and the repository does not document Skill authoring interfaces beyond the Skills directory.
- 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 55 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 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What PhoneClaw solves, and for whom
Most mobile AI assistants send your request to a server. PhoneClaw takes the opposite position: the README describes it as "a local AI agent framework for phones and edge devices" that performs inference and Skill calls entirely on-device, with a fully offline local path. The models named are Gemma 4 E2B and E4B, run through LiteRT, plus MiniCPM-V 4.6 for image questions and camera recognition in LIVE mode.
The intended user is an iOS developer or a technically comfortable tinkerer who wants an agent that can read a calendar, create a reminder, look up a contact, translate text or summarize health data without the request leaving the phone. The project is Swift, targets iOS 17 and later, and is licensed Apache-2.0. It is not a hosted service and not a cross-platform SDK. The README states plainly that PhoneClaw is unrelated to the Android automation repository "rohanarun/phoneclaw" and to the "phoneclaw" GitHub organization, and warns that app-store search results on Android may show a separate app with the same name. If you arrived looking for an APK, you are in the wrong repository.
The on-device agent loop and how Skills are routed
The architecture visible in the repository is a phone-side agent loop with a Skills layer underneath. The top-level directories separate the concerns: Agent/, LLM/, Skills/, Live/, LiveLand/, MacGateway/, UI/, Shared/, plus Packages/, LocalPackages/ and Frameworks/ for dependencies. The model runtime lives in LLM/ and the tool surface in Skills/, which is the layout you would expect from a framework that treats the model as one component and native capabilities as another.
The routing behaviour is described in the 2026-06-05 update notes, which say the agent framework was rebuilt to improve "Skill result semantics, Skill routing, tool-call chains, contextual follow-ups, and multi-step task handling". The stated goal is that the model can more reliably decide whether to answer directly, call a tool, or continue from a previous result, while reducing accidental tool triggers, repeated calls and off-track follow-ups. That is a routing problem, not a model problem, and it is where most local agent projects quietly fail. The README does not publish the routing algorithm or the prompt structure, so the mechanism has to be inferred from the directory layout and the release notes.
A second design decision is that remote inference is opt-in. The README says remote models are only used after you explicitly pair a Mac and select one. With Ollama the inference stays on your Mac; with CLI or other upstream providers, data handling follows that provider's behaviour. Web Search and webpage reading are likewise described as explicit choices rather than defaults.
Installing PhoneClaw: TestFlight, sideload or Xcode
There is no package manager step. The README points to a TestFlight link for the app, and to source builds for anything else. The TestFlight link given in the README is:
open https://testflight.apple.com/join/YuUSwq78For a source build, the repository ships PhoneClaw.xcworkspace and PhoneClaw.xcodeproj alongside a Podfile and Podfile.lock, so the expected path is a CocoaPods install followed by an Xcode build. The README's own guidance is to build from source with Xcode where possible, because Xcode-signed builds are not subject to the sideload memory cap. The exact scheme and destination are not documented in the README, so check the workspace targets before assuming a command.
A first real use, once a model is installed, is a natural-language phone task. The 2026-06-23 notes list health data, reminders, calendar events, contact lookup and translation as examples, and the 2026-06-01 notes describe calendar queries for today, tomorrow, this week and the next seven days with busyness and free-time analysis. Launch LiveLand from a Home Screen widget, Lock Screen widget, Shortcut, Control Center widget or inside the app, and the README says the local AI listens, understands, runs the task and shows the result in the Dynamic Island. The documentation states that LiveLand runs on local models by default and that local execution is free of per-call token billing.
Adding a Mac Gateway for inference you cannot run on the phone
The Mac Gateway is the escape hatch for tasks the phone cannot handle. The workflow in the README is: download PhoneClawGateway-macOS-v0.1.1.zip from the mac-gateway-v0.1.1 release, unzip it, open PhoneClawGateway.app, allow Local Network permission, then pair from the Mac Remote page in iPhone settings. The Mac advertises itself over Bonjour, you approve pairing on the Mac side, choose a Mac-side model, and then use it from the normal chat screen.
unzip PhoneClawGateway-macOS-v0.1.1.zip
open PhoneClawGateway.appWhat this buys you is access to Mac-side Ollama, Codex CLI or Antigravity CLI as a remote inference source. What it costs you is the offline guarantee. The README is explicit that with Ollama, inference stays on your Mac, but with CLI or other upstream providers, data handling follows that provider's behaviour. The gateway is a LAN feature, not a tunnel: discovery happens over Bonjour on the same network, and the README does not describe any remote-access or authentication story beyond pairing approval. The Mac Gateway releases are versioned separately from the app, with mac-gateway-v0.1.0 and mac-gateway-v0.1.1, so the two sides can drift.
Where PhoneClaw breaks: memory caps, signing and model choice
The clearest limitation is documented in the 2026-04-23 notes. Sideloadly-signed IPAs hit a memory cap, and under that cap the E4B model only works on CPU; GPU will fail. The README recommends the E2B model in that situation, calling it fully featured and more stable under the cap. If you build from source with Xcode instead, the cap does not apply and you can run E2B or E4B with GPU enabled. That is not a footnote. It decides which model you can use, which backend you run, and whether the app is usable at all on a sideloaded install.
A second constraint is platform. This is an iOS 17+ Swift project. The related searches around PhoneClaw are dominated by Android phrasing, and the README explicitly disclaims the Android repository and the same-named app-store listing. There is no Android target in the top-level entries.
A third is the experimental MTP speculative decoding toggle added on 2026-05-07, which the notes say only speeds up Gemma 4 E4B with short replies. That is a narrow win, and it is labelled experimental.
The last push to the repository was on 2026-08-06, and the most recent release listed is mac-gateway-v0.1.1 from 2026-06-23. The README does not document any deprecation policy, migration path or upgrade procedure for the Mac Gateway, so if you pin the gateway you should pin the app release alongside it.
PhoneClaw against a server-side agent stack
The obvious alternative is a server-side or cloud agent stack, where the model runs on a hosted endpoint and the phone is a thin client. The difference is not performance, it is the trust boundary. A hosted agent can call tools server-side and reach models far larger than anything that fits in phone memory, and it works on any device with a browser. PhoneClaw gives that up in exchange for the request never leaving the device on the local path, and for native access to Calendar, Reminders, Contacts, Clipboard, Health data, image understanding and voice through Skills rather than through a web API.
A second comparison point is the Mac Gateway itself. Running Ollama on a Mac and pairing over Bonjour is a middle position: bigger models than the phone can hold, but still on hardware you own. The README notes that with CLI providers the data handling follows the provider, which means the middle position is only as private as the backend you point it at.
What PhoneClaw does not offer is a documented public API for third parties, a web interface, or a Linux target. If your requirement is an agent that runs on a server and serves many users, this project is not that, and the Skills directory is the wrong abstraction for it.
Licence, maintenance and the cost of keeping up
PhoneClaw is Apache-2.0, which permits commercial and modified use under the terms of that licence, including its patent grant and notice requirements. That is a permissive choice and it is consistent with a framework that expects people to build their own Skills on top. It is not legal advice; read the LICENSE file and the NOTICE handling that Apache-2.0 requires before shipping a derived product.
The upgrade cost is real because the project ships several moving parts on separate schedules. The app has its own releases (v1.4.0 on 2026-05-12 is the most recent listed), the Mac Gateway has its own (v0.1.0 and v0.1.1), and the README's update history shows frequent changes to routing, download behaviour and the LiveLand launch path between April and June 2026. The 2026-06-23 notes include a fix for a LiveLand widget launch issue that could incorrectly show "download model first" or "model loading" even after the model was installed, which is the kind of bug that appears when the app and the widget extension disagree about state. If you fork the Skills layer, expect to re-read the routing notes on each app release. The repository does not document a supported upgrade path for the Mac Gateway.
Editorial conclusion
PhoneClaw fits iOS developers and tinkerers who want an on-device agent loop they can extend with their own Skills, and who are willing to build from source with Xcode rather than rely on a sideloaded IPA. It does not fit anyone who needs an Android build, a supported App Store release, or a documented public API: the README points to TestFlight and source builds only, and the repository does not document Skill authoring interfaces beyond the Skills directory. Before adopting it, check that your device and toolchain match the iOS 17+ and Swift 5.10 badges, confirm whether you intend to run E2B or E4B given the sideload memory cap, and read the Skills directory to see what a custom Skill actually requires.
Frequently asked questions
Is PhoneClaw available for Android?
No. The repository is a Swift project targeting iOS 17 and later, and the README states that PhoneClaw is unrelated to the Android automation repository "rohanarun/phoneclaw" and to the "phoneclaw" GitHub organization. Android app-store search results may show a separate app with the same name.
Which model should I run on PhoneClaw, Gemma 4 E2B or E4B?
It depends on how the app is signed. The README notes that under the Sideloadly memory cap the E4B model only works on CPU and recommends E2B instead, while Xcode-signed builds are not subject to that cap and can run E2B or E4B with GPU enabled.
How do I install PhoneClaw on an iPhone?
The README gives a TestFlight link at testflight.apple.com/join/YuUSwq78, and also describes building from source with Xcode. There is no package manager step; the repository ships an Xcode workspace and project along with a Podfile.
Does PhoneClaw send my data to a server?
The local path is fully offline according to the README, and LiveLand runs on local models by default. Remote models are only used after you explicitly pair a Mac and select one; with Ollama inference stays on your Mac, while with CLI or other upstream providers data handling follows that provider's behaviour.
What is LiveLand in PhoneClaw?
LiveLand lets you use PhoneClaw from the Dynamic Island. The README says the local AI listens, understands the request, runs the task and shows the result there, and that it can be launched from Home Screen widgets, Lock Screen widgets, Shortcuts, Control Center widgets or inside the app.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kellyvv-phoneclaw)