Live data from Hacker News

How Discord achieves native iOS performance with React Native

blog.discordapp.com

21–30 of 115 posts

Re: How Discord achieves native iOS performance with React Native

#21
post #18
post #4

Earlier quoted context omitted.

You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. Bu…

This is the approach used with Kotlin multiplatform development.

I suspect it will be the best way going forward, other approaches all have serious issues.

https://kotlinlang.org/docs/reference/multiplatform.html

Re: How Discord achieves native iOS performance with React Native

#23
post #16

The iOS app of Discord is crappy compared to the Android app. I mean, it's not bad bad, but it's not good, or at least not as good. I wonder why they decided to go this route instead of hiring iOS developers? I could understand if they used the same app for both platforms (like they do with their Electron app, which is also not as good as Ripcord), but since they have a native app for Android...

As far as I know, they use react for both. Where did you hear that they had a native android app?

Re: How Discord achieves native iOS performance with React Native

#24
post #18
post #4

Earlier quoted context omitted.

You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. Bu…

This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms):

- It forces you to think about your business logic vs. UI structure.

- It forces you to make your core logic library easily testable.

- Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly.

- The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM.

- Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well.

Biggest issues?

- Getting inflexible people to learn anything other than JavaScript.

- Getting slow compile times under control.

- Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase.

- Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.

Re: How Discord achieves native iOS performance with React Native

#25
post #23
post #16

The iOS app of Discord is crappy compared to the Android app. I mean, it's not bad bad, but it's not good, or at least not as good. I wonder why they decided to go this route instead of hiring iOS developers? I could understand if they used the same app for both platforms (like they do with their Electron app, which is also not as good as Ripcord), but since they have a native app for Android...

As far as I know, they use react for both. Where did you hear that they had a native android app?

Since their iOS and Android apps are different, and the iOS one is built using React, I just assumed the Android one is native. Why would they build two different React apps? Isn't the entire point that you can share the code?

Re: How Discord achieves native iOS performance with React Native

#26
post #18
post #4

Earlier quoted context omitted.

You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. Bu…

I did not have a great experience with that approach. The now (in)famous DropBox article describes why way better than I ever could: https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cos... My biggest pain points were tooling. For all of Xcode’s faults, C++ and Objective-C debugging and intermingling wasn’t one of them. Android, though, was another story.

Re: How Discord achieves native iOS performance with React Native

#27
post #6

Sounds like React Native causes more work then necessary. Business logic can be easily shared between different platforms, Android, macOS, Windows and iOS. Always the most time is spend to make the app behave right for each platform, so that’s only bit which differs. I am happily writing apps in Swift for Android and iOS

The Swift for Android and iOS makes sense but how do you "easily" share same business logic between those other different platforms?

For that I am using the compiler which allows C#, Go, Swift code to mixed. It’s really great. So with some work you could use existing C# code even in your mobile apps. I am liking it so far :)

Re: How Discord achieves native iOS performance with React Native

#28
post #24
post #18

Earlier quoted context omitted.

I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. Bu…

This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms): - It forces you to think about your business logic vs. UI structure. - It forces you to make your core logic library easily testable. - Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much…

How do you achieve this? Are you using some framework like Qt? Or is it custom?

Re: How Discord achieves native iOS performance with React Native

#29
post #25
post #23

Earlier quoted context omitted.

As far as I know, they use react for both. Where did you hear that they had a native android app?

Since their iOS and Android apps are different, and the iOS one is built using React, I just assumed the Android one is native. Why would they build two different React apps? Isn't the entire point that you can share the code?

The point of React Native is being cross-platform, yes. But you said Android had a native app.

Re: How Discord achieves native iOS performance with React Native

#30
post #24

Earlier quoted context omitted.

This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms): - It forces you to think about your business logic vs. UI structure. - It forces you to make your core logic library easily testable. - Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much…

How do you achieve this? Are you using some framework like Qt? Or is it custom?

As the previous poster mentioned, the UI is all native and written separately for each platform. To populate UI elements you call native calls so there's no UI framework like Qt needed.

We used C++14 which has a pretty good standard library and plugged the holes with some parts of Boost and then standalone libraries like SQLite, json11 and others to provide missing functionality.

Post reply on HN