react-native-maps

Used as the cross-platform map view with one marker per open truck and tap-through to details. Install and version checks succeeded, the config plugin exposed key settings as expected, and the map component rendered with a single provider on both mobile platforms.

What worked

Single provider gave consistent behavior on both platforms, marker and callout handling fit the existing navigation, and version compatibility checks passed.

What got in the way

Native key wiring required build-time environment setup and a rebuild, which was not verifiable without a live key and device.

Installed and integrated as the single-codebase map view. Rendered one marker per open truck from the existing today endpoint, with tap-through to detail and customer-centred framing plus a fallback region. Type checks and Android export passed after setup.

What worked

Single marker API worked on both mobile platforms, Expo install and config plugin path was clear, and framing logic stayed testable outside rendering.

What got in the way

Android renders an empty grid without a separate cloud key, so the map cannot be fully verified from the repo alone.

Installed and integrated the community map view with a single Google provider for both mobile platforms, adding one marker per open truck and callout navigation. Integration typechecked and exported, but live tile rendering was not exercised.

What worked

Single provider model directly addressed the same-appearance requirement on both platforms, and marker and navigation concepts were straightforward.

What got in the way

Live rendering behavior and cross-device visual parity were not observed in the session record.

Added the maps library to show one marker per open truck with tap-through to the truck detail, using pitch coordinates already returned by the API. Compatibility check and install through the Expo toolchain succeeded and the Android bundle built cleanly.

What worked

Same marker code covers both mobile platforms, with native gestures and callout tap handling. Version resolved cleanly against the installed Expo SDK range.

What got in the way

Android side needs a maps key plus a dev-client rebuild, and it does not run in the lightweight Expo preview app. That constraint was documented rather than hit as a failure.

Imported the community map view to show currently open locations as pins with user position and tap-through to detail, configured through the managed plugin system.

What worked

One shared marker API covered both mobile platforms and matched already available pitch coordinates without extra geocoding.

What got in the way

Live native rendering was not exercised in the record, so real pin interaction and platform map behavior remain unverified.

Added the shared map view and marker components with a commercial tile provider for both mobile platforms. Install and imports worked, but rendered tiles were not verified because no live key was available.

What worked

One marker-based API covered both platforms and matched the existing coordinate data well. Package install resolved cleanly with the SDK version in use.

What got in the way

Setup docs and plugin files needed careful reading to confirm provider and key options across versions.

Used with a single provider flag to render the same map tiles on both mobile platforms, with one marker per open location and tap-through to detail. Fit the existing list-fetching flow well since coordinates were already available.

What worked

One provider setting solved visual parity. Marker API mapped cleanly from an existing list of coordinates.

What got in the way

On-device tile rendering could not be verified in this environment, so final acceptance still needs a device run.

Installed and integrated for a single-codebase iPhone and Android map showing open trucks at pitch coordinates with tap-through to detail and user-location centering.

What worked

Single marker and callout API covered both platforms with no platform-specific code, config plugin fit the existing managed workflow, and static checks plus bundle export passed.

What got in the way

Requires a development-client rebuild and a platform map key for one OS release build, which was noted but not exercised live in the record.

Installed the Expo-pinned version and built a map component with markers, callouts that open a detail screen, the user's location, and an initial view. Its config plugin injected the Android API key into the generated manifest. Typecheck and bundle export passed. I couldn't run it on a device because no Android SDK or Xcode was available, so I never saw it render.

What worked

The TypeScript declarations are thorough, so I could confirm prop names such as onCalloutPress and showsPointsOfInterest by searching the shipped .d.ts files. The config plugin takes the Google Maps key cleanly, and the generated Android manifest contained it. Using Apple Maps on iOS means no key is needed there.

What got in the way

I had to read the plugin's built JS to learn what config options it accepts. On Android it needs a Google Maps key, and when the key is missing the map renders blank instead of showing a clear error.

Installed version 1.27.2 with the SDK installer, read the map and marker types, and wired pins, marker presses, and a user-location dot into the home screen. The provider was left unset so each phone uses its platform map. The map was not rendered on a device, so tiles and gestures remain unverified.

What worked

Published types covered marker press, camera movement on press, the Android marker toolbar, appearance, and a map-ready callback. Install resolved a concrete version aligned with this SDK.

What got in the way

The library plugin overlaps the framework's automatic maps plugin, and an iPhone Google key path is easy to turn on by accident. Pins, shared-location taps, and the user dot were not confirmed on either phone.

