# MapMap Nav — verdict

*Written from the position the brief demanded: an outside RN shop building on
MapMap with only published artefacts and public docs. Full evidence in
[FINDINGS.md](./FINDINGS.md).*

## The two questions

### 1. Could a competent React Native shop ship this in two weeks with MapMap *today*?

**No — not as it stands today. With the fixes below, yes comfortably.**

What we actually proved in this build:
- The **app is real and complete** — twelve screens to the UI spec, a typed
  JS↔native bridge, on-device routing/guidance/voice wired to the SDK, a
  replay-drive demo path, EAS profiles, store + privacy drafts.
- **iOS compiles end-to-end** (`BUILD SUCCEEDED`) — app → pod bridge →
  MapMap SDK → Valhalla.
- **Android compiles** to a full APK; the *only* thing standing between it
  and a device build is the GitHub Packages credential.

But "a competent shop, two weeks, today" fails on four things that are not
the app's fault:

1. **There is no React Native / Expo module.** You must write the bridge
   yourself — ~2,000 lines of Swift + Kotlin across territory install,
   routing, a guidance event stream, and voice. We did; it's reusable, but
   it's two weeks of senior mobile work on its own.
2. **The published iOS SDK did not compile.** 0.2.0 shipped without its
   generated UniFFI bindings and its resource declaration — unusable as
   distributed. We diagnosed it, fixed the packaging, and cut **0.2.1**.
   An end user without the ability to rebuild the SDK would have been dead
   in the water on day one.
3. **The CocoaPods↔SwiftPM wall.** An Expo module is a pod; a pod cannot
   consume a SwiftPM product (`spm_dependency` is test-specs-only in
   CocoaPods 1.16, and pbxproj injection leaves the module invisible). The
   only route to a green build was **vendoring the entire SDK + Valhalla +
   boost into the pod** and recompiling it — days of work, and fragile.
4. **The backend demo path is currently broken** — the signed territory
   channel 404s and hosted routing is origin-pinned to one edge (F1, F2).
   Neither is the SDK's fault, but both block the flagship end-to-end
   journey right now.

Net: a strong team spends its two weeks fighting distribution and packaging,
not building product. The product part is genuinely a few days once the
plumbing works — which is the whole point of the next answer.

### 2. Should MapMap ship an official `@mapmap/react-native`?

**Yes. It is the single highest-leverage thing MapMap can build.**

Every blocker above except the backend outages is a *packaging* problem, and
an official module solves them at the source:

- It **is** the bridge — the one we wrote is a working first draft of it
  (territory lifecycle, routing, guidance stream, voice, typed events).
- It lets MapMap own the **CocoaPods↔SPM seam once**, centrally, instead of
  every customer re-discovering the wall and vendoring the SDK by hand.
- It's the natural home for a **prebuilt `MapMapKit.xcframework` + a
  CocoaPods podspec** and a Maven-published Android artefact, so integrators
  never compile Valhalla + boost themselves.
- It makes the two-week estimate real: with a working module, this exact app
  is a ~1-week build.

**Recommended sequence for MapMap:**
1. Fix the two server outages (territory channel, routing origin) — they
   break the product for *everyone*, not just this demo.
2. Ship `MapMapKit.xcframework` (prebuilt, all-slices) + a CocoaPods podspec;
   publish the Android AAR somewhere that doesn't require a personal PAT
   (Maven Central), and document the verifying-key/credential story.
3. Wrap both in `@mapmap/react-native` (this repo's `mapmap-react-native`
   module is the seed) with an Expo config plugin.
4. Fix the docs drift (0.1.0 → 0.2.x, `gpr.key` → `gpr.token`, the Rust
   samples labelled "Kotlin/Swift", the missing on-device search / offline
   style / territory-removal APIs).

Do that and MapMap goes from "a determined shop can force it to work in a
month" to "any RN developer ships offline turn-by-turn in an afternoon" —
which is the story this demo exists to tell.

## Bottom line for the client demo

The app is built and it is polished. What it demonstrates *today*, honestly:
the UI, the architecture, and the on-device SDK integration all work
(iOS proven to `BUILD SUCCEEDED`, journey recorded against the SDK's own
mock provider while the hosted territory channel is down). What it cannot
yet demonstrate live — a real signed-territory install and a hosted-routing
preview — is blocked by two server-side outages, not by the app or the SDK
integration. Both are a box-side fix away from a fully live demo.
