skip to content

How often does React Native release a new minor version, which versions are supported, and what does unsupported mean for your app?

level: juniorimportance: should knowfreq 36%

answer

  1. 0.x.y: minors carry breaking changes
  2. a minor roughly every two months
  3. latest three minor series maintained
  4. Active, End of Cycle, Unsupported
  5. 0.87 out, 0.84 unsupported

basics

~20 s

React Native ships a new minor, which may contain breaking changes, roughly every two months and maintains only the latest three minor series. When 0.87 shipped, 0.84 became unsupported: it gets no further patches, even for bugs that affect you.

solid answer

~40 s

React Native uses **0.x.y** versioning: new features and breaking changes land in a new minor (`0.86` to `0.87`), and patches (`0.87.0` to `0.87.1`) carry critical fixes. Minors have shipped roughly every two months. The project commits to maintaining the **latest three minor series**: when 0.87 became latest stable, 0.87 and 0.86 were Active, 0.85 moved to End of Cycle with fewer patches, and 0.84 became **Unsupported**. Unsupported means no new releases except for rare, very important regressions, so a crash fix or a new store requirement may never reach your version. An app that stops upgrading drifts out of the window within about half a year.

go deeper

for a junior

Recall the numbers: a new minor about every two months, the latest three series maintained, and 0.x versioning where minors can break.

for a middle

Explain the Active, End of Cycle and Unsupported stages, what counts as a breaking change, and how the deprecation cycle spans minors.

for a senior

Show what falling out of support costs in practice: no backported fixes, libraries dropping old versions, store requirements that force a rushed upgrade.

for a principal

Turn the cadence into a policy: how many releases behind the team may fall before an upgrade is scheduled, and who owns it.

## Versioning: why every minor matters React Native has never had a 1.0 release. It follows a **0.x.y** scheme described in its versioning policy: - **Minor** bumps (`0.86` to `0.87`) carry **new features and breaking changes**. - **Patch** bumps (`0.87.0` to `0.87.1`) carry **critical bug fixes**. - A **minor series** is all releases under one minor, for example 0.87.0, 0.87.1 and so on. So in React Native a minor upgrade is what a major upgrade is in most semver projects. The policy spells out what counts as breaking: an incompatible API change, a significant runtime or layout behaviour change, removing a development feature, a major bump of a transitive dependency such as React, or raising a supported platform minimum such as the minimum iOS version or Android SDK. ## Cadence Releases follow a published schedule. In 2025 and 2026 a new minor has shipped roughly **every two months**, with a branch cut and release candidates about five weeks before each release: | Version | Released | Support status after 0.87 | |---|---|---| | 0.87 | August 2026 | Active | | 0.86 | June 2026 | Active | | 0.85 | April 2026 | End of Cycle | | 0.84 | February 2026 | Unsupported | Release candidates are published under the npm `next` tag and nightlies under `nightly`; apps use `latest`. ## The support window The React Native team commits to maintaining the **latest three minor series**. The release pages define four levels: 1. **Future**: a branch has been cut; release candidates are published for testing. 2. **Active**: stable and receiving frequent patches; the newest one has the highest priority. 3. **End of Cycle**: fewer patches, mainly important regressions, plus one last patch before it becomes unsupported. 4. **Unsupported**: no new releases are expected; only very important regressions may be exceptions, and the docs recommend upgrading as soon as possible. Every release post states the shift, for example "0.87 is now the latest stable version of React Native and 0.84.x moves to unsupported". ## What unsupported means for an app Being unsupported does not make an app stop working. It changes who carries the risk: - a crash or security fix in React Native is **not** backported to your version; - a new app-store or OS requirement, such as a higher Android target SDK, may only be met by a newer React Native; - library authors test against current versions, so new library releases may **drop** your version; - each release you skip adds another set of breaking changes to cross later. ## Deprecations and the window The same policy sets a **deprecation cycle**: an API deprecated in one minor stays available in the **next** minor and is removed no sooner than the one after. For example, `StyleSheet.absoluteFillObject` was deprecated in 0.82 and removed in 0.85. Staying within the support window means you meet deprecation warnings while the API still works, instead of discovering the removal as a build error. ## In the interview A good answer names the numbers, a minor about every two months and three supported series, and then draws the consequence: an app has roughly six months from a release before it falls out of support, so upgrades belong on the roadmap as routine work. ## Reading a release post efficiently Every stable release has a post on the React Native blog with a predictable shape, and knowing it saves time during an upgrade: - **Highlights** describe new capabilities, useful but rarely urgent; - **Breaking Changes** list what can stop your app compiling or behaving the same, often grouped as toolchain minimums, API removals, and packages and tooling; - **Deprecations** name what will be removed later, which is your to-do list for the next upgrade; - **Upgrade** points at the Upgrade Helper and states which series has just become unsupported. The changelog in the React Native repository carries the same information per commit, with Breaking and Removed sections, for when a post's summary is not enough.

  • In React Native's versioning, why is 0.86 to 0.87 treated like a major upgrade?
    Because React Native stays on 0.x, its policy ships breaking changes and new features in minor bumps, and only critical fixes in patches. A minor can therefore remove APIs, raise toolchain minimums or change behaviour, which in a semver 1.x project would need a major version.
  • What happens between a React Native branch cut and the stable release?
    The release enters the Future stage: release candidates such as `0.88.0-rc.0` are published under the npm `next` tag for the community and library authors to test, and fixes are picked into the branch before the stable `.0` ships as `latest`.

saying these in an interview costs you the question

  • React Native follows semver, so minor upgrades are always safe
  • Every React Native release is supported for several years
  • An unsupported React Native version stops working on devices
  • Release candidates under the next tag are fine for production