When a third-party library blocks a React Native app's move to the New Architecture, how do you decide whether to replace it, fork it, or port it yourselves?

## The situation A library that does not support the New Architecture is no longer a problem you can postpone by staying on the old one: since React Native 0.82 there is no old one. If the library runs through the **interop layers**, you have time. If it does not compile or its key paths silently fail, it blocks the upgrade now. Either way the team needs a decision, and it is a judgement call with no single right answer. ## The options React Native itself lists React Native's docs, for libraries built on the legacy native module and component APIs, suggest: 1. **Use an alternative library** that supports the New Architecture. 2. **Upgrade** to a newer version of the same library with first-class support. 3. **Port it yourselves** to Turbo Native Modules or Fabric Native Components. The 0.76 guidance adds **opening an issue** with the maintainer and, for an unmaintained library, looking for an alternative. A **fork** is the practical form of option 3 when the upstream will not accept or release your port. ## The questions that decide it - **How central is the feature?** In a ride-hailing app, the map, location tracking and payment sheet are on the path to revenue; a decorative animation library is not. Central features justify more investment and less risk. - **Is there a credible alternative?** A maintained library with New Architecture support and equivalent features usually wins. Migration cost is paid once; maintenance of your own copy is paid every release. - **How large is the native surface?** A module with a few methods is a contained port. A wrapper around a large vendor SDK drags in that SDK's upgrades and platform quirks. - **Can the team own native code?** A port or fork means Kotlin, Swift or Objective-C, and possibly C++, reviewed and tested by people who will still be there next year. - **What is the licence?** A fork must be allowed and properly attributed. - **What does waiting cost?** Every release since 0.84 removes more legacy classes, and React Native has said interop will eventually go. Waiting is a choice with a deadline you do not control. ## A decision grid | Situation | Leaning | |---|---| | Maintained alternative with equal features | Replace | | Upstream active, migration in progress | Wait on interop, with a deadline, and help upstream | | Upstream dead, small native surface, team has native skills | Fork and port, or bring the code in-house | | Upstream dead, large native surface, no alternative | Port only if the feature is central; otherwise cut or redesign the feature | | Feature is marginal | Remove the feature and the dependency | ## Costs people forget - **Carrying patches**: a fork must be rebased onto every React Native release, and removals in 0.84 and 0.85 show that legacy-adjacent code keeps breaking. - **Testing**: an in-house port needs device tests on both platforms, not just a successful build. - **Knowledge concentration**: a port owned by one engineer is a new single point of failure. - **Opportunity cost**: weeks spent porting a marginal library are weeks not spent on product work. - **Review burden on sensitive code**: a fork of a payment or location library puts security-relevant native code under your own review process, with no upstream reviewers sharing the load. ## Making the decision stick 1. Write the decision down with the reason, an owner and a **revisit trigger** (for example "when upstream ships New Architecture support" or "before the next React Native upgrade"). 2. Add a check to the upgrade checklist so an interop-only library is re-evaluated each time. 3. Where the team ports, consider offering the port upstream so the ecosystem, not only your app, carries it forward. ## Summary Replace when a good alternative exists, wait on interop only with a deadline and an active upstream, fork or port when the feature is central and the team can own native code, and drop the feature when it is marginal. The deciding factors are business centrality, available alternatives, native surface size, team skills and the fact that legacy support in React Native only shrinks.