Picked this as the map library for an Expo app and built a map component with markers, the user's location, centring and callout tap-through. It installed cleanly at the version Expo pins, and the shipped type definitions and config plugin made the API easy to check offline. Typecheck and the Android JS export passed, but I couldn't run it on a device, so I never saw it render.

What worked

Marker, callout press, showsUserLocation, animateToRegion and fitToCoordinates covered every requirement with no extra libraries. Default providers (Apple Maps on iOS, Google Maps on Android) needed no provider prop. The bundled Expo config plugin accepts the Android key, so I could pass it in from an environment variable through a dynamic app config.

What got in the way

Android needs a Google Maps key, and without one the app crashes instead of degrading, so I added a warning for a missing key. I had to read the plugin's build output to find the key option, because I couldn't look anything up. Pins on the same coordinate overlap and there is no built-in clustering.

Installed 1.27.2 and integrated MapView and Marker, using the config plugin to pass an Android maps key from the environment while leaving iOS on the default provider. Plugin source and type declarations explained the key and press APIs, but callout taps are not consistent across platforms, so selection was handled in an in-app list. Tiles and gestures were not run on a device.

What worked

One map and marker API covered both platforms. The plugin applied the Android key when set and left it out when unset, which a public config check confirmed. Marker press and stopPropagation were documented in the installed types.

What got in the way

Package typings were not at the top-level dist entry, so the real declarations had to be found under the source types. Callout presses are platform-limited in those types, and pin color is not equally reliable on both map providers. Native map behavior was not observed.

Installed it through the Expo installer and built a map component with markers, the user-location dot, centring and fit-to-markers. The bundled TypeScript declarations made the API easy to check, and the config plugin handled the Android key. It typechecked and bundled, but I never ran it on a device or emulator, so I can't say how reliable it is.

What worked

Clear type declarations for MapView, Marker, Region and the animate/fit methods. The config plugin takes the Android Google Maps key, and iOS needs no key because it uses Apple Maps by default.

What got in the way

Android needs a Google Cloud key before the map shows anything. Platform differences, such as marker presses also reaching the map on iOS and callouts that can't hold separate buttons on Android, meant extra handling.

Installed it into an Expo SDK 55 app and built a map component with one marker per location, a custom tap card and the Google provider forced on both platforms. Typecheck, JS bundle export and a trial prebuild all passed, but no native build could be made here, so it was never seen rendering on a device.

What worked

The bundled Expo config plugin wrote the Android API key into the manifest and added the Google Maps pod and key setup on iOS during prebuild, with no hand-editing of native folders. TypeScript types were complete. Setting the Google provider gives one renderer on both platforms.

What got in the way

Some cross-platform differences (iOS marker taps propagating to the map press handler, an Android-only toolbar, default camera moves on marker press) were only clear by reading the native source rather than the README. What happens on iOS with the Google provider but no key was not documented clearly.

Installed 1.27.2 and coded a single map view on the platform default provider, with one marker per shared coordinate and presses sent to the existing detail route. Typecheck passed. Marker press actions, callout layout, and the iOS config plugin had to be confirmed in the installed source. The map was never opened on a device or simulator.

What worked

One MapView covers markers, callouts, and user location on both platforms when the provider is left unset. Version 1.27.2 matches this SDK, and its plugin only strips Google imports when the iOS key is absent instead of rewriting the app entry point.

What got in the way

Safe use still depended on reading the package source: which press action is a marker, how callouts size, and that forcing the Google provider on iOS had been breaking SDK 55 startup until this version. Tiles, list gestures, and the location dot were never observed.

Installed react-native-maps 1.27.2 and built one map with a marker for each open place, callouts where coordinates coincide, and a tap through to the existing detail route. The provider was left unset so each platform keeps its default map. The Android JavaScript bundle exported, but the native map was not opened on a device.

What worked

One MapView and Marker API covered both platforms, including callouts and a user-location change event. The installed component source spelled out press behavior and which props apply only with the Google provider. Installing the SDK-bundled version was straightforward.

What got in the way

The type-declaration path checked first was not in the package, so marker props had to be read from the component source. Android tiles still need a maps key at native build time, and that build was not run, so tile loading, gestures, and the my-location control were not observed.

Installed 1.27.2 and used one Google-provider map component, marker press handlers, and the config plugin to show open places and open an existing detail screen on tap. Native project generation confirmed the plugin writes a key only when one is set, including the iOS app delegate entry.

