4 ms·

I'm pretty convinced RN is only really a thing because it gives PMs/managers some good promo material about how they lead a team to "switching to a shared cross

I'm pretty convinced RN is only really a thing because it gives PMs/managers some good promo material about how they lead a team to "switching to a shared cross-platform codebase". They then end up using that to switch jobs/companies before they have to deal with the long-term fallout of making the switch to RN. My company recently switched both our Android and iOS apps over from native to RN. The RN promoters promised all sorts of benefits about sharing code between platforms and how the performance would be as good as native, and how the UI would look like native, and none of that actually materialized: - In the end, RN code is only something like 20% of our Android app. They weren't able to just "write once" and run on both. - Instead of having 2 teams, an iOS and Android, now we have 3 teams, iOS native, Android native, and RN. And the RN team is split between iOS and Android. All sorts of additional complexity now. - We still need a fully staffed Android specific team for everything that couldn't be done in RN. - The performance difference vs. a native app is blatantly obvious. - Now we just have organizational problems as the app has multiple teams/languages involved, different parts of the app are owned by different teams and manager chains, rather than just one team of people that own making a good app. RN teams can dynamically push code changes to production apps and we no longer have deterministic, reproducible builds. - Now we have morale issues from the discontent from the team members that want nothing to do with RN. - The UI, even though it's supposed to use native controls, just does not look and feel like native apps, there's so many little things that are strange/different. - Our codebase is now dependent on a 3rd party platform and on a language that completely differs from how Google says that Android apps should be built. Why wouldn't we just build Android apps the way the Android team says we should? Is there going to be long term support for RN/JS?

seanalltogether 4y ago
> Instead of having 2 teams, an iOS and Android, now we have 3 teams, iOS native, Android native, and RN. And the RN team is split between iOS and Android. All sorts of additional complexity now. This is exactly where we were going with our RN skunkworks project before it was axed and rewritten fully in native. however in our case we had about 100 native screens on both platforms written in swift/java that upper management did not want to spend time rewriting to RN, so it kind of forced our hand back to native to stay sane.
brundolf 4y ago
Counter-anecdote from my company, which also ships a RN app on both platforms: > The RN promoters promised all sorts of benefits about sharing code between platforms and how the performance would be as good as native, and how the UI would look like native, and none of that actually materialized We've pretty much seen all of this materialize. Our native apps perform great, look great, feel native. There's a tiny bit of platform-specific code around the edges, mostly for integrations with third party libraries. But 90+% of our code is shared, idiomatic React code, and mostly only the team lead ever has to dig beneath that. The whole team for both apps together is around 10 people, and most of them never have to step outside of JS. They also have an easy time making changes in our React web app (and the web team has an easy time making changes in RN) because the skillsets largely overlap. > RN teams can dynamically push code changes to production apps and we no longer have deterministic, reproducible builds Ok- but nothing about RN forces you to use the dynamic code push feature. In fact, we just decided as an org that we wanted to reduce our usage of it. This sounds like an organizational issue. I have to ask, what kind of app were y'all building? I could see this varying widely based on that. Ours is a fairly straightforward finance app
andrekandre 4y ago
just curious, but ever try kotlin-native to share non-ui code?
the_gipsy 4y ago
So just like cordova / web shell apps, back in the day.
DanielHB 4y ago
yeah migrating an existing app to react native is usually not a good idea, either rewrite (maybe keep a few native modules for niche things) or keep doing full native Incrementally adding react native to an existing app is orders of magnitude harder than using react native from the start I say this as a react native developer with some native android experience. React native is awesome, but most of the success stories are apps 100% react native or mostly react native with a few sprinkles of native code for some custom functionality Also 3rd party libraries that are not maintained by Expo is usually better to be avoided, if you need some niche functionality just drop to native. And yes it does mean you now have 3 problems, but at least, summed together, those three problems are smaller than the previous 2 big ones
- sandofsky 4y ago
  I keep hearing the "You have go to all in" argument from React Native evangelists, but I haven't heard a reasonable explanation for why this would be. Why was Facebook able to introduce it within an existing native app? This also seems to contradict one of the major selling points, that you can always just drop down to native for problems outside its scope. This is a very important requirement for any company building more than a simple CRUD app. A simpler explanation is that "you have to go 100% in on React Native" self-selects for anecdotes from tiny companies tackling trivial problems, and allows one to say "No true scotsman" when a bigger company has a bad experience.
