Release readiness
React Native Nitro Geolocation 2.0 is currently a release candidate. Use it to integrate and validate 2.0 contracts, but treat production approval as your application team's decision after testing the exact devices and features you ship. The project does not provide an SLA or guarantee that an RC is free of contract corrections before 2.0 stable.
RC policy
@rcis a moving npm tag for evaluation. Pin an exact RC in a lockfile used for QA or release approval.- A later RC can include breaking corrections when they are required to make the stable 2.0 contract coherent. Review the package changelog before updating.
- Stable 1.x documentation remains at the unversioned site. 2.0 RC documentation
is under
/v2/. - Keep a known-good 1.x release branch and lockfile until the 2.0 upgrade and release gates pass in your application.
- There is no date-based GA promise. The project will mark 2.0 stable after the public contracts are frozen, release builds and consumer contracts pass on both native platforms, versioned docs match the package, and release prebuilts are validated.
Pin the repository's current reference combination:
Declared support
Declared support is the package contract, not a claim that every possible combination is continuously exercised.
Tested reference stack
The 2.0.0-rc.5 repository currently builds and runs its consumer contracts with this reference stack. This is evidence of the continuously exercised path, not the full peer range.
Reference last reviewed for 2.0.0-rc.5 on 2026-08-27. Consult the current
example package and E2E workflow if this page and the installed release differ.
Known limits
- Expo Go cannot load the native Nitro bindings.
- SwiftPM-only iOS is experimental on React Native 0.87.x and requires Nitro Modules 0.37.1 plus the documented app configuration helper.
- Browser builds support foreground geolocation only. The
/backgroundweb entry is import-safe but reports unsupported behavior. - Background delivery is best effort. Termination, reboot, iOS suspension, Android OEM restrictions, permission changes, and device settings affect what can be delivered. Read the reliability contract.
- Prebuilt fallback can turn an install into a source build. Validate both the selected artifact path and your CI's native build prerequisites.
- Geocoding and heading have platform/provider constraints; offline GPS does not imply offline geocoding. See the GPS/offline recipe.
- The library does not choose your battery/accuracy policy. Validate intervals, distance filters, accuracy, retention, and disclosure against the product use case and target devices.
Track newly reported release-candidate issues in GitHub Issues.
Ship checklist
- Exact Geolocation, Nitro Modules, React Native, and Expo versions are locked and recorded in release evidence.
-
nitro-geolocation doctorpasses after native project generation. - The app handles foreground grant, approximate/reduced grant, denial, restriction, settings changes, timeout, and provider unavailability.
- Current, cached, and watched positions are tested according to the product's freshness and accuracy rules.
- Every enabled background feature passes on physical devices and target OS versions; unsupported OS lifecycle claims are not shown to users.
- Background event recovery and server processing are idempotent.
- Only permissions required by enabled features are declared and requested at a user-understandable moment.
- Location retention, deletion, backup, sync, credentials, store disclosures, and incident handling pass the privacy review.
- Release-build consumer flows cover the product's critical path; use the consumer E2E contract kit as a baseline.
- Support reports can include the evidence in Troubleshooting without exposing precise user coordinates or credentials.
- A rollback build and any persistent-data compatibility strategy have been tested before rollout.
For 1.x applications, complete Upgrade from 1.x before using this checklist as the final release gate.
