Expo SDK 57: getRootViewForAutoplay snippet doesn't compile, and MapTemplate renders nothing on CarPlay

[spendres]

Thanks for this library — the API shape is exactly what we needed, and the cross-platform maneuver types (TurnType, OffRampType, … mapping to both TYPE_TURN_SLIGHT_LEFT and slightLeftTurn) are a better design than we'd have arrived at ourselves.

We're integrating into an Expo SDK 57 app (prebuild/CNG, New Architecture, RN 0.86.2) that also uses @googlemaps/react-native-navigation-sdk. We're stuck on the main question below, and found three things on the way that look like real issues rather than our misuse.

1. The README's getRootViewForAutoplay snippet doesn't compile on Expo SDK 57

The documented snippet calls:

factory.superView(
  withModuleName: moduleName,
  initialProperties: initialProperties,
  launchOptions: nil
)

which on SDK 57 fails with:

error: missing arguments for parameters 'bundleConfiguration', 'devMenuConfiguration' in call

superViewWithModuleName: gained two parameters (EXReactRootViewFactory.h:28-32), and Expo's own caller supplies them (ExpoReactNativeFactory.swift:166-172):

let bundleConfiguration = ExpoBundleConfiguration.configuration(
  bundleURL: withBundleURL ?? configuration?.bundleURLBlock()
)
rootView = factory.superView(
  withModuleName: …, initialProperties: …, launchOptions: …,
  bundleConfiguration: bundleConfiguration,
  devMenuConfiguration: self.devMenuConfiguration
)

Smaller snag in the same snippet: Expo's generated AppDelegate declares var reactNativeFactory: RCTReactNativeFactory? (base type) while assigning an ExpoReactNativeFactory, so reaching Expo-specific members needs a downcast.

Question: what is the intended implementation on SDK 57? We currently delegate to Expo's public recreateRootView(withBundleURL:moduleName:initialProps:launchOptions:), which assembles both arguments internally and calls the same superView — but see the last section, because we may be handing back the wrong type.

2. WindowApplicationSceneDelegate silently blanks the phone on Expo

WindowApplicationSceneDelegate.swift:24-26:

guard let rootViewController = UIApplication.shared.delegate?.window??.rootViewController
else { return }

Against Expo's generated AppDelegate.swift this returns nil. The template declares var window: UIWindow? as plain Swift, and Swift 4+ does not infer @objc, so the UIApplicationDelegate.window selector lookup finds nothing. The guard returns silently, no window is made key and visible, and the phone is blank from the first frame with no error anywhere.

We hit exactly this in our own scene delegate last week; our fix was casting to the concrete AppDelegate type in the same module instead of going through the protocol. That's Expo-specific so it may not suit a general library, but a loud NSLog on that guard would save the next person a day.

3. NitroSurface.stop: logs "not recognized type" unconditionally

if ([view isKindOfClass:[RCTSurfaceHostingView class]]) {
    …
    [rootView.surface stop];
}

NSLog(@"[AutoPlay] View is not recognized type, ignoring");

The log sits outside the if, so it fires on the success path too. We treated it as the smoking gun for our problem before reading the source. Moving it into an else would make it mean what it says.

What we're actually stuck on

CarPlay shows our app icon; tapping it opens an empty surface and the scene tears down a few seconds later. From a device log archive we have confirmed:

• no crash;
• CPTemplateApplicationScene is created and carkit authenticates the session;
• your code runs — NitroSurface.stop executes on teardown, so HeadUnitSceneDelegate and AutoPlayScene are live;
• our MapTemplate is constructed with a component, and setRootTemplate() is called from the didConnect listener — also guarded by isConnected() at registration, since our app's startup is long enough that the event can otherwise land before the listener attaches.

So the gap is between scene-connect and a rendered surface, and neither side logs there.

Is there a known-good Expo SDK 57 integration? Given that NitroSurface checks specifically for RCTSurfaceHostingView, if the answer to §1 is "it must return that exact class", that would likely resolve this immediately — and would explain why recreateRootView isn't equivalent even though it calls the same superView internally.

Happy to contribute an Expo section to the README, or a PR for §2 and §3, once we have a working integration.

[spendres]

Resolved — and the cause was on our side, not yours. Posting the details because two of them are still worth fixing in the library, and the third will bite any Expo app.