rubicon33 4y ago
This post hits the nail right on the head. React Native is absolutely a business win, but a developer loss. PM/Manager can advertise shared code base, and even sometimes hire less, or at least argue that they should be able to hire less, but really it ends up being a nightmare for the teams that have to use RN for all the reasons you've listed. I work for a company that builds a very advanced mobile application (not your basic CRUD) and unfortunately the previous frontend manager decided on RN. The result is a 50% RN 50% native codebase which is a nightmare to traverse, and impossible to hire for. We need effectively 3 teams, RN / JS / TS, Java, and Swift. The complexity added is absurd. The tooling, typescript, building, all of it. Going completely native drops all of that and allows developers to focus entirely on their craft - building rather than context switching all day long between JS / TS and Java / Swift. Hands down the worst part is the performance. There is a very obvious performance hit in nearly all UI interactions. If you're building out your mobile team and building a complex app, I highly recommend you do not use RN.
- brundolf 4y ago
  > I work for a company that builds a very advanced mobile application (not your basic CRUD) I think this is your problem right here. By nature, most higher-level abstractions will work better for mainstream/expected use-cases. If you're really pushing the envelope, I can see why an abstracted framework wouldn't work for you. For my company (which does have a straightforward CRUD app), it's worked out great. Very little native code on either platform
flakyfilibuster 4y ago
It looks like your company was ill prepared for the transition/ is not capable of fully transitioning as most of your mentioned "issues with RN" read like issues rather than problems with the framework itself. > - In the end, RN code is only something like 20% of our Android app. They weren't able to just "write once" and run on both. That has nothing to do with RN, that's on your company > - Instead of having 2 teams, an iOS and Android, now we have 3 teams, iOS native, Android native, and RN. And the RN team is split between iOS and Android. All sorts of additional complexity now. Again, your company/ mgmt. We shared code between iOS and Android and had zero native module maintenance. > - We still need a fully staffed Android specific team for everything that couldn't be done in RN. which was what exactly? > - The performance difference vs. a native app is blatantly obvious. The majority of apps within the app store could've been written in RN and you wouldn't know/ notice. Discords iOS App is written in RN and I bet a huge amount of commenters here wouldn't have know without reading the article.

seanalltogether 4y ago

> Instead of having 2 teams, an iOS and Android, now we have 3 teams, iOS native, Android native, and RN. And the RN team is split between iOS and Android. All sorts of additional complexity now. This is exactly where we were going with our RN skunkworks project before it was axed and rewritten fully in native. however in our case we had about 100 native screens on both platforms written in swift/java that upper management did not want to spend time rewriting to RN, so it kind of forced our hand back to native to stay sane.

brundolf 4y ago

Counter-anecdote from my company, which also ships a RN app on both platforms: > The RN promoters promised all sorts of benefits about sharing code between platforms and how the performance would be as good as native, and how the UI would look like native, and none of that actually materialized We've pretty much seen all of this materialize. Our native apps perform great, look great, feel native. There's a tiny bit of platform-specific code around the edges, mostly for integrations with third party libraries. But 90+% of our code is shared, idiomatic React code, and mostly only the team lead ever has to dig beneath that. The whole team for both apps together is around 10 people, and most of them never have to step outside of JS. They also have an easy time making changes in our React web app (and the web team has an easy time making changes in RN) because the skillsets largely overlap. > RN teams can dynamically push code changes to production apps and we no longer have deterministic, reproducible builds Ok- but nothing about RN forces you to use the dynamic code push feature. In fact, we just decided as an org that we wanted to reduce our usage of it. This sounds like an organizational issue. I have to ask, what kind of app were y'all building? I could see this varying widely based on that. Ours is a fairly straightforward finance app

