BrainDrive Mobile App

BrainDrive Development
1

Hi All,

@DJJones is starting on iOS and Android apps for mobile so starting a new thread here where we can share our projects and for others to participate.

Questions, comments, ideas and contributions welcome as always.

Thanks
Dave W.

Braindrive Installer
2

@djjones — now that the Mac + Windows installers are landing, here’s the v1 spec for the next bucket: BrainDrive Mobile (iOS + Android) via Capacitor. Want your review before we lock the build plan.

Full docs in the Library:

The shape

  • Capacitor 8 wrapping the existing React client. One codebase, two stores.
  • Full TS runtime on-device (per D3). Memory = markdown files in Capacitor Filesystem. Models remote — all three paths (Models / OpenRouter / Tailscale-Ollama).
  • Adam Carter is the V1 persona (D1). GitHub PAT, Tailscale + Ollama API key, App Store IAP assumed. Katie polish comes V2+.
  • Free at launch (D8). No Concierge subscription required.
  • US-only v1. UK/CA/AU as v1.1. EU as a separate v2 workstream (DMA paperwork is real).

What I’d most like your eyes on

1. The 7 runtime adapters. The runtime-jsonly spike landed on three categories of Node-only usage that need adapters before the TS runtime will run cleanly inside the WebView:

  • Filesystem (~145 imports) → Capacitor Filesystem adapter
  • Child process / git (~32 imports) → in-memory journal or zip-based snapshot
  • Crypto (~8 imports) → Web Crypto + tweetnacl.js

Spike estimates 3–4 weeks for one engineer, no blockers. File:line refs in the spike report. Does that match your intuition from the codebase, or is the lift bigger than that?

2. IAP integration. Per D9, credit purchases route through Apple/Google IAP with pass-through pricing (OpenAI pattern). The braindrive-models pricing fields (D43 — input/output cost per N tokens) feed this. Open question: pass-through ratio vs absorb (see open-questions.md Q1). The US iOS storefront also gets an additional “Buy at braindrive.ai (web price)” link gated by SKStorefront.countryCode == "USA" (allowed under AGR 3.1.1(a) post-Epic, May 2025).

3. Secure-storage plugin pick. Recommendation: @aparajita/capacitor-secure-storage (Capacitor 8 ready, MIT, actively maintained). Side-findings worth knowing: @capacitor-community/secure-storage-plugin doesn’t actually exist on npm despite a lot of guides citing it; @evva/capacitor-secure-storage-plugin was archived on May 4. Open to alternatives if you have a preference — aparajita was the cleanest fit I found.

4. The handful of App Store gotchas that’ll matter most for submission:

  • Named-provider consent screen before any external model call (5.1.2(i), enforced Nov 13, 2025)
  • Working test API key in App Review Notes — #1 BYOK rejection cause
  • 17+/18+ age rating, in-app report mechanism on AI responses
  • NSLocalNetworkUsageDescription for the Tailscale/Ollama path
  • Privacy manifest via Capacitor 8 (avoid ITMS-91061)

Open questions

  • IAP pricing pass-through ratio (Q1, open-questions.md)
  • Apple post-Epic commission rate watch (Q2)
  • Sequencing — mobile is ahead of the connectors-first pivot (D173/D174); want to confirm we’re aligned on that
  • Build owner for the Capacitor shell + onboarding flow (assumed you for runtime adapters; would others pick up the onboarding/IAP layer?)

Take a look when you have a minute. Happy to walk through it on the next call. The build plan is the next step — wanted your read on the spec + the adapter scope before we lock phasing.

Braindrive Installer
3

Hi All,

Quick update on where we are with BrainDrive on phones.

@DJJones spent time researching running BrainDrive natively on iOS and Android via Capacitor. The finding: he full-runtime path is blocked at the Gateway layer — the Node backend can’t run natively on either platform without a Go rewrite.

What’s encouraging is that this turned out to be a proof point for the architecture rather than a problem with it. The implementation language would have to change; the architecture itself holds. He found a clean separation point too: the client has a single hard-coded /api reference to the Gateway, and making that dynamic gives us a thin-client path — front-end on the phone, backend on either managed hosting or your own local server via Tailscale. Small lift when we pick it back up.

For now we’re pausing all mobile work to focus elsewhere (more on that in a separate post about document processing as the next feature and we will keep mobile on the roadmap to prioritize as we go.

Questions, comments, and concerns welcome as always. Just hit the reply button.

Thanks,
Dave W.