Mobile ⇄ Web Feature Gap — living tracker

What this is: the ongoing, prioritized backlog of what the web app (apps/frontend) can do that the pre-release mobile app (apps/mobile, React Native / Expo) cannot yet. This is the gap-closing view. The status grid (every feature × every surface) lives in FEATURES_BY_INTERFACE.md — this doc reads from it and adds priority, rationale, and a re-audit cadence.

Last audited: 2026-07-15 (by AI assistant, route-diff method below) Next audit: see the recurring product task "Mobile⇄web gap: re-audit + close top gaps".

Legend: ✅ shipped on mobile · 🟡 partial / read-only / deep-links-to-web · ❌ not on mobile · 🚫 not a mobile target (web/headset/admin-only by design)

How this doc is scoped

Mobile is a daily-companion surface: capture, coaching, presence, and light review — the things you reach for a phone to do. It is not meant to mirror every web surface. Three big web areas are deliberately web-first and should NOT be counted as mobile gaps:

• VR / WebXR surfaces — /dashboard/vr, /cockpit, /dome, /stream/immersive, /inspiration/vr, /notebooks/vr, /circles/vr, /entries/[id]/vr. These target headsets, not phones. (A native mobile presence layer is its own track — see MOBILE_JQ_PRESENCE.md.)
• Admin / operations — everything under /dashboard/admin/* (111 pages). Super-admin tooling stays on the web.
• DreamPro public science community — the citizen-science platform (world map, competition, sponsors, calculators, K-12) is a public-web surface; mobile only needs the personal DreamPro (dreams + steps), which it has.

Everything else below is a real parity candidate.

2026-07-16 re-scope — the journaling-market lens

The journaling-space marketing analysis (see the comparison SEO cluster: /compare/journaling, /compare/hivejournal-vs-*, /best-journaling-apps-2026, data in apps/frontend/src/lib/journaling-compare.ts) adds a second prioritization axis on top of the daily-loop tiers: what unblocks competing with Rosebud / Day One / Stoic. Concretely:

1. Store presence is the gate, not a feature — every competitor is app-store native; our comparison pages honestly list "no native app in the stores" as our top gap. → P0 task "Mobile: ship HiveJournal flavor to TestFlight → App Store" (reuse the WW Phase-0 EAS flow; the journaling loop below is already shipped, so this is config + store checklist, not feature work).
2. Voice entry capture (already Tier 1) gains a competitive rationale: it's a paid feature on Rosebud ($12.99/mo) — shipping it free flips a no cell in the comparison matrix.
3. JQ chat on mobile (Tier 1) is the AI-reflection parity play — Rosebud's whole product is conversational reflection on a phone.

When any of these ship, update the matrix cells + HIVEJOURNAL_SELF.honestGaps in journaling-compare.ts — those pages advertise our gaps by design.

Tier 1 — core daily-loop gaps (close first)

These are things a mobile user hits in normal daily use where the phone is the better device, or where the absence breaks the core loop.

Tier 2 — companion features (close next)

Valuable on mobile but not loop-breaking.

Tier 3 — creator / niche surfaces (defer)

Web-first for now; port only if a mobile audience emerges.

🚫 Not mobile targets (do not port)

• VR / WebXR: /dashboard/vr, /cockpit, /dome, /stream/immersive, /inspiration/vr, /notebooks/vr, /circles/vr, /entries/[id]/vr
• Admin: all of /dashboard/admin/*
• DreamPro public science community: map / competition / sponsors / calculators / classrooms (personal DreamPro dreams are on mobile ✅)
• Marketing / public pages: /, /features, /compare, /about/*, etc. (mobile follows deep links into the in-app browser)

What mobile already has (✅ shipped)

Auth · Dashboard (entries list + search) · Entry detail / editor · Notebooks (list/detail/editor) · Goals (list/detail/editor) · Stream · DreamPro (dreams / detail / editor) · Sleep entry · Note analysis (read-only) · JQ Bridge (accept + view + my-connections) · Encouragement Drops (received) · Graphene slate + season detail · Writer · Workout Window (setup / check-in / dashboard / chain / mosaic / battle) · Settings (profile / email prefs) · Share entry.

Wired screens confirmed in apps/mobile/src/navigation/MainNavigator.tsx.

Re-audit procedure (run this each cycle, then update the tables + dates above)

The audit is a route diff between web and mobile:

# 1. Web user-facing surfaces (exclude admin)
find apps/frontend/src/app -name page.tsx | sed 's|apps/frontend/src/app||;s|/page.tsx||' \
  | grep '^/dashboard' | grep -v '/admin/' | sort

# 2. Mobile wired screens (source of truth = what's in the navigator, not orphan files)
grep -oE 'name="[A-Za-z]+"' apps/mobile/src/navigation/*.tsx | sort -u

# 3. Cross-check against the per-feature status grid
#    docs/reference/FEATURES_BY_INTERFACE.md  (Mobile column: ✅ / 🟡 / ❌)

Registered ≠ reachable. Step 2 tells you a route exists, not that the buttons pointing at it work. navigate('X') resolves only against the navigators in the caller's chain — its own stack, then the tab navigator, then the root stack. A route registered in DashboardStack is invisible to a screen in SettingsStack, and React Navigation drops an unhandled action (dev-only warning, nothing in release), so the button silently does nothing. Five Settings cards shipped dead this way — the audit counted them ✅ because the grep found the names. When a screen is linked from more than one tab, register it in each of those stacks via the shared featureScreens() fragment in MainNavigator.tsx, and spot-check the entry point by tapping it, not by grepping for it.

For each new web /dashboard/* route since the last audit: classify it as a Tier 1/2/3 gap or 🚫 not-a-target, add a row, and (if it's a real gap) confirm FEATURES_BY_INTERFACE.md has a matching Mobile ❌. Bump Last audited / Next audit at the top.

Keep this doc and FEATURES_BY_INTERFACE.md in sync — that grid is the feature-level source of truth; this doc is the prioritized backlog on top of it.