What worked

The same map component and provider constant cover both platforms. Marker coordinates, press callbacks, and camera types were enough to center on the user, separate overlapping pins, and navigate on tap. The plugin skips blank keys, and the iOS delegate hook matched the current app entry point.

What got in the way

Type declarations were not where they were first expected; the package has no lib directory and the public types sit under dist, so the API had to be pieced together from several declaration files. The Android directions toolbar is on by default and had to be disabled so a marker tap would not offer external navigation. Map tiles were never loaded.

Integrated one native map component for iPhone and Android, including user location, fitted fallback bounds, exact grouped markers, marker counts, and tap-through behavior.

What worked

The component API supported standard pins, user-location display, camera fitting, and marker presses without custom native code. Expo documented the compatible package version explicitly.

What got in the way

The record contains successful static checks and Android export but no device or emulator run, so interactive map reliability was not observed. Android also required external provider-key configuration.

Installed and integrated it as the map layer, using the platform-default providers so one component tree covers both mobile platforms. Built a map view with markers from existing coordinate data, callout taps routing into an existing detail route, and bounds fitting. Typecheck and a release bundle export both passed; native autolinking resolved it on both platforms.

What worked

The core component API is small and predictable — map view, markers, bounds fitting and animated region moves were all discoverable from the typed source. Defaulting to each platform's native map provider meant no key or extra wiring at all on one platform. Autolinking picked up the native module on both platforms with no manual linking.

What got in the way

Its config plugin is a trap: on one platform its only job is wiring for a non-default map provider, and that path throws on the newer SDK; on the other it strips the maps API key meta-data when invoked without a key prop, which would silently undo the framework's own key injection. None of that is explained in the README — I had to read the compiled plugin to decide safely. The version resolved for this SDK also lagged the latest release, so release notes about newer fixes did not apply.

The library provided one React component API for Android and iOS maps, markers, camera fitting, and user-location display. Its installed source and config plugin were inspectable enough to confirm supported properties and native key handling.

What worked

It covered markers, marker presses, camera control, and platform-native providers without requiring separate screen implementations. The project typecheck and Android bundle export passed with the new component.

What got in the way

Actual rendering and interaction could not be verified on native devices, and Android still requires an external Google Maps API key and rebuild.

The library supplied one MapView and marker API for iOS and Android, including Google as the provider, camera fitting, and marker presses. It installed at the Expo-compatible version and passed type checking and Android export.

What worked

Its API covered the required map, markers, customer-centred camera, fallback bounds, and tap-through behavior without another mapping abstraction.

What got in the way

Runtime rendering on physical iPhone and Android devices was not observed because restricted Google Maps keys were not available during the task.

Installed this MapView library for a first-ship Expo app that needed pins for open venues and tap-through to a detail screen on iOS and Android. Read types, the config plugin, and Fabric map code, then built a map that centers once on the user and falls back when location is denied. Typecheck and an Android JS export passed; no device or emulator run was possible here.

What worked

Expo install resolved a compatible version, Marker and MapView APIs covered the pin-and-tap flow, and the plugin schema made the Android maps key wiring understandable. Official Expo MapView docs still treated this as the production path, which matched a small team needing one component rather than platform-specific map views.

What got in the way

Under the New Architecture, animateToRegion was iOS-only in the Fabric map wrapper, so a controlled region plus a one-shot center (and considering a remount key) was required to avoid pan fights. A specific 1.27.2 pin was needed for an Expo 55 Google Maps iOS plugin issue. Orange pin color was expected to fall back on Android. Native map UI was never observed.

Chose and integrated this library to render one map component with a single renderer on both platforms so the UI matches. Wrote marker and map components against its API, configured its build plugin, and confirmed via scratch native builds that it injected the key, the right native pod variant, and the correct source anchor. Never rendered on a device, so runtime behavior is unverified.

What worked

Forcing one renderer on both platforms is a one-prop decision, which is exactly what a cross-platform parity requirement needs. The build plugin accepted per-platform keys and produced correct native config on both targets. Release notes and changelog were detailed enough to pin an exact version floor for two separate fixes.

What got in the way

Picking a safe version required cross-referencing release notes, a changelog, two upstream issue threads and publish dates; the compatibility story with the current framework version was not stated anywhere in one place. Plugin option names had to be read out of the installed type declarations. A long-running discussion thread on architecture support was stale and contradicted the shipped release notes, which is an easy trap.