Local chat depends on the model you put on your phone
PocketPal AI lets you download a GGUF language model and chat on your phone without a backend account. That is a useful fit for someone who wants an assistant available without a connection. The first decision is which model fits your phone's memory and storage, a choice the README explicitly leaves to the user. Our repository run did not measure a phone or generate an answer.
The README describes iOS and Android apps, with model discovery through Hugging Face and imports from local storage. Pals are configurable assistants with a model and system prompt. This puts model selection inside a consumer chat workflow, rather than making every user assemble an inference application. Whether a particular model follows your instructions well still needs checking with your own questions.
What happened when we ran it
Our sandbox installed PocketPal AI's 1,435 dependencies in 138 seconds, occupying 2,115 MB, on November 10, 2026. The measured commit was b0f3c83. The checkout contained 2,019 files, approximately 274,376 source lines and 34.5 MB before the dependency footprint.
No build script or target was found, so the build step was skipped. This means the generic lab path didn't produce a mobile application. It doesn't establish that the documented native platform commands are absent or broken. The scan found a tests directory and four CI workflow files, with no Dockerfile.
The test command exited 1 after 430 seconds. Jest reported 9,170 passed, zero failed and two skipped tests out of 9,172. It also reported three failed suites and 438 passing suites, with 310 passing snapshots. Those summaries describe different things: individual assertions passed, while some suites never ran successfully.
The named suites were scripts/tests/ios-llama-metal.test.js, scripts/tests/verify-android-payload.test.js and scripts/tests/verify-plus-gate.test.js. Each says "Test suite failed to run." The supplied tail has stack frames, but no underlying exception establishing why. Calling this a clean pass would hide a finding. Blaming missing platform tools would invent a diagnosis.
The configured sandbox had 3 CPUs, 8 GB RAM and image label lab-node:22. That label doesn't prove a runtime or operating-system version. We have no device latency, model quality, battery measurement or native launch result. The failing repository command is a reason to investigate source readiness, without treating it as proof that mobile inference fails.
Offline chat and optional online features have different boundaries
PocketPal's privacy note says chats and documents can leave the device through enabled web search and page reading, a remote server, or an online system voice. A reader choosing it for privacy should check those settings explicitly. "Runs on your phone" isn't enough information to approve every available workflow.
The README separately lists network activity for model and voice downloads, PalsHub, purchases and device-compatibility rules fetched at launch. It says those requests do not attach chats. These are the project's documented practices, not findings from traffic inspection. Download what you need, disable online features for an offline evaluation and confirm the intended workflow with connectivity removed before introducing private documents.
Hands-free voice is a paid store feature
The README places hands-free voice conversation in an optional PocketPal Plus purchase for App Store and Google Play builds. It says source builds include every Plus feature. That distinction matters if voice conversation is your reason for choosing the app: reviewing source availability doesn't tell you the terms of the store build you intend to use.
Speech also has its own execution choices. The documentation describes local Whisper recognition and on-device neural voices, alongside system voices. Pick a documented local voice when offline behavior is a requirement. We haven't measured recognition accuracy or speech quality, and the repository timings cannot answer either question.
Source development crosses native platform boundaries
PocketPal is a React Native application with native inference and speech bridges. The developer instructions require the pinned Node and Yarn versions, plus Xcode and CocoaPods for iOS or Android Studio with SDK and NDK for Android. The iOS simulator path specifically needs an Apple silicon Mac. A successful dependency installation covers only part of that work.
The README also warns that native changes require a rebuild rather than a JavaScript reload. Contributors should budget for the platform they intend to change and reproduce the failed script suites with full logs before drawing conclusions about them. For an ordinary user evaluating chat, the store route avoids taking on that contributor workflow.
Recent fixes show activity, with device behavior still unmeasured
The last push was November 10, 2026, and recent PR activity includes model-memory work. Release v1.23.0, published the same day, lists fixes for imported replies and an Adreno GPU load crash. These are maintenance signals and upstream change reports, rather than independent confirmation on our hardware.
The release also labels its local OpenAI-compatible API server a proof of concept. Don't select PocketPal as an established phone-hosted production API on that evidence. Its clearer evaluation path here is a downloaded model answering questions locally.
An engine or desktop runner may fit a different job
MLC LLM is a machine learning compiler and deployment engine. Its README documents iOS and Android interfaces alongside other targets. Consider it when you are building an application and want to own that integration. It doesn't answer the same ready-made mobile chat question as PocketPal.
Ollama documents macOS, Windows and Linux download paths. It is worth considering when inference can run on a computer instead of the phone. We have no comparative phone performance or setup measurement for either alternative.
The cards remain unrated: source installation alone cannot establish user setup ease, and this review doesn't assess support responsiveness or production maturity. Documentation was read, but its native and device-specific paths weren't reproduced. For a first trial, choose one model, switch off connectivity and ask questions whose answers you can check. Keep the full test failure log as a separate requirement if you intend to develop from source.