I didn't get the 18 Pro Max because of the camera. I got it because I was tired of either sending sensitive stuff to the cloud or pretending a phone model was useful when it clearly wasn't. The A20 Pro is the first one where that trade-off started feeling reasonable.
Ten years of QA left me with a simple habit: if the data is client-related or just plain sensitive, I don't want it leaving the device unless I have a good reason. Streaming session logs, payment flows, real device recordings, internal API responses — most of that doesn't belong in a random cloud prompt. For a long time the local models on phones were too weak to matter. You could get them to rewrite a sentence. Anything more serious and you just opened the laptop. That changed with this chip.
One thing that still bothers me, living in Prague: the new Siri and the deeper Apple Intelligence features built on it are still not available in Europe. The hardware is sitting there with a strong Neural Engine, but the system-level AI that should make the phone feel integrated is just missing. There's no proper way to tap into the full potential of the A20 Pro through the OS itself. So the only real option is third-party apps and local models. It works, but it feels like a workaround for something the phone should already be doing.
What I Run
I keep two apps around. Locally AI is the one that feels the most polished right now.
Locally AI (by LM Studio) is the app I reach for most. It looks legit, the interface is clean, and the performance on the A20 Pro is solid. It handles Apple's own on-device foundation models well and also runs a good set of third-party quantized models. One of the practical ones I keep loaded is Ministral 3 3B — responsive enough for multi-turn work and good enough at the shorter QA tasks I throw at it. It also has a local voice mode, which is useful when I don't want to type on the tram. You can speak the prompt and get the answer without the text ever leaving the phone.
MLC Chat is the other one I keep. It's the App Store client for the MLC LLM project — models get compiled for Metal ahead of time, so on the A20 Pro they run noticeably quicker than the generic options at the same size. Once a model is downloaded, it stays offline. No account, nothing phoning home. I use it when I want the compiler-optimized path and a stable runtime. Stable is literal here: the App Store build hasn't been updated since September 2024, so the model list is frozen at what was compiled then.
On this phone the practical set looks like this:
- AFM 3 Core
- AFM 3 Core Advanced
- Ministral 3 3B
- More aggressive quantizations of Qwen and Gemma
- 1-bit Bonsai-class models, when I need the extra size
- Llama 3.2 3B
- Gemma 2 2B
- Phi-3.5 mini
- Qwen2.5 1.5B
A normal 3B-class model is responsive enough that I don't mind multi-turn use. The open models run on the GPU rather than the Neural Engine, so for them it's the faster GPU and the 50 percent extra memory bandwidth on the A20 Pro that make the difference between "it technically runs" and "I can actually iterate with it."
One more difference from the cloud assistants matters for testing. The big services wrap their models in separate filters that check prompts and answers. Run an open model locally and you get only the safety tuning baked into the weights. That cuts both ways. A local model will draft the injection payloads, malformed inputs and hostile test strings that a hosted assistant sometimes declines as a false positive. It also has no safety net: no filter catches it when it confidently gets something wrong, so nothing it writes reaches a real user or a test report without a human check.
Security First
The main reason the phone is in the toolkit at all is security. When you're dealing with streaming platforms or payment systems, even redacted logs can still contain session identifiers, device fingerprints, or partial user data that you don't want floating through a third-party API. Local models remove that decision for the smaller tasks. Nothing leaves the device. There's no account, no telemetry, no residual copy sitting in someone else's logs. For a QA lead that matters more than raw capability.
I still escalate the heavy reasoning to the Mac, but the phone handles the parts where the data itself is the sensitive asset. The local voice mode in Locally AI is nice here too — I can speak a short prompt about a log snippet without typing it out in public.
Nothing leaves the device. There's no account, no telemetry, no residual copy sitting in someone else's logs.
What I Actually Use It For
Most of the real agent work still happens on the Mac. Cursor, Claude, Codex — that side hasn't gone anywhere. The phone is for the smaller, privacy-sensitive loops.
Log and response triage. I paste a redacted but still sensitive API response or a log from the payment or authorization service into Locally AI (usually with Ministral 3 3B). The model extracts the failure pattern, points at the likely layer (payment gateway, provider callback, token or session handling, entitlement), and drafts the first set of reproduction notes. Because the context stays small and local, I can do this on the tram without worrying about where the snippet ends up. It's not deep root-cause analysis, but it shortens the later cleanup on the laptop.
Customer data analysis. Support tickets, NPS comments and complaint exports are some of the best QA signal I get, and also the most sensitive: names, emails, order and payment details, subscription history. Even pseudonymized, I'd rather not paste them into a cloud chat. Locally I paste a small batch and ask the model to group the tickets by problem area (payment, login, playback), pull out device and app version, and flag the ones that look like a real defect rather than a how-to question. The context window keeps the batch small, and I still spot-check the grouping by hand. Local doesn't mean exempt, though. Feeding customer data to a model on the phone is still processing under GDPR, so it belongs on a managed device and inside what company policy allows. What the local model removes is the third party in the chain.
Short automation review. Same approach with Playwright or Appium fragments. Missing waits, flaky selectors, missing assertions, or auth edge cases that only show up on real devices. I keep the snippet short so the model stays focused. It catches enough that the review pass on the Mac is faster.
Prompt and system-prompt checks. When I'm reviewing an AI feature, the system prompt is often sensitive in its own right: internal rules, service names, sometimes details that should never have been in a prompt at all. So I check it locally, in two passes. First a read-through: I ask the model to list anything secret or internal in the prompt, plus every rule like "never reveal X" that belongs in code rather than in text. Then a rehearsal: I set the feature's prompt as the system prompt in Locally AI and fire a set of known injection patterns at it, plus variants the local model drafts for me. The local model is a stand-in, not the production system, so results don't transfer one to one: a payload that works here goes on the list to rerun against the real feature, and a clean run proves nothing. It doesn't replace proper red-teaming, but it surfaces the lazy cases immediately and without sending the feature's prompt anywhere.
Focused questions with external context. Context windows on the phone are still limited, so I don't try to dump whole Confluence spaces or large log files into the conversation. I ask about one thing at a time and paste only the slice it needs: a single bug report, a schema excerpt, the few log lines around the failure. MCP would be the cleaner way to do this, with the model pulling a specific resource or tool on demand instead of me pasting it up front. LM Studio supports MCP on the desktop, but neither Locally AI nor MLC Chat supports it on iOS yet, so on the phone the slice is still manual. It doesn't solve every context problem, but it keeps the amount of sensitive material I paste small.
Where It Stops
The A20 Pro makes the multi-turn versions of these tasks tolerable. First tokens come back quick enough, and it doesn't fall apart the moment the conversation gets a bit longer. It still gets warm if you push it hard for a while — that's usually my signal to stop and move the rest to the laptop.
- Log and response triage
- Short automation review
- Prompt and system-prompt checks
- Focused questions on a small slice
- Customer ticket and NPS triage
- Driving a browser
- Rewriting a large suite
- Reasoning across many pages
- Deep root-cause analysis
None of this replaces the bigger models. When I need something that can drive a browser, rewrite a large suite, or reason across many pages, I still open the Mac. The phone is just the part of the toolkit that finally stopped being a toy for the private or mobile bits. In Europe it also happens to be the only practical way to use the AI hardware the phone already has, since the system features are still missing.
I still reach for the laptop for most of the heavy work. But the phone, with Locally AI (and MLC Chat) running on the A20 Pro, is no longer something I only use for working with cloud models. It's a genuinely useful tool in its own right.
The phone is just the part of the toolkit that finally stopped being a toy for the private or mobile bits.
