Mapbox Navigation SDK version
3.26.x (Maps 11.26.x)
Steps to reproduce
(Visibility rules introduced in 3.25 via the CarPlay speed-limit positioning/visibility update — CarPlaySpeedLimitViewConfiguration.shouldHideSpeedLimitView / CarPlaySpeedLimitViewVisibilityCoordinator)
Connect CarPlay and show the app on the map (free drive / browsing — no active turn-by-turn guidance).
Ensure free drive is running so map-matching provides speed limits (locationMatching / MapMatchingState has non-nil speedLimit).
Drive on roads with known posted limits (Vienna Convention signs).
Observe whether Mapbox’s CarPlay SpeedLimitView appears.
(Optional) Start active navigation on a similar stretch and compare.
Expected behavior
When speedLimit / signStandard are available and the navigation camera is in .following (and the user is not panning/previewing), the speed-limit sign should become visible after Mapbox’s short reveal delay (~0.2s), same as during active guidance.
Actual behavior
On free-drive, the private speedLimitViewContainer remains isHidden = true for the entire session (10+ minutes in our log), even though:
SpeedLimitView.speedLimit updates correctly (e.g. 30 / 50 / 70 km/h)
signStandard = viennaConvention
SpeedLimitView.isHidden goes false when data is present (canDraw OK)
isAlwaysHidden = false
navigationCamera.currentCameraState = following
So the view has data and would draw, but the container never unhides. Our own speed pill (fed from navigation().locationMatching → MapMatchingState.currentSpeed / speedLimit) correctly turned red when over limit, confirming the data path is fine.
When we later started active navigation, we saw container.isHidden true → false almost immediately, and the sign stayed visible for the rest of the drive.
This matches shouldHideSpeedLimitView keeping the container hidden — most likely areCarPlayControlsVisible stuck true (safe-area top/horizontal growth vs. the 38pt threshold on layouts) or another chrome input that does not clear in free-drive, while active navigation somehow re-evaluates and reveals the container.
Reproduced in a real vehicle (not only simulator).
Same road segments had shown the sign previously / showed it again under active guidance.
KVO on speedLimitView.isHidden vs speedLimitView.superview?.isHidden separates data-layer hide from chrome-layer hide; only the container stays stuck.
Happy to share anonymized diagnostic log lines (timestamps + containerHidden / speedLimit / camera / upcoming safe-area fields).
Is this a one-time issue or a repeatable issue?
repeatable
Mapbox Navigation SDK version
3.26.x (Maps 11.26.x)
Steps to reproduce
(Visibility rules introduced in 3.25 via the CarPlay speed-limit positioning/visibility update — CarPlaySpeedLimitViewConfiguration.shouldHideSpeedLimitView / CarPlaySpeedLimitViewVisibilityCoordinator)
Connect CarPlay and show the app on the map (free drive / browsing — no active turn-by-turn guidance).
Ensure free drive is running so map-matching provides speed limits (locationMatching / MapMatchingState has non-nil speedLimit).
Drive on roads with known posted limits (Vienna Convention signs).
Observe whether Mapbox’s CarPlay SpeedLimitView appears.
(Optional) Start active navigation on a similar stretch and compare.
Expected behavior
When speedLimit / signStandard are available and the navigation camera is in .following (and the user is not panning/previewing), the speed-limit sign should become visible after Mapbox’s short reveal delay (~0.2s), same as during active guidance.
Actual behavior
On free-drive, the private speedLimitViewContainer remains isHidden = true for the entire session (10+ minutes in our log), even though:
SpeedLimitView.speedLimit updates correctly (e.g. 30 / 50 / 70 km/h)
signStandard = viennaConvention
SpeedLimitView.isHidden goes false when data is present (canDraw OK)
isAlwaysHidden = false
navigationCamera.currentCameraState = following
So the view has data and would draw, but the container never unhides. Our own speed pill (fed from navigation().locationMatching → MapMatchingState.currentSpeed / speedLimit) correctly turned red when over limit, confirming the data path is fine.
When we later started active navigation, we saw container.isHidden true → false almost immediately, and the sign stayed visible for the rest of the drive.
This matches shouldHideSpeedLimitView keeping the container hidden — most likely areCarPlayControlsVisible stuck true (safe-area top/horizontal growth vs. the 38pt threshold on layouts) or another chrome input that does not clear in free-drive, while active navigation somehow re-evaluates and reveals the container.
Reproduced in a real vehicle (not only simulator).
Same road segments had shown the sign previously / showed it again under active guidance.
KVO on speedLimitView.isHidden vs speedLimitView.superview?.isHidden separates data-layer hide from chrome-layer hide; only the container stays stuck.
Happy to share anonymized diagnostic log lines (timestamps + containerHidden / speedLimit / camera / upcoming safe-area fields).
Is this a one-time issue or a repeatable issue?
repeatable