testflight/2026.06.20 #14

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

Signed-off-by: eisa01 <eisa01@gmail.com>

Adds a CarPlay Dashboard scene showing a Search shortcut button and a
placeholder view (map rendering in the dashboard is a follow-up).
Requires the CPSupportsDashboardNavigationScene key and scene
configurations for both CarPlay roles in the scene manifest.
Also migrates the main CarPlay connection from the deprecated
CPApplicationDelegate to CPTemplateApplicationSceneDelegate, required
after UIScene adoption — the old callbacks no longer fire once a scene
manifest exists. Scene delegate classes use explicit @objc names since
the Swift module name varies between build configurations.
UIApplicationSupportsMultipleScenes stays false: CarPlay scenes connect
regardless, and enabling it would offer iPad multi-window, which the
single shared MapViewController doesn't support.
Generated with Claude Code Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

With the scene-based lifecycle, the CarPlay scene can connect while no
phone window scene exists: when the app is force-quit on the phone with
CarPlay connected (iOS relaunches it immediately for CarPlay), or when
the app is launched directly into CarPlay.
In that state MapsAppDelegate.mapViewController hit its NSAssert, and
CarPlayService.setup passed the nil phone window to a non-optional
UIWindow parameter. Make the window and mapViewController properties
nullable, and defer attaching the map to the CarPlay window until the
phone scene connects, at which point SceneDelegate notifies
CarPlayService (attachMapIfNeeded).
Until the phone scene connects, CarPlay shows templates without the
map; decoupling the map view from the phone UI is a follow-up.
Generated with Claude Code Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

The map stack (MWMNavigationController with MapViewController and the
single Drape surface) was only created when the phone scene
instantiated Main.storyboard, so in a CarPlay-only session (force-quit
relaunch, phone locked in the car) CarPlay showed templates with an
empty map area.
Make MapsAppDelegate own the map stack: it is created once on demand by
whichever scene connects first and reused for the app's lifetime. The
phone SceneDelegate now builds its window manually instead of via
UISceneStoryboardFile (this also fixes scene reconnection creating a
second MapViewController), CarPlayService creates the stack when
attaching the map with no phone scene present, and CarPlaySceneDelegate
drives the framework foreground/rendering lifecycle in car-only
sessions, where the phone SceneDelegate isn't there to do it.
Generated with Claude Code Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

Host the shared map view in the CarPlay dashboard window whenever the
dashboard is visible, instead of a static placeholder. Per Apple's
guidelines the window contains only map content; the system draws ETA
cards and shortcut buttons itself.
CarPlayService now owns the decision of which window hosts the single
map view (updateMapHost): the visible dashboard wins, then the CarPlay
app window, then the phone — unless the user explicitly chose "Continue
on the phone". All scene lifecycle events funnel into this one
idempotent decision point, so activation-callback ordering between the
two car scenes doesn't matter. The dashboard can also be the first and
only connected scene (phone locked), in which case it creates the map
stack and the Drape engine itself.
The framework foreground/rendering lifecycle for car-only sessions
moved into a CarSceneLifecycle helper shared by both car scene
delegates: the app and dashboard scenes hand the car display over to
each other, so the framework only enters the background when neither
remains foreground-active.
Generated with Claude Code Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

UIKit drives each scene's lifecycle independently, so the phone scene
resigning active on screen lock would disable rendering, stop frame
presentation and location updates, and background the framework even
while a CarPlay scene was showing the map.
Centralize the framework foreground/rendering lifecycle for all scenes
(phone, CarPlay app, CarPlay dashboard) in SceneLifecycle: the framework
enters the foreground with the first active scene and enters the
background only when no scene is foreground-active anymore. This also
fixes the frozen map when CarPlay connects while the phone is already
locked.
Also:
- Enable UIApplicationSupportsMultipleScenes per the CarPlay App
 Programming Guide; keep iPad single-window since the app has one
 shared map stack
- Defer the dashboard search button action until the CarPlay app
 scene has connected
- Let updateMapHost() handle the map re-parenting in
 switchScreenToPhone() instead of duplicating the transition
- Rename FrameworkHelper.setRenderingEnabled to enableRendering
Generated with Claude Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

