When React Native updates, what breaks is the build, not usually your screens.
React Native has no major version. It ships breaking changes in minor releases, about every two months, on a schedule it publishes with dates. So the thing that breaks is almost never a button you can see. It is the Node version the build needs, the Kotlin and Gradle versions on Android, a transitive dependency that moved, an API that was deprecated two releases ago and has now gone. Expo pairs each SDK version with one React Native version, which means the change does not reach you as a framework bump you chose. It reaches you through the Expo SDK release notes.
What follows is what React Native counts as breaking in its own words, how long a version keeps getting patches, how long an Expo SDK stays current, and the three facts about your repository that decide whether an upgrade is an afternoon or a fortnight. Every figure was read from React Native and Expo documentation on 17 October 2026. The dates matter here more than usual, because last year's version numbers are all wrong by now.
See what breaks firstThe short version
The framework moves on a schedule, and the schedule is published.
React Native uses a 0.x.y scheme. Breaking changes and new features both arrive by incrementing the middle number, and only critical bug fixes arrive in the last one. It commits to maintaining the latest three minor series, and prints the branch cut date, the release date and the current support level for each one. On 17 October 2026 that meant 0.87 and 0.86 in active support, 0.85 in its end of cycle, and 0.84, which shipped on 9 February 2026, already unsupported.
Expo sits on top of that and moves in larger steps. One Expo SDK version pins one React Native version, so you upgrade the SDK and the framework comes along. The two clocks do not agree, and that is the part worth knowing: Expo still lists SDK 55 among its current releases, SDK 55 ships React Native 0.83, and React Native marks 0.83 unsupported. Being inside Expo's window is not the same as being inside Meta's.
What actually breaks when React Native updates?
React Native publishes its own definition, which is more useful than any list of symptoms. A change is breaking if it is an incompatible API change in JavaScript, Java, Kotlin, Objective C or C++, meaning your code no longer compiles or runs. Or a significant behaviour or runtime change, with the layout logic of a prop changing as the example. Or a significant change in the development experience, such as a debugging feature being removed. Or a major bump of one of its transitive dependencies, and its own examples there are React 18 to React 19 and the Android target SDK moving from 34 to 35. Or a reduction in the platform versions it supports, such as raising the minimum Android or iOS version. Four of those five are things you never typed.
The same page lists what is deliberately not covered, and this is where generated code can surprise you. Anything with an unstable_ prefix can change at any time. So can anything private or internal, whatever its visibility. So can the APIs reserved for frameworks and tooling, parts of Metro and React Native DevTools among them, which change by agreement with the tool authors rather than by announcement. Development warnings can appear or change between any two versions. If your project leans on one of those, no promise covers you, and the release notes will not mention it.
One release makes it concrete. React Native 0.87, released on 10 August 2026, required Node 22.13.0 or newer, moved Android to Kotlin 2.0 and Android Gradle Plugin 9, raised the minimum compile target for libraries, and made the Strict TypeScript API the default, so deep imports into internal folders stopped resolving unless you opt back in. Not one of those is a feature you would describe to a customer, and all of them stop a build. The breaking changes for each release are collected in the Breaking and Removed sections of the changelog and in the Breaking Changes section of that release's notes, which are the two places worth reading before you change a version number.
Deprecations come with a short, specific promise. Once an API is deprecated it stays available in the following stable release, so something deprecated in 0.76 is still there in 0.77 and will not be removed sooner than 0.78. At roughly two months a release, that is about two months of warning, sometimes longer when the ecosystem needs it. A warning you have been scrolling past since the spring is a compile error by the autumn. If you have not yet run the project on your own machine, getting started with Expo covers the commands the rest of this page assumes.
React Native, Releases, schedule and versioning policy, read 17 October 2026
How long does a React Native version stay supported?
Three minor series at a time. React Native states the commitment plainly: to support users upgrading, it maintains the latest three minor series, and for those it publishes regular updates and bug fixes. The schedule page then sorts every release into four levels. Future, where a branch has been cut and release candidates are coming quickly. Active, where the version gets frequent patches and the newest stable gets them fastest. End of Cycle, where patches slow down and one final one is produced on the way out. And Unsupported, where no new releases are expected at all, apart from a very important regression, with the written advice being to upgrade as soon as possible.
Put the cadence and the window together and you get the number that actually governs your year. The published 2026 release dates are 9 February, 6 April, 9 June, 10 August and 12 October, with 0.89 planned for 7 December, and each stable release lands about five weeks after its branch is cut. That is roughly six breaking releases a year, three of them supported at any moment. So a version is patched for something like six to eight months after it ships. On the day this was written, the oldest supported series had shipped in April 2026 and the newest unsupported one in February 2026.
Treat the schedule as a plan rather than a fact. On 17 October 2026 the same table listed 0.88 with a release date of 12 October and still marked it Future, while the documentation version list still offered 0.87 as the latest. That is normal, and it is a good reason to check the schedule page itself when you need to know where you stand, rather than a number someone quoted in a thread six months ago.
Where each React Native release stood on 17 October 2026
| Minor series | Released | Support level | Still getting patches |
|---|---|---|---|
| 0.87.x | 10 August 2026 | Active | Yes |
| 0.86.x | 9 June 2026 | Active | Yes |
| 0.85.x | 6 April 2026 | End of Cycle | Fewer patches, one last one on the way out |
| 0.84.x | 9 February 2026 | Unsupported | No |
| 0.83.x | 10 December 2025 | Unsupported | No |
Dates and support levels from React Native's published release schedule, read on 17 October 2026. The bottom row, 0.83, is the version Expo SDK 55 ships, which is the clearest illustration of the two clocks: current on one side, unsupported on the other.
How long does an Expo SDK version stay supported?
Expo answers this differently, and you should know that before you plan around it. There is no end of support date for an SDK version in its upgrade documentation. What that page carries instead, last modified on 16 October 2026, is a list: release notes for SDK 55, 56, 57 and 58 under its current heading, and SDK 54 and everything older under a separate heading for deprecated SDK version changelogs. Four versions deep on the day it was read. The same page says that when a new SDK is released the latest version enters the current release status, that this applies to Expo Go because Expo Go supports only the latest SDK version and previous versions are no longer supported, and that development builds are the recommendation for production apps because backwards compatibility for older SDK versions on EAS services tends to be much longer, but not forever.
So you are tracking two clocks that run at different speeds. An SDK version can sit comfortably inside Expo's current list while the React Native version underneath it has stopped receiving patches. SDK 55, which Expo documents as using React Native 0.83, is exactly that case on 17 October 2026. Nothing is wrong with your project when this happens. It just means a React Native fix will not come to you until an SDK upgrade brings a newer minor, and that upgrading your SDK by one step can move your framework by more than one minor.
There is one boundary in this history that is not a judgement call, and it is the biggest thing to break in this generation of React Native. Expo documents that SDK 55 and later run entirely on the New Architecture, that it is always enabled and cannot be disabled, and that SDK 54 or earlier is the answer if you still need the legacy one. React Native 0.82 was the first version to remove the switch. Expo also records that the legacy architecture was frozen in June 2025, so it receives no new features and no bug fixes, and that as of January 2026 about 83 percent of SDK 54 projects built with EAS Build were already on the New Architecture. If anyone tells you the migration is optional, that is the paragraph to read back to them.
The practical reading of all this: the version you are on is a number in your package.json, and the clock started the day the project was created, not the day you first opened it. Pick a quarterly slot for the upgrade and it is routine. Discover it because a library you need no longer publishes for your version, and you are doing an upgrade and a feature at the same time, which is the worst week to be publishing to the App Store.
Expo, React Native's New Architecture, last modified 16 October 2026, read 17 October 2026
Do you have to do anything about it?
Three facts about your repository decide the cost, and you can check all three in ten minutes. The first is whether the ios and android folders are committed. Expo generates those from a template tied to the SDK version you have installed, a system it calls Continuous Native Generation, and a new Expo project has both folders in its ignore file. If they are absent, EAS Build generates them before compiling, so the native half of an upgrade arrives for free. If they are present, EAS Build deliberately does not generate them, to avoid overwriting work you did in there, and every native change in a new template is yours to apply by hand. Expo's own summary of the good case is short: upgrade the npm dependencies, update the app config, run prebuild again with the clean option.
The second is what your dependencies are. Expo versions its own packages and a curated set of twenty third-party libraries, Reanimated, Gesture Handler, Screens, Skia, Maps and WebView among them, which it says are tested with each SDK release. For those, installing with the fix option aligns the versions to the SDK you are on, and expo-doctor checks the project for common problems. Anything outside that set is yours to track, and since SDK 52 the doctor warns by default about packages it cannot find in React Native Directory. In practice this is where upgrade time goes: not in React Native itself, in the libraries nobody has looked at since the day they were added.
The third is whether anyone edited the native folders by hand. Expo is explicit that manual changes there are at risk the next time the native projects are regenerated with the clean option, and that the supported way to change them is a config plugin, which is a function that reapplies your change every time. A hand edit is a cost you pay on every single upgrade. A config plugin is a cost you pay once. If you inherited a project and do not know which you have, the ignore file and a look at the commit history will tell you in a minute.
Check yours
What an upgrade will cost you
Tick what is true of your project. Each answer is the documented consequence, not a guess about your code.
Nothing ticked. A project with no committed native folders, no libraries outside the tested set and a current SDK is the cheap case: change the versions, reinstall, let the native projects be generated again.
Where this lands if a builder generated your app
Nothing in this changes because an AI wrote the first version. A generated React Native and Expo project is on a React Native minor and an Expo SDK like any other, it inherits the same support window, and the clock starts at generation rather than at handover. The thing worth internalising is that none of the upgrade cost is decided by who typed the code. It is decided by what is in the repository: the SDK version, whether the native folders are committed, and how many libraries sit outside the tested set.
Newly is an AI app builder. You describe an app and it writes a real React Native and Expo project you own, with two-way GitHub sync, so the three checks above are checks you can run yourself in your own repository rather than questions you have to ask somebody. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, because Apple requires the owner of the content to submit the app. It is $25 a month, and there is no free tier. If the question of ownership itself is live for you, the longer answer is in who owns AI generated code.
The honest limit: generating an app does not stop the framework moving, and no builder can promise otherwise. What it gives you is a starting position, and the only way to know which one you have is to look. Read the expo version in package.json, see whether the ios and android folders are in the repository or in the ignore file, and run the doctor. That is a ten minute job in your first week with a project, and it tells you where in the support window you are standing before anyone plans a release around you. Do it every quarter and an upgrade stays a quiet afternoon. Let four releases pass and it becomes a project with a name and a meeting.
Questions people ask about React Native upgrades
The build chain first, your native dependencies second, and your own JavaScript last. React Native's own definition of a breaking change covers an incompatible API change in JavaScript, Java, Kotlin, Objective C or C++, a significant behaviour or runtime change, a significant change in the development experience, a major bump of a transitive dependency such as React 18 to React 19 or the Android target SDK, and any reduction in the platform versions it supports. Four of those five are things you never typed. The 0.87 release, out on 10 August 2026, is a fair sample: it raised the required Node version, moved Android to Kotlin 2.0 and Android Gradle Plugin 9, and made the Strict TypeScript API the default so that deep imports into internal folders no longer resolve.
Start on a current version, and keep it that way
Put the upgrade in the calendar every quarter, read the breaking changes section before you touch a version number, and keep your native folders generated rather than hand edited. That is the whole discipline, and it is the difference between an afternoon and a fortnight.
Start building