Rehearse React Native compatibility before removing the fallback
React Native 0.82 ignores legacy architecture opt-outs. Use the 0.81 migration stage to verify native dependencies and separate mandatory from optional changes.
By 
Paul. Languages and frameworks
A migration becomes harder to diagnose when the same update both changes the architecture and removes the way back. React Native's October 2025 transition offers a useful general lesson: establish compatibility while the previous architecture remains selectable, then cross the release boundary that removes that choice. Dependency readiness should be a release condition with evidence attached to the actual application.
Looking back from November 2026, React Native 0.82 arrived on 8 October 2025. It made the New Architecture mandatory. The argument here concerns that historical transition, not a recommendation that an application should now stop indefinitely on 0.81. A current migration must also consider supported versions and the intervening changes that apply to its starting point.
The fallback flag no longer changes the architecture
The 0.82 announcement states that Android's newArchEnabled=false and iOS's RCT_NEW_ARCH_ENABLED=0 are ignored. An application still runs on the New Architecture. A flag remaining in a configuration file is therefore not evidence that the fallback remains available. The setting's meaning is defined by the version that consumes it.
The maintainers recommended first moving an unmigrated project to React Native 0.81 or Expo SDK 54, the last versions permitting the Legacy Architecture, then enabling and verifying the New Architecture there. That sequence separates architecture compatibility from the later mandatory boundary. It does not promise that every other change in 0.82 is consequence-free.
React Native 0.81 was released on 12 August 2025. Its announcement also describes platform changes, including targeting Android 16 and moving built-in JavaScriptCore support to a community package. Those details make the intermediate stage real engineering work. It would be misleading to present 0.81 as a neutral switchboard with no platform or dependency changes of its own.
This article is public framework analysis. It does not inspect AL+ mobile applications, access a developer's Mac, run a native build or report a device test. Whether a particular app is compatible remains a question for evidence from that app's code, dependencies and supported devices. The release posts supply the framework boundary, rather than the application's result.
Compatibility belongs to the dependency graph
An illustrative app may have a small JavaScript interface and still depend on native libraries for storage, camera access or navigation. The migration decision needs the exact dependency versions and any custom native modules. A package name appearing on a general compatibility list does not establish that the pinned version, local patches and platform configuration in that app work together.
For each important native boundary, identify the user action that would expose a failure. Opening an image picker and returning to an unfinished form is a more useful acceptance condition than saying that the camera package is present. A successful launch is necessary, but it does not establish that the full workflow preserves data or handles interruption correctly.
Keep evidence proportional to the application. A simple app with few native integrations need not invent an elaborate certification program. An app whose business depends on background work or custom native code needs checks that reach those paths. The relevant scope follows the application's promises, including error handling and supported platforms, rather than the length of its package list.
Responsibility also needs a name. If an incompatible third-party module blocks migration, someone has to decide whether to update, replace, maintain a patch or delay. The 0.82 announcement directs dependency problems to library maintainers and core bugs to the framework issue tracker. That is guidance on where to report a problem, not a guarantee of a fix on an application's deadline.
Mandatory architecture does not mean every experiment is mandatory
The 0.82 release separately offered experimental Hermes V1 as an opt-in. It also shipped React 19.1.1. Neither fact should be rewritten as a requirement to adopt every new runtime experiment in order to migrate architecture. Keeping optional changes separate can make a failure easier to attribute and a migration plan easier to explain.
The announcement also retained interoperability layers and did not remove Legacy Architecture APIs from core in that release. Mandatory New Architecture is therefore a narrower claim than saying all legacy classes disappeared in 0.82. Compatibility through an interoperability layer and continued execution on the Legacy Architecture are different things. Preserve that distinction when assessing a library's support statement.
A release note can establish those framework facts without proving an app's performance. The maintainers' measurements of Hermes experiments do not become a speedup promise for another application. A compatibility migration may be justified by support and maintainability even when no measured performance gain is available. Its acceptance criteria should say which problem the upgrade is intended to solve.
A rehearsal is useful only when it answers an uncertainty
The strongest counterargument is that an app already verified on the New Architecture gains little from repeating an intermediate migration solely for ceremony. If the existing evidence covers its dependencies and workflows, a direct upgrade may be appropriate. The general principle is to separate unresolved risks, not to require every team to visit every historical version.
Delaying can also be defensible when a critical dependency remains incompatible and there is no acceptable replacement. The delay needs an owner, a reason and a reconsideration point. It should not be justified by assuming a disabled architecture flag will continue working after the upgrade. Equally, a deadline alone does not establish compatibility that has not been checked.
For software maintenance, record the architecture currently running, the dependency evidence required and the boundary after which the old opt-out is ignored. Then choose the smallest sequence that resolves the actual unknowns. A useful migration plan makes the point of commitment visible before users depend on the result.