The my-position arrow snapped off-center in the dashboard because
CarPlayMapViewController kept pushing visible viewports while the
dashboard hosted the map: its mapView is nil then, so template events
and its own layout passes sent the full car screen frame in points
(scale fallback 1) against a surface measured in phone-scale pixels,
putting the drape pivot in the top-left quarter of the surface. Only
push a viewport while actually hosting the map view, with its real
contentScaleFactor.
The visual scale adjustment also required a phone window as comparison
source, so car-first sessions (locked phone) kept rendering at the
phone's visual scale, ~50% oversized on a 2x car screen. The target
scale only depends on the destination window: rework the adjuster API
accordingly, track the last applied scale to skip redundant tile
recaches, and drop the deferred-adjustment state from CarPlayService.
Generated with Claude Code Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

The car inherited whatever zoom level the phone was at (drape preserves
meters-per-pixel across host switches), which reads too close on a car
screen and especially in the small dashboard tile. Zoom out to level 15
once per CarPlay session, when the map first follows the position on a
car screen and no route is active, leaving navigation auto-zoom and
manual zooming alone.
Adds FrameworkHelper.setZoomLevel using relative scaling, which unlike
SetViewportCenter keeps the location follow mode intact.
Generated with Claude Code Fable 5
Signed-off-by: eisa01 <eisa01@gmail.com>

Signed-off-by: eisa01 <eisa01@gmail.com>

Surface turn lane recommendations during CarPlay navigation, as already provided by the routing core
Per Apple's CarPlay guidance, lanes are shown on two surfaces:
- Guidance panel: a full-width, symbol-only second CPManeuver whose symbolSet
 is a lane strip (recommended lane highlighted, others dimmed)
- Supported instrument clusters / HUDs: CPManeuver.linkedLaneGuidance
 (iOS 18+) (not tested, not possible in the normal simulator)
Generated with the help of Claude Opus 4.8
Signed-off-by: eisa01 <eisa01@gmail.com>

CarPlay previously rendered the upcoming turn as a single instruction
string built from the phone-oriented "[6A]: [US 101 South] > ..." text,
leaving the structured road data and the modern CPManeuver APIs unused.
Bridge the structured next-turn road components (name, ref, junction ref,
destination ref, destination, isLink) from FollowingInfo through to Swift,
alongside the maneuver direction, and use them to:
- Build CPManeuver.instructionVariants as a descending-length array so the
 head unit can pick the longest text that fits the available width,
 instead of a single pre-formatted string that just truncates.
- Populate the iOS 17.4 instrument-cluster / HUD metadata: maneuverType,
 junctionType, and highwayExitLabel.
The variants are composed from the structured fields (clean "Exit 6A:
US 101 South → San Jose" rather than the bracketed phone syntax), falling
back to the existing formatted street name. The new FollowingInfo field is
additive and unused on Android, but should be tested
Generated with the help ofClaude Opus 4.8
Signed-off-by: eisa01 <eisa01@gmail.com>

Surface turn lane recommendations during in-app phone navigation, as already
provided by the routing core and already shown on Android and CarPlay.
The routing core exposes lanes via FollowingInfo::m_lanes, but the phone
navigation dashboard ignored it. This reuses the LaneWay / MWMLaneInfo Swift
models introduced for CarPlay:
- LaneWay gains turnImageName, mapping each direction to the existing
 NavigationDashboard/Turn/* arrow assets (mirrors the Android LaneWay.mTurnRes
 mapping and the existing CarPlay symbolName).
- MWMNavigationDashboardEntity gains a lanes property, populated from m_lanes
 for car routing via the same GetActiveLaneWays() extraction used by
 MWMRoutingManager.
- NavigationLanesView draws the upcoming turn's lanes as a horizontal strip:
 the recommended lane(s) at full opacity, the rest dimmed, hidden when empty.
- MWMNavigationInfoView places the strip beside the turn box, mirroring Android.
Generated with the help of Claude Opus 4.8
Signed-off-by: eisa01 <eisa01@gmail.com>

Sync with Carplay, move to shared helper
Signed-off-by: eisa01 <eisa01@gmail.com>

Mirrors iOS + Android
Signed-off-by: eisa01 <eisa01@gmail.com>

When CoMaps was launched directly into CarPlay, and the last session on the phone was not the following mode, CarPlay did not have the position in focus either
Engage following automatically once the location settles on a car screen (CarPlay app or dashboard), so the map centers and follows on startup.
Guarded to once per session so it never re-forces following after the user intentionally stops it.
Generated with the help of Claude Opus 4.8
Signed-off-by: eisa01 <eisa01@gmail.com>