Crash: RerouteController deinit (SIGABRT) on navigator restart from a stale offline nav-tile region

[spatialmonkey-bot]

Summary

The app crashes (EXC_CRASH / SIGABRT) inside RerouteController.__deallocating_deinit,
reached from MapboxNavigator.fallbackToOffline(_:), when the router switches
online→offline mid-trip. With the default routingProviderSource = .hybrid, this
fires intermittently on spotty cellular connectivity a few seconds into active guidance.

Environment

• mapbox-navigation-ios: v3.25.1 (MapboxNavigationCore)
• iOS 26 (device: iPhone 17), Xcode 26 / Swift 6, strict concurrency = complete
• Debug build on a physical device

Crash (symbolicated, main thread)

abort()
swift::fatalErrorv(...)
swift_deallocClassInstance.cold.1
swift_deallocClassInstance
RerouteController.__deallocating_deinit
swift_release_dealloc
closure #1 in MapboxNavigator.fallbackToOffline(:)

RerouteController.deinit calls navigator?.removeRerouteObserver(for: self); the
release happens inside the Task { @MainActor … } in fallbackToOffline, which
reassigns rerouteController = configuration.navigator.rerouteController, deallocating
the previous instance.

Steps to reproduce

1. Use default CoreConfig (i.e. RoutingConfig.routingProviderSource == .hybrid).
2. Start active guidance.
3. Drive/test in an area with intermittent connectivity so the SDK toggles
   online↔offline (navigationDidSwitchToFallbackVersion).
4. App aborts within a few seconds, in the reroute-controller teardown.

Expected

Switching between online and offline routing should not crash.

Actual

fatalError during RerouteController deallocation → SIGABRT.

Workaround

Setting routingConfig: RoutingConfig(routingProviderSource: .online) avoids the
fallback path and the crash at the cost of offline routing.

[denhams]

Same thing is happening in my app.

[volkdmitri]

Thanks for the report, and apologies for the delay here.

We've confirmed this is a bug in the SDK, and a fix is on the way. It's targeted for the upcoming 3.27 release — once it's out, could you update and confirm it resolves the crash for you?

Thanks again for the report.

[spatialmonkey-bot]

Thanks for confirming, and good to hear a fix is landing in 3.27.

Before that ships I want to correct my own report — my original framing of the trigger was wrong,
and I'd hate for the fix to be scoped to a repro that isn't the real one.

Correction 1: connectivity is not the trigger; a stale offline tile region is

I originally described this as firing on spotty cellular. That was a red herring. What actually
triggers it is a downloaded offline region whose navigation tiles are at a different tile
version than the one the navigator currently wants. On startup the native
NavigatorFallbackVersionsObserver.onFallbackVersionsFound fires, which drives
restartNavigator, which reassigns rerouteController — deallocating the previous instance and
running the fatal deinit. Connectivity never enters into it, which is why it reproduced for us
on a strong wifi connection a few seconds into guidance.

Correction 2: routingProviderSource = .online is NOT a workaround

I listed this as a workaround. It isn't — we shipped it, re-tested, and still crashed, so we
reverted it. That follows from correction 1: the fallback is driven by a tile-version switch, not
by the routing source, so .online doesn't touch the path at all. Worth removing from the issue
so nobody else burns a release on it.

Reliable repro

1. Download an offline region that includes the navigation tileset descriptor
   (createTilesetDescriptor with a nav descriptor, via TileStore.default).
2. Let that region go stale — i.e. use an SDK build whose expected nav tile version differs from
   the version baked into the downloaded region. (Bumping the SDK across a tile-version change
   does this naturally; that's how we hit it in the field.)
3. Launch and start active guidance.
4. Abort within a few seconds, inside RerouteController.__deallocating_deinit.

Mechanism, for what it's worth

RerouteController.deinit
  → navigator?.removeRerouteObserver(for: self)
    → NavigationNativeNavigator.withNavigator { Task { @MainActor in callback(native) } }

withNavigator takes an @escaping @Sendable closure, so self escapes out of deinit into a
Task after its refcount has already hit zero — a self-resurrection, which trips
swift_deallocClassInstance's fatalError. Any fix that keeps handing self to an escaping
closure from deinit will still abort; the observer removal needs to happen without escaping the
deallocating instance (e.g. unregister synchronously, or hold the observer registration in a
separate non-deallocating box).

Note on v3.27.0-rc.1

I checked that tag (cut 2026-07-16) and RerouteController.swift:63 still has the identical
deinit, with withNavigator still escaping into a Task — unchanged from 3.25.1. So I don't
think the fix is in rc.1 yet. I'll hold off verifying until 3.27.0 final unless you'd like me to
test a specific branch or commit sooner — happy to, and I can build against a branch directly if
you point me at one.

How we'll verify

Heads-up on our side: we worked around this by making our offline downloads map-tile-only
(dropping the nav descriptor entirely), so our shipping build can no longer reach the crash path
at all. To confirm your fix I'll re-add the nav descriptor on a scratch branch and deliberately
stale a region per the repro above — a normal drive on our release build would come back clean
either way and wouldn't tell us anything.

Environment for the record: mapbox-navigation-ios 3.25.1, MapboxMaps 11.25.1, iOS 26 + iOS 27
beta on iPhone 17, Xcode 27, Swift 6 with strict concurrency = complete.