We recently migrated an app from React Native to Compose Multiplateform. It was painful, but we did ...

# compose

[Nathan Fallet]

We recently migrated an app from React Native to Compose Multiplateform. It was painful, but we did it. I’m about to write an article about it. Anything that would be interesting to mention/deep dive?

[Rey (Kingg22)]

Maybe the ecosystem on each technology (libraries for X react native exist and you do X to replace it).
If you have something manual for platform specific and how you addressed it in the migration

[Oliver.O]

I’d be interested in: Why did you do it? What were the pain points and how did you deal with them. What would you do differently next time? Did the result meet your expectations?

[Nathan Fallet]

@Oliver.O The pain was about react native itself. Each time we had to upgrade Expo for example, everything was broken, and we were tired about this (while I never got breaking issues like this making native apps for years). Also, Kotlin feels way safer than TypeScript; The setup is cleaner (for example no one talks about DI in RN while it’s a standard thing with Kotlin) and we can more issues at compile time.
Settings up a CMP project was easy (done a lot of time before), but understanding React Native modules to embed native code was really difficult (compared to how you embed a native view in Compose which is very easy)
Another reason for the migration is that all our backend has been in Kotlin for a long time, so more cohesion between our components and teams, and the ability to reuse models/logic over projects sometimes.
We’re currently still in the process of migrating, we achieved the setup to have multiple CMP screens in the React Native app, but the plan is too replace all screens over time to get a full CMP app with no more RN/TS. We’re pretty happy about the new screens we have and the way they work.

[Sergey Y.]

How did you evaluate Compose Multiplatform against other alternatives (Flutter, Skip, native development, etc.)?

[Oliver.O]

@Nathan Fallet Sounds very reasonable. Looking forward to your article!

[Sairaj Kalkundre]

@Nathan Fallet can you explain also about performance improvements ?

[Dzianis Shakinau]

@Nathan Fallet embedding native view in composable is very easy indeed, but all of them are drawn behind the main composable layer and it makes impossible using iOS liguid glass widgets for example

[Nathan Fallet]

@Sergey Y. I was already used to Kotlin & Compose from other projects. It was the first RN project we made. Never done Flutter before. It’s about getting to what we feel comfortable with, and are able to ship new stuff quickly. + the all Kotlin ecosystem we already have on the server side.

[Nathan Fallet]

@Dzianis Shakinau We are not interested by liquid glass right now. We already have our design system, which is common between ios and android, so we will stay with it

[Pearce Keesling]

We are in a very similar spot right now so I'll be on the lookout!
I'd love to hear your migration path. We're considering using react-native-brownfield to sort of "back out" of react native using the tools people use to migrate in.
Did you leverage reakt-native-toolkit at all? We're using that for some of our core native modules and are slowly migrating some core typescript code (auth, web sockets, etc) over so that if/when we migrate we'll be able to reuse all of that.
Were you all ever able to make it over to the new arch on rn?
Size of the app in terms of code and users?
What feedback did your users have?
Was it the same or different between the two platforms?

Sorry for the million questions, I'm in lots of meetings about this topic right now so it's on my mind.

[Nathan Fallet]

@Pearce Keesling That’s a lot of questions but it’s okay! It’s not an easy task.
We did not use any external tool for this. We directly use the SimpleViewManager<ComposeView> on Android and RCTViewManager on iOS (wrapping the compose view with ComposeUIViewController).
It was a pain to setup this “bridge”, but it works fine, and you cannot see the difference between Compose and React Native screens visually.
The app is a bit bigger right now because we embedded both frameworks, but it’s a small difference when you see how big is the RN app initially. And we know the day we’ll completely remove RN we’ll have a way smaller app as well.
One great thing is that CMP allows more consistency between platforms than RN (because some RN views does not render exactly the same way on both platforms)
Also, we’re building the desktop app of our SaaS so that’s what made us think we can migrate (because we’ll use CMP for desktop so why not migrate mobile as well)
Hope I got most of your questions answered. I don’t know about reakt native toolkit for example, since we went for a simple wrapping screens method until we get all screens available in CMP and totally remove RN (we don’t plan to keep both at the same time for long)

[Pearce Keesling]

Thank you so much!
What layer of the tree did you wrap the screens in? For example if you're using react-navigation (or expo-router since you mentioned expo) is that still the "driver" of the navigation and then the native screens are just stubs that host the View Managers?

[Nathan Fallet]

React is managing the navigation and we embed native screens directly inside a native component which is used as a screen for react navigation