andrekandre 4y ago

just curious, but ever try kotlin-native to share non-ui code?

the_gipsy 4y ago

So just like cordova / web shell apps, back in the day.

DanielHB 4y ago

yeah migrating an existing app to react native is usually not a good idea, either rewrite (maybe keep a few native modules for niche things) or keep doing full native Incrementally adding react native to an existing app is orders of magnitude harder than using react native from the start I say this as a react native developer with some native android experience. React native is awesome, but most of the success stories are apps 100% react native or mostly react native with a few sprinkles of native code for some custom functionality Also 3rd party libraries that are not maintained by Expo is usually better to be avoided, if you need some niche functionality just drop to native. And yes it does mean you now have 3 problems, but at least, summed together, those three problems are smaller than the previous 2 big ones

sandofsky 4y ago
I keep hearing the "You have go to all in" argument from React Native evangelists, but I haven't heard a reasonable explanation for why this would be. Why was Facebook able to introduce it within an existing native app? This also seems to contradict one of the major selling points, that you can always just drop down to native for problems outside its scope. This is a very important requirement for any company building more than a simple CRUD app. A simpler explanation is that "you have to go 100% in on React Native" self-selects for anecdotes from tiny companies tackling trivial problems, and allows one to say "No true scotsman" when a bigger company has a bad experience.

rubicon33 4y ago

This post hits the nail right on the head. React Native is absolutely a business win, but a developer loss. PM/Manager can advertise shared code base, and even sometimes hire less, or at least argue that they should be able to hire less, but really it ends up being a nightmare for the teams that have to use RN for all the reasons you've listed. I work for a company that builds a very advanced mobile application (not your basic CRUD) and unfortunately the previous frontend manager decided on RN. The result is a 50% RN 50% native codebase which is a nightmare to traverse, and impossible to hire for. We need effectively 3 teams, RN / JS / TS, Java, and Swift. The complexity added is absurd. The tooling, typescript, building, all of it. Going completely native drops all of that and allows developers to focus entirely on their craft - building rather than context switching all day long between JS / TS and Java / Swift. Hands down the worst part is the performance. There is a very obvious performance hit in nearly all UI interactions. If you're building out your mobile team and building a complex app, I highly recommend you do not use RN.

brundolf 4y ago
> I work for a company that builds a very advanced mobile application (not your basic CRUD) I think this is your problem right here. By nature, most higher-level abstractions will work better for mainstream/expected use-cases. If you're really pushing the envelope, I can see why an abstracted framework wouldn't work for you. For my company (which does have a straightforward CRUD app), it's worked out great. Very little native code on either platform

flakyfilibuster 4y ago

It looks like your company was ill prepared for the transition/ is not capable of fully transitioning as most of your mentioned "issues with RN" read like issues rather than problems with the framework itself. > - In the end, RN code is only something like 20% of our Android app. They weren't able to just "write once" and run on both. That has nothing to do with RN, that's on your company > - Instead of having 2 teams, an iOS and Android, now we have 3 teams, iOS native, Android native, and RN. And the RN team is split between iOS and Android. All sorts of additional complexity now. Again, your company/ mgmt. We shared code between iOS and Android and had zero native module maintenance. > - We still need a fully staffed Android specific team for everything that couldn't be done in RN. which was what exactly? > - The performance difference vs. a native app is blatantly obvious. The majority of apps within the app store could've been written in RN and you wouldn't know/ notice. Discords iOS App is written in RN and I bet a huge amount of commenters here wouldn't have know without reading the article.