Starting with React Native 0.82, the old Bridge-based architecture ceased to exist. All libraries with native modules that weren't updated became incompatible with current framework versions.
Our own libraries were actively used in several projects that had already migrated to the new architecture. Without updating the libraries, their further development would be blocked. The choice was obvious – it was time to act.
Where We Started
We allocated two days for the migration. First, we studied the migration experience of other open source libraries and chose our toolset. The best solution turned out to be react-native-builder-bob – it creates a ready-made boilerplate with TurboModules and Fabric support, eliminating the need to configure infrastructure from scratch.
Transitioning to Modern Languages
The native code of the libraries was written in Java and Objective-C. For the new architecture, we decided to switch to Kotlin and Swift – more modern and convenient languages.
The migration from Java to Kotlin went smoothly. But with Swift, an interesting problem emerged that didn't manifest immediately.
The use_frameworks! :static Problem
When Swift code is used in a React Native module, the compiler automatically generates an Objective-C bridging header – a special file that allows calling Swift from Objective-C.
Everything worked perfectly until we tried to integrate the library into a project with the use_frameworks! :static setting in CocoaPods. In this mode, the path to the header file changes, and the library stopped building.
#if __has_include(<react_native_wallet_manager/react_native_wallet_manager-Swift.h>)
#import <react_native_wallet_manager/react_native_wallet_manager-Swift.h>
#else
#import "react_native_wallet_manager-Swift.h"
#endifWhat We Got
- Libraries work with current React Native versions
- Modern code in Kotlin and Swift instead of Java and Objective-C
- Compatibility with different CocoaPods configurations
- Projects unblocked and continuing development
Conclusions
Migrating to the new React Native architecture isn't just a version update. It's a transition to new tools, languages, and approaches. The key is not to postpone if your projects depend on libraries with the old architecture.









