Discord Switching to React Native for Android App(discord.com)
discord.com
Discord Switching to React Native for Android App
https://discord.com/blog/android-react-native-framework-update
81 comments
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.
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
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.
> - 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.
> 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.
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
> 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
just curious, but ever try kotlin-native to share non-ui code?
So just like cordova / web shell apps, back in the day.
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
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.
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.
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.
it is because they are not afraid to drop to native when it makes sense, see:
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)
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)
[deleted]
I have to assume it's partly because they never update Electron -- I've not been able to run it under Wayland for a few months now
--ozone-platform=WAYLAND ?
That is indeed how I would enable it, but it stopped working! I get this:
interface 'wl_output' has no event 4[deleted]
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.
Big win for React Native! I'm curious how the user feedback will be.
One 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...
One 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...
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.
[0]: https://browser.geekbench.com/ios_devices/iphone-11 [1]: https://browser.geekbench.com/android_devices/samsung-sm-s90...
[0]: https://browser.geekbench.com/ios_devices/iphone-11 [1]: https://browser.geekbench.com/android_devices/samsung-sm-s90...
Here's my experience with react native:
- 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.
- 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.
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
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
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
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
I hope desktop apps can soon start switching from Electron to React Native.
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.
>> why not just slap your website in a webview
Because safari sucks and that makes webview suck too. It's like asking why people don't use ie6 for web apps.
Because safari sucks and that makes webview suck too. It's like asking why people don't use ie6 for web apps.
Hence why they just bundle a copy of Chromium in Electron.
I would prefer something actually native, instead of a switch from one bad web based thing to another.
React Native isn't really web based. It draws real, native UI elements, not HTML.
Still a web framework though, even if the end result isn't HTML.
The only thing "web" about it is that it uses javascript. Do you want to elaborate how using javascript makes for bad UI?
It's not a web framework. It's a native application framework.
it is not much different from using python with QT on linux for example
whats still a web framework?
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.
Electron doesn't really come at a significant performance cost?
I wonder why Rockstar or Bethesda don't just use electron for their games.
I wonder why Rockstar or Bethesda don't just use electron for their games.
Damn I wonder why they don’t use WinForms or Qt either? Could it be that it’s an entirely different use case than a regular desktop application?
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.
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.
I meant relative to React Native, which isn't suitable for that either. There's plenty of areas where native makes the most sense on desktop.
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.
Messenger did.
Skype on the other hand switched from React Native to Electron.
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.
This fake paradise of "one app to rule them all" is absolute madness to me now.
Lot of people here don't know what React Native actually is
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.
> as long as it's a real standard already installed and kept up to date on 99% of potential user's systems.
Unfortunately, by far the closest thing we have to this is Google Chrome.
Unfortunately, by far the closest thing we have to this is Google Chrome.
I would, except it's not a 'native dialog'; it doesn't yield first class citizen UI interaction, it lives in a tab in the browser.
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?
>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-...
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-...
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 thought Discord is mostly webview-powered, is it not? If so, this change will make very little difference to the user.
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.
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 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.
The iOS app is RN Si makes total sense to bring android along as well.
[deleted]
Knowing little about android dev - does this affect compatibility for older android versions? current discord app works great on android 6
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.
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.
That’s good. Having one app be RN and one native is probably the worst thing you can do.
That said, seems like Android users really dislike this update as the app seems slower, buggier and less polished than it used to be.
That said, seems like Android users really dislike this update as the app seems slower, buggier and less polished than it used to be.
Do they share code between desktop and RN?
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
The bigger wins come from shared tooling/skillset/headspace. Our UI devs can fairly easily jump back and forth between the two codebases
Did you consider using React Native Web?
Interesting, I didn't know about that
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
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
Oh this makes me nervous. Discord on android is slow and bloated and occasionally memory leaky. I have a tasker routine to restart it nightly...
If the app gets any laggier or slower I will probably have to abandon it...
If the app gets any laggier or slower I will probably have to abandon it...
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...
Their reason for switching to react native is to address these issues
That is explicitly not their reason. They want platform parity, as they specify in the article.
Moving from native to react native will almost certainly be slower (unless something in their native app is just very broken).
Moving from native to react native will almost certainly be slower (unless something in their native app is just very broken).
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?