gmi-software/react-native-better-maps

Problem Both iOS overlay controllers commit "these markers are on the map" before checking that there is a map to put them on — the same write-before-check shape as #127 on Android. MapOverlayController.setMarkers (ios/MapOverlayController.swift:61): func setMarkers(_ descriptors: [MarkerDescriptor]?) { guard markerPipeline.setMarkers(descriptors) else { return } // records the fingerprint reapplyMarkers() // `guard let mapView else { return }` } MarkerRenderPipeline.setMarkers (ios/MarkerClusterEngine.swift:402–413) writes markersFingerprint = fingerprint at :409 and returns true; reapplyMarkers (MapOverlayController.swift:68) then gives up at guard let mapView. With no map view the pipeline believes that descriptor set is applied while nothing was drawn, and because the next delivery of the same array early-returns on the matching fingerprint, there is no recovery — exactly the mechanism described in #127. GoogleMapOverlayCont

Problem GoogleMapProviderAdapter keeps four fields for overlays that arrive before the Google map is ready — pendingMarkers, pendingPolylines, pendingPolygons, pendingCircles (GoogleMapProviderAdapter.kt:36–39). None of them can ever hold anything the adapter does not already have. Every one of the four setters assigns the backing field before it branches, so the else branch stores a second copy of what was just written (:251–298): private var _markers: Array<MarkerDescriptor>? = null override var markers: Array<MarkerDescriptor>? get() = _markers set(value) { _markers = value // :255 — always if (googleMap != null) { updateOverlayViewportSize() overlayController.setMarkers(value) } else { pendingMarkers = value // :260 — the same value that is already in _markers } } The other three are identical in shape (:264–274, :276–286, :288–298). So at every point in the adapter's life pendingX is either null or the very same

Problem resolveOverlayId falls back to the child's position in the children list (package/src/overlays/overlayCollect.ts:32-42): export function resolveOverlayId(providedId: string | undefined, type: string, index: number): string { if (providedId != null && providedId.length > 0) return providedId; return `${type}-${index}`; // marker-0, marker-1, polyline-0, geojson-0, ... } It is used for every JSX overlay — useCollectedOverlays.ts:76 (marker), :111 (polyline), :134 (polygon), :158 (circle), and collectGeojsonOverlays.ts:81 (geojson layer). The React key is never consulted. useCollectedOverlays.ts:209-224 walks children with Children.forEach and hands the element to the collector, which only reads child.props; child.key is not read anywhere in package/src. It is available at that point — verified against React 19.2.3, Children.forEach yields elements whose key is the string the consumer passed, for arrays from .map(), single-element arrays and lone children alike. That i

Problem onPoiPress gives a placeId on the Google provider and nothing identifying on Apple. AppleMapProviderAdapter.notifyPoiPress sets placeId: nil (package/ios/AppleMapProviderAdapter.swift:360-372), because MKMapFeatureAnnotation exposes no stable public identifier. Since the default provider is apple on iOS and google on Android (package/src/providers.ts:4-20), the same <MapView onPoiPress={...} /> gives: Platform (no provider prop) Payload iOS { provider: 'apple', coordinate, name?, category, rawCategory? } Android { provider: 'google', coordinate, name, placeId } The types are honest about this — PoiPressEvent is a discriminated union keyed on provider (package/src/types/map.ts:24-39), so TypeScript forces narrowing before placeId can be read, and the README documents the three payload shapes (README.md:307-311). What is missing is the consequence, which is what anyone building "tap a POI → look it up" hits: on Apple there is no identifier to look anything up with

Problem Both platforms gate onRegionChange / onRegionChangeComplete on a user-gesture flag, so setCamera, animateCamera, fitToCoordinates and the region / camera props emit nothing at all. iOS — package/ios/AppleMapProviderAdapter.swift:287-308: func handleRegionWillChange(userInteracting: Bool) { startLiveClustering() guard userInteracting, !isUserRegionChange else { return } // <- programmatic: returns isUserRegionChange = true emitRegionChange(complete: false) } func handleRegionDidChange() { stopLiveClustering() guard isUserRegionChange else { return } // <- programmatic: returns ... } MKMapViewDelegate does call both for programmatic region and camera changes (package/ios/HybridMapViewDelegate.swift:82-88), but mapView.isUserInteracting is false, so both guards drop the event. Android — GoogleMapProviderAdapter.kt:430-441 and :712-724: map.setOnCameraMoveStartedListener { reason -> handleRegionWillChange( userInteracting = reason == G