It was our own splash screen. The "large app icon where the map should be" was expo-splash-screen (a 200px icon on #232323), not a CarPlay placeholder. It mounts as a full-size opaque UIView above RCTSurfaceView in the root view you get from getRootViewForAutoplay, and it is only hidden by whichever JS root owns it — so when the app is launched for the CarPlay scene, it can cover the car surface indefinitely while every log line reports success.

Proven by removal. Native probe on the root view, before and after calling SplashScreen.hideAsync() from the component rendered by MapTemplate:

before:  subviews=2   [0] RCTSurfaceView   [1] UIView (full-size, opaque, on top)
after:   subviews=1   [0] RCTSurfaceView
                        [0.0] RCTRootComponentView frame=(0,0,459,240)

With that one call, the Google Navigation SDK's NavigationView renders correctly on the head unit at 459x240@2 with our own React overlay composited on top. So yes — @googlemaps/react-native-navigation-sdk and this library do compose. Happy to write that up as a README section if useful.

Two things from the original post still stand, and a third I would now rank higher:

1. The getRootViewForAutoplay snippet does not compile on Expo SDK 57 (superView gained bundleConfiguration:/devMenuConfiguration:). Our working version delegates to Expo's public recreateRootView(withBundleURL:moduleName:initialProps:launchOptions:), which assembles both internally, with a downcast because the generated property is typed as the base RCTReactNativeFactory.

2. WindowApplicationSceneDelegate silently blanks the phone on Expo — UIApplication.shared.delegate?.window?? returns nil against Expo's generated AppDelegate.swift, and the guard returns quietly. We kept our own phone scene delegate (concrete downcast) alongside your HeadUnitSceneDelegate, and the two coexist fine since AutoPlayScene only touches SceneStore.

3. NitroSurface.stop: logs "View is not recognized type, ignoring" unconditionally — it is outside the if, so it fires on the success path. During debugging we read it as the smoking gun and lost real time to it. Moving it into an else would help a lot.

One more that may be worth a line in the docs regardless of the above: an app whose startup is non-trivial can miss didConnect entirely. Tapping the CarPlay icon launches the app for the scene, and ours (expo-router + providers + auth) was still booting when the event fired. We register before expo-router/entry using require rather than import so ordering actually holds, and we consult isConnected() at registration. Worth noting that doing both needs a one-shot guard — otherwise isConnected() and didConnect each build a MapTemplate for a single connect, and one root view gets deallocated.

Thanks for the library — the semantic maneuver types in particular are a much better design than building per-platform icon mapping ourselves.

[spendres]

Follow-up with a production report: the integration shipped. One JS codebase now drives guidance on BOTH CarPlay and Android Auto in our app — Google Nav SDK session on the phone, its nav info mapped in TypeScript onto your startNavigation/updateManeuvers/updateTravelEstimates, glyphs via setIconFont with Material Symbols. Road-verified over several drives (turn cards, ETA, teardown, second trips, locked-phone operation — all clean). Thanks for the library; the semantic maneuver model and the ≤2-tuple update API held up exactly as documented.

Two findings that may help other integrators (or the docs):

1. Android: fragment-based RN views cannot be hosted on the car surface. Google's react-native-navigation-sdk NavigationView commits a Fragment into the Activity's FragmentManager keyed by the React view tag — mounted inside your virtual-display root it crashes on the next activity lifecycle transition (No view found for id … NavViewFragment). Not your bug, but a composition limit worth a README note: any RN library that mounts Android Fragments won't survive on the MapTemplate surface.

2. DX suggestion: nitro variant-conversion errors don't name the offending field. Cannot convert \"[object Object]\" to any type in variant<…NitroRoutingManeuver…> cost us two long debugging sessions — the causes were an undefined inside travelEstimates.distanceRemaining.value and an undefined attributedInstructionVariants[].text (both from upstream data gaps on our side). If the conversion error could name the first failing property path, these would be one-glance fixes.

Happy to expand either into a proper issue/PR if useful.

[spendres]

Follow-up on the Android composition limit above: we built the Android counterpart of the iOS getRootViewForAutoplay hook — a host-provided native View rendered under the React surface of the root display (NativeBackdrop + NativeBackdropRegistry, per-presentation lifecycle, day/night forwarded from onCarConfigurationChanged). It lets a Fragment-free native map (in our case the Google Navigation SDK's NavigationViewForAuto) sit beneath the React overlay on Android Auto; DHU-verified on a debuggable build. Proposed as #120.

[raffiot]

Hey @spendres thank you so much for posting & sharing your findings here! I'll try to make the same integration Google's react-native-navigation-sdk + Expo + react-native-auto-play so thank you!

[spendres]

Hope it helps to narrow the issues @raffiot.