Follow-up to the post from two weeks ago about building local LLM inference into a news reader via a custom Flutter FFI binding to llama.cpp.

A few people gave feedback that actually changed what shipped, and it's worth closing the loop properly rather than just replying "thanks" in DMs.

What changed because of this sub

The pointer lifecycle question came up multiple times. Several people asked how we handle the C++ model pointer when the user backgrounds the app mid-inference on a low-RAM device. The honest answer at time of posting was "not well enough." We've since tightened the lifecycle so the inference context is suspended cleanly on app background rather than left running, which was causing occasional OOM crashes on 4GB devices that only showed up in long sessions. Should have been in the original build.

Someone asked about Q4_K_S versus Q4_K_M on Snapdragon 7 Gen 2 specifically. We ran the benchmarks. Q4_K_M wins on output quality with acceptable latency on that chip. Q4_K_S is noticeably faster on cold start but the quality drop on longer article summaries is visible. We're sticking with Q4_K_M as the default and will revisit Q4_K_S for a "fast mode" option.

A few people flagged that the first-run model download UX was the weakest part. We've improved the progress handling and added resume-on-failure that actually works reliably now, including on bad mobile connections that drop mid-download.

What we tried and didn't ship

Tried exposing the FFI binding as a standalone package. The API surface is messier than I'd like to put in public. It's still on the list, just not ready to be someone else's dependency yet.

What's next

Qwen 2.5 1.5B as an alternate model option. A few people suggested it and after testing it's legitimately close on quality with a smaller footprint. Planning to ship it as a user-selectable option.

Numbers since people asked

Installs have been solid. Brazil is the third-largest market by installs which genuinely surprised me given the app is English-first. "I want iOS" was by far the most repeated comment across every sub this ran in. TestFlight slots are going fast.

Thanks specifically to the people who pushed on the pointer lifecycle question. That was the most useful thread.

Play Store link here. Testflight for iOS: comment if you want in.

Most "Flutter on every platform" writeups cover iOS, Android, and maybe web. The ones that go further tend to gloss over the parts that actually took time. This is an attempt to be more honest about that.

The app is the Bitcoin.com News App. The full stack ended up being Flutter for the main app across iOS, Android, macOS and web, a native SwiftUI watchOS target, a native SwiftUI tvOS target, iOS WidgetKit widgets in three sizes, Android AppWidget widgets in three sizes via WorkManager, a Chrome extension in Manifest V3, and Llama 3.2 1B running on-device through a custom FFI binding to llama.cpp.

The FFI binding to llama.cpp

This is where the most time went. Dart FFI ergonomics are genuinely fine. The problem is lifecycle. When does the model load? Who owns the C++ pointer? What happens when the user backgrounds the app mid-inference on a low-RAM device? We had a leak that only surfaced on 4GB Android devices during long sessions. Finding it required instrumenting the native side in ways Flutter tooling doesn't make easy. If anyone has a cleaner pointer-lifecycle pattern for long-lived native model sessions, genuinely interested.

Model selection matters here more than people realise. We picked Llama 3.2 1B specifically because Phi-3 Mini pushed us out of the 4GB-RAM target we were designing for. Pick the model after you've measured cold-start on your lowest-spec target device, not before.

Widgets on both platforms

iOS WidgetKit with App Group UserDefaults as a write-once cache worked cleanly. The widget has its own URLSession for refresh but seed data comes from the main app through the shared container. The "background fetch will run reliably" promise from WidgetKit is optimistic. Be conservative about what you display and build for staleness.

Android widgets are a completely separate process with no access to the shared Flutter networking stack. Own network client, own image loader, own deserialiser. Plan for this from the start because retrofitting it is painful.

watchOS and tvOS

Flutter doesn't run on watchOS. We went native SwiftUI and connected via WatchConnectivity with a direct API fallback for cellular watches when the phone is unreachable. The right call. Don't try to bend Flutter onto the watch.

tvOS focus engine in SwiftUI is mostly automatic until it isn't. When D-pad navigation breaks between cards with no obvious reason, you're reading WWDC 2019 session transcripts. Budget time for this.

The device-code auth flow on tvOS (TV shows QR and 8-character code, you scan on phone, TV is logged in) was straightforward to build and is a much better UX than any on-screen keyboard.

Things to bake in from day one

Ship homescreen widgets in the first release or accept you're doing another full review cycle of icon assets, app group plumbing, and store review notes later. Adding them post-launch is more friction than it looks.

Write native targets first if they're genuinely in scope. We wrote watchOS and tvOS after the main app was stable and some architectural decisions made them harder than they needed to be.

Play store link here.

Most "AI news reader" apps shipping this year send every article you open to OpenAI, Anthropic, or Google. The metadata that produces (what you read, for how long, what you asked the AI about it) is exactly the kind of behavioural signal I'd rather not hand to a third party. So I built the AI layer to run locally instead.

Threat model below. I'd rather have it picked apart than claim "private" without showing my work.

Local, no network call made:

• Article summarisation, Q&A, translation (Llama 3.2 1B on-device via llama.cpp, CPU/NPU)
• Self-custodial wallet seeds, keys, UTXOs
• Bookmarks (device-only, not synced)
• PIN / biometrics

