AI's Main Battlefield Is the Phone, Yet Memory Lives in the Cloud: NylonME, the First Open-Source Memory Engine Embedded in Mobile Apps

A Mismatch: You Live on Your Phone, Your Memory Lives in the Cloud

Look at what the mainstream AI assistants look like today: ChatGPT, Kimi, ChatYou, DeepSeek — their primary entry points are all mobile apps. And the private things users tell AI — health reports, family plans, job-change hesitations, 3 a.m. wandering thoughts — all happen on the phone.

Now look at how open-source memory engines deploy: mem0 needs Python plus a vector database to even start; Zep needs a graph database cluster; MemOS needs a GPU to schedule KV caches. Every single one is PC or cloud. Want to give a mobile app long-term memory? The architect's answer is: ship the user's data to a server, run the memory engine there, and send the results back.

Which means a user's most intimate memories must first leave their phone before they can be "remembered."

We think this mismatch should be fixed. nylon-mobile is open-sourced today: the complete NylonME memory engine, compiled into your app, running in-process — no open ports, no network traffic, and it remembers as long as it has power.

Not a "Lite Version" — the Same Engine

First, correct a gut assumption: mention "mobile port" and people picture a feature-gutted lite edition. nylon-mobile is the opposite — we extracted the server's core logic into a shared EngineCore, so the gRPC server and the mobile client run the exact same weave, resonance, and retrieval implementations. The mobile crate is just a thin UniFFI binding, called in-process directly from Kotlin and Swift.

This gives a rare guarantee: on-device and server behavior are identical. Same memory, same query, same result on both sides. We verified this in engineering practice — the CJK tokenization story below is the proof.

The mobile build cuts only three things, and cuts them with a clear conscience: server dependencies (tonic/axum/rmcp never enter the compile artifact), multi-tenancy (a phone has exactly one user — single tenant, single owner), and all billing and cloud logic — the latter belongs to the commercial layer, and will never exist in this crate.

Real-Device Numbers: Semantic Retrieval on a Mid-Range Phone

Anyone can draw architectures on paper; the real question of on-device AI is compute. We ran a real-device regression on an Honor NTH-AN00 (Snapdragon 778G — a 2021 mid-range chip):

Lexical channel (zero model dependency, pure graph retrieval):

• 20 mixed Chinese-English memories, 8 Chinese queries, top-1 hit on every single one
• 55 microseconds average per resonance — yes, you read that unit correctly: µs

Semantic channel (on-device ONNX embeddings, quantized bge-small-zh, just 24MB):

• top-1 hit on all 10 queries, including the pure-semantic probe "do you have a pet at home" — zero literal overlap with the target memory, correctly hitting the orange-cat entry via embeddings
• 0.3–1.2s per resonance (including query embedding, pure CPU inference), 0.3–1.1s per single weave

A 24MB model, a pure-Rust inference stack (tract + our own WordPiece tokenizer), sub-second semantic recall on a mid-range phone. For a memory engine's usage pattern — one or two calls per conversation — this performance hides entirely below the user's perception threshold.

Three Hard Battles on Mobile

Getting the engine into a phone isn't hard because of compilation — it's three things that simply don't exist on PC.

Battle 1: processes die without warning. A mobile app gets killed by the OS at any moment; there is no such thing as a graceful exit. Our answer is a three-layer safety net: writes go straight to WAL (process killed? replayed automatically on next launch); backgrounding the app triggers an automatic checkpoint (default: 32 writes or 300 seconds of dirty state); shutdown() does a compact plus flush. We verified WAL recovery across processes on a real device — not a single record lost.

Battle 2: Chinese queries have no spaces. A query like "what is the user's cat called" leaves English tokenizers dumbstruck. We implemented CJK query tokenization: Han terms expand into non-stopword single characters plus adjacent two-character groups, IDF-weighted, with "的/了/吗" excluded and two-character groups containing stopwords skipped outright. The real bug this fixed is worth telling: "user's cat" used to get hijacked by the "user's X" sentence pattern — because the group "户的" collides everywhere. After the fix, all 8 Chinese queries hit top-1. This logic lives in the core layer, shared by server and device — no "finds it on the phone but not on the server" splits.

Battle 3: the embedding model must work out of the box. The ONNX model downloaded from HuggingFace has symbolic shapes tract can't reconcile (the quantized version's value_info misbehaves), so we wrote a preprocessing script that strips them; the embedding dimension is auto-inferred from the model's output shape — swap models without touching code. We filled in every one of these pits and documented each step.

Why Mobile Is the Home Turf for Personal Memory

Cloud memory engines solve the memory of organizations: a support team sharing customer history, a department's agents sharing project experience — that's what the NylonME server edition has been doing all along (multi-tenancy, audit, TLS, team management — covered in earlier posts).

But personal memory is different. Your health, your moods, the tacit understanding you've built with your AI assistant day after day — the best home for these is not some company's server; it's the device in your pocket. The phone is the main battlefield of personal AI, and there has never been a memory engine that could fight on it.

Now there is. And the privacy story becomes almost trivially simple, simple enough for one sentence: your memories never leave your phone, because there is no reason for them to leave. Works offline, works in airplane mode, and switching phones is just copying a file.

Our full picture has two layers: personal memory on-device (nylon-mobile), team memory in the cloud (NylonME server) — the same engine kernel, each guarding its own boundary. AI assistant companies can build a personal assistant that truly "knows you"; app developers can add leak-proof long-term memory to any application.

Try It Today

• Repo: GitHub nylon-memory/NylonME, the nylon-mobile branch, at engine/crates/nylon-mobile/
• Android / iOS: UniFFI-generated Kotlin / Swift bindings; CI already covers NDK and iOS builds; releases produce .so / xcframework per tag
• Embedding optional: skip the model and you get the pure lexical channel (55µs); add the 24MB quantized model and you get on-device semantics
• Integration guide: INTEGRATION.md, including hook samples for onStop→checkpoint / onDestroy→shutdown

And the honest boundaries, stated up front: the device build is currently single-tenant single-owner; the LLM channels (weave decomposition, reflection) are left empty on-device — deep understanding on the phone will either rely on on-device small models (under evaluation) or a user-configured cloud LLM (on the roadmap). Swapping the embedding model to a different dimension requires rebuilding the memory store. We will keep filling these in — but day one of open source is exactly what it is.

The second half of AI needs memory, and memory's second half has two homes: one in the cloud, one in your pocket. We've open-sourced the pocket half first.

---

NylonME: a Rust memory engine, Apache-2.0. Server edition: LoCoMo 82.9% / LongMemEval-S full split 83.2%, both benchmarks above 80 on official full splits. Mobile edition: open-sourced today — same kernel, pocket deployment.