MapLibre React Native is one wrapper per renderer, and the fork is the reason

A React Native binding over MapLibre Native, not a web map in a view

MapLibre React Native is described as a React Native library for creating maps with MapLibre Native for Android and iOS. That distinction is the whole technical story. The rendering is done by native code on the device, not by a WebView running a JavaScript map engine.

That has concrete consequences for how you build on it. Gestures, camera animation and tile rasterisation run on the platform's own rendering path, so the map is not competing with a JavaScript thread for frame budget, and there is no DOM involved. The cost is that the library is a bridge to a native renderer, so the set of features you can use is the set the underlying native SDK exposes, and you cannot patch behaviour with a JavaScript workaround.

The supported targets are Android and iOS, and the repository topics list android, expo, ios, react and react-native. The homepage is the MapLibre project site, and the documentation lives at maplibre.org/maplibre-react-native.

For an engineer, the practical question is whether the app is React Native in the first place. If it is not, this library does not apply, and the effort is better spent on the native MapLibre SDKs directly or on a web map embedded in a WebView.

The fork exists because Mapbox and MapLibre SDKs diverged

The README explains the project's origin in a way that tells you how to think about its API. It started as a fork of rnmapbox, a community maintained React Native library for building maps with the Mapbox iOS and Android mobile SDKs. The original library supported both Mapbox and MapLibre for some time, but as the two SDKs diverged, separating the projects into specific wrappers by underlying renderer became necessary.

So the fork is not a feature decision. It is a response to upstream divergence, and it explains the shape of the library. A wrapper tied to one renderer can track that renderer's releases and its breaking changes without having to support two of them at once, which is the standard argument for splitting a codebase when a shared dependency diverges.

The practical consequence for a migrating team is that the API you remember from rnmapbox may not be the API here, and the README does not enumerate the differences. The documentation site is the place to check the current surface, and the CHANGELOG.md in the repository is the record of what changed.

There is also a governance angle. The project sits inside the MapLibre organisation rather than being one person's fork, and the community channels named in the README are the MapLibre channels on the Open Street Map Slack.

A yarn workspaces monorepo, with the library in one package

The repository is a monorepo, and package.json says so directly. The name field is monorepo, the package is marked private, and the workspaces list names four entries.

  "workspaces": [
    "docs",
    "examples/*",
    "package",
    "scripts"
  ],

