AdminConsole
Tutorials/Intermediate
Intermediate45 minReact Native

Build a cross-platform React Native map

Install the native wrapper, configure both platforms, add annotations, and handle cleanup.

By the endOne map experience across Android and iOS.
Real-world scenario

Build against an explicit contract

A React Native product needs one map feature across Android and iOS without hiding native lifecycle, permissions, or packaging differences.

A Mappls developer projectA restricted React Native applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A React Native product needs one map feature across Android and iOS without hiding native lifecycle, permissions, or packaging differences. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Configure both native projects

Install the documented wrapper and peer versions, apply Android package/signing and iOS bundle restrictions, and keep platform setup changes reviewable.

Maps · SDK or product slice
<!doctype html>
<html>
  <head>
    <script src="https://sdk.mappls.com/map/sdk/web?v=3.0&access_token=YOUR_STATIC_KEY"></script>
    <style>html, body, #map { height: 100%; margin: 0; }</style>
  </head>
  <body>
    <div id="map"></div>
    <script>
      const map = new mappls.Map("map", {
        center: { lat: 28.612964, lng: 77.229463 },
        zoom: 12
      });
    </script>
  </body>
</html>
Step 3

Design a stable JavaScript boundary

Pass serializable camera/features, use stable IDs, avoid high-frequency bridge chatter, and unsubscribe callbacks on unmount.

Step 4

Test native divergence

Exercise permission, background/foreground, rotation, memory pressure, architecture, and release builds independently on both platforms.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when android and ios select the same feature identity; unmount releases native listeners; release builds work with restricted credentials. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

wrapper/native version skew

Fail fast with a typed, user-safe outcome and preserve the original request identity.

bridge receives events after unmount

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

one platform denies location permission

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

Android and iOS select the same feature identityunmount releases native listenersrelease builds work with restricted credentials

React Native production checks

Native and wrapper releases are compatibleHigh-frequency events are throttled before crossing the bridgeUnmount releases native views and listenersPlatform-specific behavior is documented, not hidden
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.