Cohen says the release process had not kept pace with React Native’s development. With only two releases a year, each version accumulated six months of changes, bugs, and breaking changes. Unclear rules for late fixes led to repeated release candidates, with some versions taking six or nine RCs to stabilize.
React Native Releases in 2025: Towards a Stable Future
Speaker
Jorge Cohen, a software engineering manager on Meta’s React team, discusses React Native’s 2025 release process at React Universe Conf 2025, presented by Callstack.
The team moved from two releases a year to a target of six, one every two months. Changes must now meet clear acceptance criteria, with a bot explaining the rules when someone proposes a release change. Feature flags let the team disable a troubled feature instead of rushing a fix.
After accidentally publishing version 1000 to npm, the team rebuilt its CI around GitHub Actions and automated more release steps. A bot helps merge changes, pick fixes, and manage tasks. Cohen says release crew work fell from two days per release candidate to two hours.
The team runs end-to-end Maestro tests on RNTester for every commit, so it can catch problems before release. Its React Native Nightly Testing Program checks ecosystem libraries against nightly builds, with a public dashboard showing compatibility. The initial library criteria include active maintenance, at least 100 stars, 50,000 downloads, and native code.
Cohen says React Native supports the latest three releases, giving teams a six-month upgrade window. He points to recent improvements across versions 0.76 through 0.81 and encourages teams to avoid falling behind. Predictable releases, stable APIs, and fewer breaking changes are part of the work toward 1.0.
Takeaways
- Shorter release intervals can reduce the amount of change teams must absorb in each upgrade.
- Set explicit criteria for release fixes to avoid late debates blocking a ship date.
- Use feature flags to disable risky changes when a release deadline is near.
- Run end-to-end checks on every commit to find regressions earlier.
- Test nightly builds against actively maintained ecosystem libraries to catch compatibility problems before release.
Mentioned in this talk
Search inside this talk
What was claimed 11
- role atJorge Cohen is software engineering manager on the React team at
Meta
“I'm a software engineering manager on the React team at Meta”
YouTube Unverified1 source· Talk
- metricReact Native: Six releases a year in 2025, one every two months
“Six releases a year. That's our goal for 2025. We're going to do one every two months”
YouTube Unverified1 source· Talk
- featureReact Native release process: Releases are scheduled every two months and are on time, less manual, and tested early
“releases have to be on time, less manual, and tested early”
YouTube Unverified1 source· Talk
- uses
“We also started relying more heavily on feature flags”
YouTube Unverified1 source· Talk
- uses
“We rebuilt our entire CI around GitHub Actions”
YouTube Unverified1 source· Talk
- metricReact Native release process: Release crew time dropped from two days per release candidate to two hours
“the time spent by the release crew dropped from two days per RC to two hours”
YouTube Unverified1 source· Talk
- uses
“we now run full end-to-end Maestro tests”
YouTube Unverified1 source· Talk
- uses
“we now run full end-to-end Maestro tests”
YouTube Unverified1 source· Talk







