It depends on your definition. The chat view, where you probably spend 99% of your time, was native as-of 2019. Not sure if there's been any progress made since then.
If it's already bad, isn't that a reason to be excited about the change? From what you say, it's already at the brink of unacceptable in terms of performance...
I'm skeptical that this makes business sense for most companies. Most electron apps feel like they're just checking off a box, rather than crafting any sort of quality desktop experience. If you don't care, why not just slap your website in a webview? Way easier than trying to hire or train developers in a niche technology.
On the desktop I don't think there's much value in it. Electron is much more compatible with the web, requires less platform specific work, and doesn't really come at a significant performance or UX cost.
Not a different use case, all draw shapes to users' screen. I've seen people ship games with electron. If what GP is saying is correct, AAA companies should have no problem deploying CPU/GPU-intensive games using Electron.
Leaving the sarcasm aside, I'm tired of people arguing Electron has no performance/memory/whatever cost. It's worse at everything compared to native programs except developer experience.
I understand valuing your developers' time more than your users' (which is a bit backwards but whatever), but don't argue that Electron is not a tower of abstractions that has no cost at runtime. That's just not true.
Sure they could ship games in electron that render to canvas and use wasm, otherwise yes they are entirely different use cases. Desktop UIs are mostly static. Web renderers are actually quite good at rendering mostly static UIs in an accessible and efficient way.
To my surprise, the most common issues I see with the desktop app are audio device issues, e.g. the app doesn't get any audio from my mic the first time I run it, only after I kill and re-launch it. The UI has been fine, if weird. I don't know of any major apps using RN on desktop so going that route may be worse than sticking with Electron.
My company has a RN app and a React web app. We've found there isn't much opportunity for sharing UI code; you can share hooks, data layer type stuff, etc, but the actual components aren't really compatible because the leaves of the UI tree are totally different (native elements vs HTML elements)
The bigger wins come from shared tooling/skillset/headspace. Our UI devs can fairly easily jump back and forth between the two codebases
Though our web app does a lot of things the mobile app doesn't, and also benefits from things like Next.js, so I'd be a little worried about the cost/value tradeoff there for us specifically
I've been using the iOS RN app for years (on a phone that's currently 4 years old) and never had any performance issues. There may just be some transition pains they need to work through on Android
It's worth noting that even a cheap, used 3-year-old iPhone 11 [0] is faster in benchmarks than a new flagship Samsung S22 Ultra [1], and the disparity is much larger when comparing flagships of the same generation head-to-head. This is no excuse for slow software, but it does go some way towards explaining the speed of the iOS app.
I hate a lot of Electron and React Native based software, but Discord manages to avoid performance, stability, and quality issues that most seem to encounter. I don't know what they do or how they do it, but I think it's very impressive.
We used it a lot over the pandemic and random crashes and having to restart because it started using way too many system resources was extremely common. Nobody left it open when not in active use, because it was such a resource hog. Using it on battery would take a macbook from full to 0% in like two hours flat. This was with a couple very small private groups only, no use of large public channels or anything.
The desktop client is, to me, not as performant as it should be. Many actions take several hundred milliseconds when it's obvious that they could be much faster.
react-native is NOT a total replacement for native code, you still need native devs. It is more like instead of 5 ios and 5 android devs you need 4 JS, 1 android and 1 ios devs (but the ios and android persons also need to know JS)
react native =/= electron (and similar frameworks like CEF). The former uses native widgets. The latter uses HTML/CSS rendered by a browser layout engine.
I know that. I am saying that if the app is mostly webviews anyway instead of building the views natively, there would not be much difference between being a fully native app with WebViews or being an RN app with <WebView> components.
There is still a _desperate_ need for a widely used common standard for GUI; I'd even be OK with that happening to be 'things are webpages' if they were OS native and would otherwise behave similarly to native apps on every platform. That HTML5 desktop or even Postscript would be nice; anything as long as it's a real standard already installed and kept up to date on 99% of potential user's systems.
It should be noted that the need for standard GUI doesn’t come from the users, who mostly prefer consistency among different apps within their OS of choice.
React Native really is a game changer for mobile development. I picked it up last year to build a new iOS app for the first time since the old Objective-C/UI-Kit days. I was literally building things in minutes that would have taken hours or days of writing custom OpenGL and networking code back then. Any performance tradeoffs left at this point are worth it IMO.
I picked up React Native a few years ago for a project and spent a week doing nothing but fighting the build system. And then I spent another week doing the same on Android.
The first question that popped into my head when I saw this headline was: Is React Native still a hot mess?
>The first question that popped into my head when I saw this headline was: Is React Native still a hot mess?
Expo [0] is what really makes things painless now. There's no more struggling with native binary dependency hell. And the entire App store submission process is completely managed; building, signing, uploading, and pushing a new version from your machine to Apple is just a single CLI command.
I wonder if they considered Flutter as well, but their website is probably written in React so it makes sense to use RN as well to share relevant code.
If it reaches the performance of the already RN iOS app, then it’s a win. I’m still rocking an iPhone 6s, on which Discord is buttery-smooth. If only the Slack app could do the same…
The iOS app seems to work as well or better than the desktop app in my experience, so imagine my surprise finding out it's React Native. If the Android app will work just as well, this is good news.
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?
> 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.
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
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
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.
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.
> 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
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.
I had to uninstall the discord app for my Core i5 Windows PC because it would randomly peg the CPU at 100% and become mostly unresponsive (several seconds to register keystrokes...). Now it's only a web tab I load when I need to.
I was relying on the Android app for notifications... but if it's now becoming as bad as the Windows and the Web apps, that's going to be an issue. I can't uninstall it from everywhere, not a messaging app.
- There were very little opportunities for sharing functionality between web and mobile. The standard react architecture is code-behind, and you can't share components between react and react native.
- Time-consuming to update to new versions, especially on the IOS side of things. A constant avalanche of errors from the very convoluted cocoapods build system, with stack traces in multiple different languages popping up (From memory: bash, objective C, swift, ruby). Involved a deep dives into github issues.
- In the end we were at least able to share some validation stuff between the web and mobile app, which was better than nothing.
Full disclaimer - I was a busy tech lead, wasn't very hands on with it, and in my teams the mobile app was a secondary concern.
Very curious if other people have a different experience.
We've had a good experience (I've commented with more details elsewhere)
I will say, I don't think sharing code between web and mobile was ever supposed to be a key advantage. As you say, there may be some small opportunities for that, but the real benefits are a) sharing code between the two mobile platforms, and b) sharing skillsets between web and mobile
that was true a while ago, but react-native-web works pretty well these days. You do need to write your code react-native first though (ie your code is react-native and react-native-web adapts it to work in the web)
but a lot of things are, not clunky per se, but unsolved for web. Main example is JS-based tooltips, react-native-web doesn't give you one and it doesn't make sense to do it in mobile. So you end up needing a lot of if platform === 'web' do this, way more than just supporting ios+android
updating to new versions is a huge pain, I usually default to making a new project from scratch and re-introducing our custom native code. Having iOS build knowledge helps a lot
Are there any numbers? It might be interesting to compare apk size differences, performance (perceived and measurable), at least app cold startup times. What about accessibility improvements or degradation?
I guess good luck to them. I still don't understand why organizations this large cannot maintain a native experience that is tailored to each class of device.
This fake paradise of "one app to rule them all" is absolute madness to me now.
81 comments
[ 3.5 ms ] story [ 132 ms ] threadOne thing that isn't super clear in the article: Is their iOS app already on React Native?
Edit: Seems like it https://discord.com/blog/how-discord-achieves-native-ios-per...
If the app gets any laggier or slower I will probably have to abandon it...
Moving from native to react native will almost certainly be slower (unless something in their native app is just very broken).
That said, seems like Android users really dislike this update as the app seems slower, buggier and less polished than it used to be.
Because safari sucks and that makes webview suck too. It's like asking why people don't use ie6 for web apps.
I wonder why Rockstar or Bethesda don't just use electron for their games.
Leaving the sarcasm aside, I'm tired of people arguing Electron has no performance/memory/whatever cost. It's worse at everything compared to native programs except developer experience.
I understand valuing your developers' time more than your users' (which is a bit backwards but whatever), but don't argue that Electron is not a tower of abstractions that has no cost at runtime. That's just not true.
The bigger wins come from shared tooling/skillset/headspace. Our UI devs can fairly easily jump back and forth between the two codebases
Though our web app does a lot of things the mobile app doesn't, and also benefits from things like Next.js, so I'd be a little worried about the cost/value tradeoff there for us specifically
[0]: https://browser.geekbench.com/ios_devices/iphone-11 [1]: https://browser.geekbench.com/android_devices/samsung-sm-s90...
https://discord.com/blog/why-discord-is-sticking-with-react-...
react-native is NOT a total replacement for native code, you still need native devs. It is more like instead of 5 ios and 5 android devs you need 4 JS, 1 android and 1 ios devs (but the ios and android persons also need to know JS)
Unfortunately, by far the closest thing we have to this is Google Chrome.
The first question that popped into my head when I saw this headline was: Is React Native still a hot mess?
Expo [0] is what really makes things painless now. There's no more struggling with native binary dependency hell. And the entire App store submission process is completely managed; building, signing, uploading, and pushing a new version from your machine to Apple is just a single CLI command.
[0] https://expo.dev/
https://dev.to/mauro_codes/expo-101-building-mobile-apps-in-...
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?
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.
> 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
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
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.
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.
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
> - 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.
I was relying on the Android app for notifications... but if it's now becoming as bad as the Windows and the Web apps, that's going to be an issue. I can't uninstall it from everywhere, not a messaging app.
- There were very little opportunities for sharing functionality between web and mobile. The standard react architecture is code-behind, and you can't share components between react and react native.
- Time-consuming to update to new versions, especially on the IOS side of things. A constant avalanche of errors from the very convoluted cocoapods build system, with stack traces in multiple different languages popping up (From memory: bash, objective C, swift, ruby). Involved a deep dives into github issues.
- In the end we were at least able to share some validation stuff between the web and mobile app, which was better than nothing.
Full disclaimer - I was a busy tech lead, wasn't very hands on with it, and in my teams the mobile app was a secondary concern.
Very curious if other people have a different experience.
I will say, I don't think sharing code between web and mobile was ever supposed to be a key advantage. As you say, there may be some small opportunities for that, but the real benefits are a) sharing code between the two mobile platforms, and b) sharing skillsets between web and mobile
but a lot of things are, not clunky per se, but unsolved for web. Main example is JS-based tooltips, react-native-web doesn't give you one and it doesn't make sense to do it in mobile. So you end up needing a lot of if platform === 'web' do this, way more than just supporting ios+android
updating to new versions is a huge pain, I usually default to making a new project from scratch and re-introducing our custom native code. Having iOS build knowledge helps a lot
This fake paradise of "one app to rule them all" is absolute madness to me now.