Skip to content

Connect native navigation in the installed mobile app #398

New issue
New issue
Open
Feature
Open
Connect native navigation in the installed mobile app#398
Feature

Description

@Medformatik
Medformatik
opened on Oct 6, 2026

What problem would this solve?

The mobile shell has processors, durable sessions, effects, permissions and recovery code, but the installed App deliberately advertises native navigation as unavailable because the foreground graph is not composed. Browser planning/fallback paths and shell capability boundaries remain separate; isolated native components are not proof of usable installed navigation.

What would you like to be able to do?

Connect the existing foreground coordinator/processor graph, validated bridge command dispatch, permission controller, effect ports, driver, narration/notifications and active-session description in the production shell. Preserve one native owner for location and durable navigation. Enable each mode/capability only after its real runtime is ready. Out of scope: a new renderer, offline route engine, voice recognition, car UI or station-entrance data pipeline. Resolve exact supported first-release modes and device matrix during triage; land independently verified mode/lifecycle slices rather than one unreviewable rewrite.

Verified current state

Rechecked against main at a8e03bc3efc49207d91f7c1855402c6cf149b8fd on October 7, 2026.

Acceptance criteria

  • Installed Android and iOS apps can start, pause, resume and end each advertised navigation mode through the authenticated bridge.
  • Permission denial/revocation and foreground-only/background availability are explicit; unimplemented modes remain gated.
  • Background/foreground, WebView reload, process death and recovery preserve coherent session ownership with no duplicate location driver.
  • Narration and notifications handle interruption/mute; failed effects do not prevent essential cleanup.
  • Stale/untrusted document commands are rejected, active-session handshake reflects durable state, and browser fallback remains valid.
  • Real-device lifecycle evidence, automated integration tests, capability docs and screenshots are supplied before declaring modes production-ready.

Verification approach

Add production App composition tests spanning valid bridge commands, permission outcomes, driver ownership and recovery; retain channel rejection and effect-failure cases. Run pnpm mobile:verify, pnpm mobile:prebuild:check, pnpm mobile:bundle:check, appropriate pnpm mobile:smoke/QA evidence, and root lint/type/test checks. Actual-device Android/iOS interruption/background/recovery checks remain required; passing mocks or one simulator is not certification.

Dependencies and decisions

No data-provider change is required. Use the comparison/replay corpus as it becomes available; #309 is a completed web arrival handoff, not native composition. Background permission, runtime effect-port choices and supported mode matrix are blocking design decisions. Offline routing, recognition and car integration depend on this composition, not vice versa.

Alternatives or workarounds

Advertising capabilities before composing their ports would create false promises. Replacing the native architecture discards tested session/recovery groundwork; continuing browser-only behavior is the valid fallback until composition is verified.

Additional context

Area

Other / cross-cutting

Ownership and status

Maintainer-owned backlog; implementation has not started. Resolve the named decisions during triage before scheduling work.

Activity

  1. Medformatik
    added
    enhancement
    needs-triageOpen issue awaiting initial maintainer review
    on Oct 6, 2026
  2. Medformatik
    added the
    Feature
    issue type on Oct 6, 2026
  3. Medformatik
    updated Priority High and Effort High on Oct 6, 2026
  4. Medformatik
    marked this as blocking 3 issues on Oct 6, 2026
  5. Medformatik
    removed
    enhancement
    on Oct 18, 2026
  6. Medformatik
    changed the title [-]Compose native navigation in the installed mobile shell[/-] [+]Connect native navigation in the installed mobile app[/+] on Oct 18, 2026
  7. Medformatik
    removed
    needs-triageOpen issue awaiting initial maintainer review
    on Oct 30, 2026
  8. Medformatik
    added 2 commits that reference this issue on Nov 3, 2026

    fix(mobile): start the installed app and keep its bridge on Android (#…

    e68106f

    feat(mobile): run native ground and transit navigation in the install…

    ae28df7

  9. Medformatik commented on Nov 3, 2026

    @Medformatik
    Medformatik
    on Nov 3, 2026
    CollaboratorAuthor

    Progress update, 3 November 2026: native navigation is composed on Android and ran on a physical device.

    Four merged PRs make the installed Android app start and run native navigation:

    Status against the acceptance criteria:

    • Start, pause, resume and end each mode, on Android and iOS: partly done.
      • Android ground navigation: start, end, and resume after the process is killed were verified on a Pixel (Android 17) against openmapx.com. Pause was not exercised.
      • Transit is composed but was not run on a device. Its refresh and replan effects are still no-ops: a transit session keeps its captured itinerary.
      • iOS has not run on a device.
    • Permission denial, revocation and foreground-only availability are explicit: partly done. The native disclosure, Android's "Allow all the time" page and the notification prompt were verified on the device. Foreground-only mode and revocation during a session were not exercised on a device.
    • One location owner across background, reload and process death: done for the cases tested. The background task uses the registered foreground coordinator, and a killed process resumes its session. A WebView reload during a session was not tested specifically.
    • Narration and notifications handle interruption and mute; failed effects do not block cleanup: partly done. Speech waits for the TTS engine to initialise; three consecutive cold launches spoke, but one earlier launch reported a failure that was not explained. Interruption and mute were not tested on a device.
    • Stale or untrusted commands rejected; handshake reflects durable state: done. The existing channel checks are unchanged, and the handshake now reads the active durable session.
    • Device evidence, integration tests, docs and screenshots: done for Android. App composition tests were added, mobile-architecture.md describes the composition, and the PRs include device screenshots.

    Remaining for this issue:

    • Run on iOS.
    • Wire transit refresh and replan.
    • Exercise on a device: pause, foreground-only mode, revocation mid-session, a WebView reload mid-session, audio interruption and mute, and a reroute on the road.

    #404, #405 and #406, which depend on this issue, were rewritten today to ask for implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Feature

    Fields

    Priority

    High

    Effort

    High

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions