I have been working for the past four years exclusively on react-native apps and their backend API, from bootstrap to publishing, adding new features every few months and maintaining the apps.<p>It was a mixed experience. When I migrated to expo two years ago, many problems were solved but not all.<p>But I still encounters bugs and problems with many common dependencies. It is not uncommon to have bugs on certain Android brands, with the community on github reporting the bug but waiting months for it to be fixed.<p>iOS is by far better and more stable than Android.<p>Performance is great on iOS, but less great on Android.<p>Our apps are animation heavy using react-native-reanimated and react-native-skia. Everything went perfect on iOS but we had to remove some animations or simplify them on Android.<p>Upgrading your dependencies every four months will probably break something somewhere : deep links stop working, some animations stop working, or maybe it's another dependency from the JS world.
Sometime the fix is easy, other time an issue with the regression can be found on Github, other time we have no data.<p>Overall I'd say react-native is perfectly servicable and is easy to learn for anyone, which is a big plus.
I'd recommend react-native because it is easy, have a big JS ecosystem, but I am now on the Flutter side.
At the time of writing this comment, we've got:<p>1 person talking about how they wish react native didn't exist<p>1 person asking about Capacitor<p>1 person complaining about Expo<p>1 person saying that they wouldn't use react native and recommending Kotlin Multiplatform instead<p>1 person complaining about the quality of the discussion (Me)<p>0 people talking about the new architecture<p>I still love Hacker News but the discussions are becoming increasingly pointless.<p>All that's missing is:<p>1 person complaining about the style in which the article was written
I'm a Flutter dev since 2018 and I am honestly not sure if Flutter or React Native still make sense in 2024 and onwards.<p>When they emerged, the mobile development scene was completely different than today.<p>Today, we have Swift UI and Compose, both are pretty solid. I'm not sure if it's the consensus amongst mobile developers, but I believe that on the mid/long run you will be better off - even if you write things twice. In terms of end user experience, developer experience, and in the business sense, everywhere.<p>Sure if you have an Flutter / RN app that has years of engineering efforts invested into it, go ahead and continue (duh), but I wouldn't start new apps with them.
I've used React Native quite a bit in the past and I gotta say I wish it didn't have to exist at all.<p>It's often times fine on iOS and then incredibly slow on Android. Hermes is very exciting but still requires many polyfills to make simple NPM packages work. I hope one day, the web (and embedding web apps on mobile) makes React Native fully obsolete.
We use Expo/RN for Bluesky. The way I see it, if it's a separate codebase then it's a separate product. I honestly don't think we could've survived trying to build 3 different apps at once, so when I get hit with one of the warts (and believe me we hit them) it's not hard to shrug it off.<p>The team has been able to progressively target the different platforms where needed with native modules and TS files targeting the arch. Expo's build plugins have also saved our bacon.<p>We've been pretty excited for the new architecture. Our early tests show a lot of performance benefits on android, and so far the conversion process has been pretty good.
I did a performance test last year, rendering thousands of views, and Flutter's rendering speed was 5 times faster than React Native. I wonder if this version will be improved after the update.
Interestingly, I used React on the web to render the same number of views, and its speed was much faster than React Native.
Seems to be a lot of negativity around RN, and I can understand that if you haven't used it in a while. But these days I have nothing but great things to say about React Native when used with Expo. It's great to want custom bespoke individual native apps for each platform but as a solo dev that just isn't really practical and RN has enabled me to ship things I wouldn't have been able to otherwise. Also that hot reloading react DX is just great in general. And I really want the RN model of using the platforms native controls to win out vs rendering everything to a canvas like Flutter.<p>Can't wait to try out the new arch when 0.76 lands in expo.
Is Capacitor a viable solution yet? I saw this tweet saying "it just works" for porting a webapp on NextJS: <a href="https://x.com/marc_louvion/status/1836023560462360746" rel="nofollow">https://x.com/marc_louvion/status/1836023560462360746</a>
Is there any sane way of using RN without locking into the Expo ecosystem? Last I checked it was a nightmare dealing with native dependencies otherwise.
React native is finally pretty good this year. It still has problems but I feel like it's really starting to pick up momentum.<p>When react-strict-dom is totally ready for prime time it's going to be a game changer and react native will become an absolute juggernaut.
I have built a React Native app in the past. Nowadays I would go for Kotlin Multiplatform. It is already the primary language on Android and now it is possible to create native binaries on iOS. With Compose multiplatform it also has the ability to also share UI code with a declarative syntax on multiple platforms.<p>I think React Native was the go to place in the past but it has been surpassed now.
This is pretty incredible, kudos to the team! I wonder if there's still an option to call native modules asynchronously (since I'd guess the synchronous native calls block JS execution?)<p>Also, I remember transferring lots of data through the bridge could be a bottleneck for some use cases. Is that effectively solved with this architecture?
I'm not familiar with UI development at all, but I'm kind of amazed that the old solution of a giant async bridge where the renderer enqueued native function calls worked at all. What was the initial reasoning behind this architecture? (that is to say, why did it seem like a good idea at the time?)
Guys, help me understand these changes:<p>Can I comprehend this as a new Virtual Native UI immutable tree running in native space?<p>And react native mounts and updates basically synchronally updating this immutable tree and reconciliation being done in native space, dynamically updating the app layout?
Love react native, I'll be updating to this version soon. Really hoping it makes suspense work correctly with libs like Relay. Well done and thank you RN team.
It’s looking really good so far. Some known issues in the expo and RN ecosystem are called out under the troubleshooting section here:<p><a href="https://docs.expo.dev/guides/new-architecture/" rel="nofollow">https://docs.expo.dev/guides/new-architecture/</a>