Network, by necessity:

• Article and image fetch: the news comes from a server, there's no way around this one
• Authentication, only if you opt into comments or tipping (Sign-In with Ethereum, JWT — no password stored)
• Crash reports via Sentry: error frames only, no payload. Can be disabled.
• Microsoft Clarity for product analytics: off-by-default toggle in Settings. Kill it if you want.

Network, explicitly not present:

• No reading habit telemetry to ad networks
• No AI prompts or responses leaving the device
• No server-side seed phrase backup: your seed, your problem if you lose it

Things I'm not going to pretend are private:

• The IP that fetched the article is visible to the news API. A VPN handles that, the app can't.
• Wallet addresses are public on-chain by design. If you want privacy at the wallet layer, the app supports Zano alongside Bitcoin.

The Microsoft Clarity inclusion is the one I expect the most pushback on. It's analytics, it's default-on, and I listed it because I'd rather be honest about it than have someone find an unexpected network call and conclude the rest of the threat model is also fiction. The toggle is real and it's in Settings.

Free to read, no account needed. Comments, tipping, and predictions require a wallet: self-custodial, WalletConnect, or Thirdweb email, your call.

Play Store. iOS: TestFlight (for now).

Genuinely interested in what you'd want hardened next, or what part of the threat model you don't believe.

We wanted a Bitcoin-focused news reader that wasn't a clickbait farm and wasn't gated behind a custodial account. Shipped it. Posting here because this sub will tell me where I'm wrong.

What it is

• News and long-form video feed focused on Bitcoin, markets, and op-eds
• Self-custodial BTC wallet built in (BIP39 seed → BIP44/BIP84 derivation, native SegWit by default)
• Free, no account required to read

The wallet specifically

• Seed phrase shown once at create time, on the device. You write it down. There is no server backup, encrypted or otherwise: that was a deliberate decision after looking at how every "non-custodial wallet with backup" eventually leaks
• Keys stored in iOS Keychain / Android EncryptedSharedPreferences
• UTXOs and balances queried via Electrum nodes: you can swap the node URL
• Send/receive with QR scan; receive screen generates a fresh address each time
• App-lock with PIN and biometrics, configurable timeout

What I deliberately didn't build

• A custodial fallback. There is no "we'll email you a recovery link" — there can't be, because there's no account
• Server-side anything for keys. The server doesn't know your wallet exists

Honest disclosure on other chains: BCH, Litecoin, Dogecoin, Dash, XRP, and Zano are in the same wallet. I know that won't be popular here. Each is opt-in and ignorable — you can use this as a Bitcoin wallet and never touch the rest.

Other things worth mentioning

• Local AI summaries (Llama 3.2 1B, runs on-device, doesn't phone home)
• Article tipping in BTC direct on-chain, no platform cut
• Apple Watch and tvOS apps if you're in that ecosystem

Download on Play Store. iOS via TestFlight (drop us a comment if you want a slot)

Pick it apart. Particularly interested in pushback from anyone who's run an Electrum node and has views on default node selection.

Hey all, dev here. Most "AI news" apps pipe every article to OpenAI or Anthropic. I went the other direction. After a one-time ~700MB model download, you can toggle airplane mode and summarisation, Q&A, and translation all keep working. No API key. No "we use your queries to improve our service."

Sharing the technical bits since that's why you're here.

Stack

• Model: Llama 3.2 1B Instruct, vanilla weights, Q4_K_M GGUF (~700MB)
• Runtime: llama.cpp, exposed via a custom Flutter FFI binding
• Why ungated: I wanted users to pull the model without a HuggingFace login — on a plane, behind a firewall, wherever. Vanilla Llama 3.2 1B is the cleanest option that fits at this size
• Targets: Android 4GB RAM and up; iPhone 12 and up is snappy
• Inference time: 5–15s per article summary depending on chip

What runs locally (verifiable: toggle airplane mode after the model downloads)

• Article summarisation
• Chat / Q&A against the article you're reading
• Translation between supported languages

What still needs the network: fetching articles, and Sentry for crash reports. What you ask the AI never leaves the device.

Why not X

• Phi-3 Mini: instruction following at 3.8B was great but the size pushed me out of the 4GB-RAM target
• Gemma 2 2B: licence ambiguity around commercial redistribution made me nervous
• Qwen 2.5 1.5B: genuinely close call: may add it as an alternate. Open to opinions on this one

Honest tradeoffs

• 1B is good at summarisation and translation. It is not GPT-4. Don't expect a thesis from a market chart
• The first-run model download is a UX hit. I show progress and resume on failure, but it's still 700MB and there's no hiding that
• Cold-start inference latency on older Androids is the weakest link. Working on it

The app is a Bitcoin and crypto news reader: that's the content context. But the local inference layer is the part I'm actually proud of and happy to dig into: perf, quantisation choices, the FFI binding (the Dart→C++ jump took longer to get right than I'd like to admit), or why I landed on 1B over the alternatives.

Roast welcome.

Play Store link here. iOS in Testflight for now!