Thread by @mateusz1913

That #reactnative #Fabric & #TurboModules migration was a big pain, especially that I had Kotlin and Swift code to migrate, so it’s a big relief to have it done. And there is lots of completely undocumented stuff I wish I knew that would made it a lot easier to migrate

If you care about backward compatibility, supporting #Fabric & #TurboModules is realistically doable only from version 0.70+ (Swift support + Kotlin fixes + CMake builds instead of NDK + autolinking for Android available only in rn cli v9 which is available in RN 0.70+)

Android side is easy:
- declare additional newarch nad oldarch sourcesets
- create seperate newarch/oldarch "entry" files for your module/viewmanager
- use existing module/viewmanager files as a "common" implementation

And if you don't have to migrate shadownodes, you only work with Kotlin/Java code which is nice (and some small Gradle script changes)

On iOS it's way harder, especially if your library had a lot Swift code, because "entry" files for your module/viewmanager need to be written in ObjC++ (because of importing headers with classes and namespaces from C++ or ObjC++)

Detecting if new arch is enabled "can" be done in Swift with "OTHER_SWIFT_FLAGS" custom flag, but it's limited and you can't use it to e.g. use some conditionally imported ObjC++

Common implementation files can be left in Swift, however, using Swift code inside ObjC/ObjC++ within cocoapod library is “broken” github.com/CocoaPods/Coco… and manual header declaration must be done

Unlike in Android, in iOS code, more documented approach is to use single source set with #ifdef or #if declarations to detect if newarch or oldarch code should be used, however with cocoapods, separate sourcesets can be declared inside podspec (as a separate subspecs)

If your native component uses RCTDirectEventBlock prop on iOS, you must handle it separately on newarch, in ObjC++ code :( thanks to dedicated view event emitters in RCTViewComponentView (in some way successor for RCTViewManager)

When migrating custom RCTView, it can be reused in newarch code, with custom ReactViewComponentView declaring it as a self.contentView property. And to handle children, mount/unmountChildComponentView must be overriden to forward children to the custom RCTView

Overall, it's harder especially if you don't have experience with C++ specific stuff like namespaces, or writing conditional code with #ifdef directives or you just prefer Swift over messing up with ObjC/ObjC++

On JS side the only hard thing I found was that TypeScript codegen specs for native components needs to have specific CodegenTypes like Int32, WithDefault, DirectEventHandler, etc. - however it was well documented reactnative.dev/docs/new-archi…

And it's nice to have codegenConfig fully in package.json reactnative.dev/docs/new-archi… from 0.70 compared to previous 0.68-0.69 where Android config needed to be done in Gradle

For anyone interested, here is how whole migration looks like:
github.com/mateusz1913/re…