The library itself lives in the package/ workspace, whose published name is @maplibre/maplibre-react-native, with its entry point at package/src/index.ts. The docs workspace is the documentation site, scripts/ holds the tooling, and examples/* pulls in the example applications.

The examples are the interesting part of the workspace glob, because they are plural in a way that matters. The repository contains examples/expo-app/, examples/react-native-app/ and examples/shared/, so the same library is exercised against two different React Native setups, one Expo managed and one bare, with shared code factored out into the third workspace. For a library whose selling point is that it works in both worlds, having both examples in the tree is the closest thing to a test matrix.

The packageManager field pins [email protected], and there is a .yarnrc.yml and a .npmrc at the top level, so the repository expects a specific yarn setup rather than a generic node install.

Development runs through yarn workspaces and per-language formatters

The scripts section of package.json shows how the maintainers work, and it is a good map of what this project actually contains because the scripts name every sub project explicitly.

    "test": "yarn package test",
    "docs": "yarn workspace docs",
    "examples:expo": "yarn workspace expo-app",
    "examples:react-native": "yarn workspace react-native-app",
    "package": "yarn workspace @maplibre/maplibre-react-native",

Two of these lines are informative. The test script runs only in the package workspace, so the automated test suite lives with the library rather than with the examples. And the examples each have their own top level script, which means running an example is a single command from the root rather than a cd into a directory.

The formatting setup is the clearest evidence that this is a multi language codebase. The format script chains three separate formatters: prettier for TypeScript, JavaScript, JSON, Markdown, CSS and YAML, then clang-format through the package workspace, then ktlint. The last one is for Kotlin, which points to an Android side written in Kotlin, and clang-format points at the C and Objective C layers that the iOS build uses.

    "format": "yarn format:prettier && yarn package format:clang-format && yarn package format:ktlint",

The codegen script, yarn scripts codegen, is the other thing to know about. In a project with native bindings there is usually a generated layer between the JavaScript API and the native module, and a codegen entry point is where you would find it.

The README is a signpost, and the real documentation lives on the site

It is worth saying plainly that the README here is short. After the project description and the fork history, it points at the documentation, gives a contributing link, and names the community channels. There is no install snippet, no example component, no API list and no configuration reference in the repository's main README file.

For a library of this kind that is defensible, because the documentation site is the canonical place and duplicating it in the README guarantees drift. The cost is that the README alone will not tell you how to install the package, what a minimal map component looks like, or which props exist, and a new user has to leave the repository to find that out.

What the repository does contain in the way of guidance: a CONTRIBUTING.md that the README tells you to read before setting up a local development environment, a CODE_OF_CONDUCT.md, an AGENTS.md at the top level, and a CHANGELOG.md. The docs/ workspace is the source for the site, so the documentation is versioned with the code rather than living in a separate repository.

The release workflow is visible in the repository too, in the badge that points at a release.yml GitHub Actions workflow on the main branch.

MIT licensed, releasing often, and pinned to the native SDK

The licence is MIT, stated in the badge and recorded in LICENSE.md at the top of the repository. That is the permissive end of the spectrum and it is what you would expect for a library intended to be embedded in commercial apps.

On maintenance, the repository is not archived and the last push was on 2026-10-15. The releases are frequent and the version numbers tell you there is a long history behind them: v11.5.0 on 2026-10-04, v11.4.1 on 2026-10-01 and v11.4.0 on 2026-09-19. Two releases ten days apart and a patch in between is the pattern of a project that ships as the underlying SDK ships, not one that batches changes on its own schedule.

That is also the upgrade cost to plan for. Because the wrapper is tied to one underlying renderer, a new MapLibre Native release can pull a new wrapper release along with it, and the wrapper's own major version bumps when the native layer changes in a breaking way. The CHANGELOG.md is the file to read before bumping, since it is the only record of what changed on the JavaScript side.

The npm package name is fixed by the workspace configuration, @maplibre/maplibre-react-native, and that is the identifier you put in your dependency list.

What this library is the wrong choice for

Three boundaries are worth naming before you invest time in it.

First, platform. This is a React Native binding for Android and iOS. A web application gets nothing from it, and a native Android or iOS application should use the MapLibre Native SDKs directly rather than adding a React Native runtime to reach them.

Second, feature parity with the original library. Because rnmapbox served both Mapbox and MapLibre for a while, it carried Mapbox specific capabilities, and splitting by renderer means the Mapbox specific parts do not come along. Any feature you remember from that library should be checked against the current API rather than assumed.

Third, the maintenance surface. A React Native library that binds to a native renderer on two platforms carries a native build step, a codegen step and a per platform formatting and lint setup, so the integration cost is higher than a pure JavaScript component. If your map is a static image or a simple embedded web view, none of that is justified.

The library is at its best in the case it was built for: an existing React Native or Expo application that needs interactive vector tiles on device without a commercial map SDK in the dependency tree.

Editorial conclusion

Adopt MapLibre React Native if your team ships a React Native or Expo app, needs interactive vector tile maps on device, and wants a renderer with no commercial SDK dependency. Do not adopt it for a web map, a bare native Android or iOS app, or a project that needs the Mapbox features the original library carried. Before you start, read the documentation site rather than the README, since the README points there for all API detail, check that the released version of @maplibre/maplibre-react-native matches the MapLibre Native build you intend to bundle, and confirm the examples under examples/expo-app and examples/react-native-app run against your Expo version.

Frequently asked questions

Official sources

1. License: MIT
2. maplibre/maplibre-react-native on GitHub
3. Project website
4. README
5. Releases