5 ms·

There's a lot of discussion in the comments here about Electron vs. native apps. But last year's Catalyst project, which allows you to ship iOS-based projects o

There's a lot of discussion in the comments here about Electron vs. native apps. But last year's Catalyst project, which allows you to ship iOS-based projects on the Mac, opens an important new path. I've been surprised not to see many people discuss it! In particular, this means that you can use React Native to build native macOS apps. You still get live reloading, hot code push, pleasant abstractions, etc. Most importantly, though, these apps can use straight-up AppKit controls on macOS and straight-up UIKit controls on iOS. Better still, you can use react-native-web to ship such projects on the web too. You will+should, of course, have many platform-specific branches. But I find that the vast majority of my code is shared, and there's a _world_ of difference in being able to use the same development tools to ship polished software on desktop, mobile, and web. My most recent project builds to macOS, iOS, Android, and web out of the same Typescript project. There was certainly some toolchain chicanery involved in this, but now that it's set up, it's delightful. Many of the companies shipping Electron apps on desktop are shipping React Native apps on mobile. I would very much like to see React Native-based desktop apps replace Electron apps.

ViViDboarder 7y ago
So what would you suggest then for the non-Mac desktops? Are there React Native based solutions for Windows and Linux?
- scarlac 7y ago
  Yes, at least officially for Windows. The official fork: https://github.com/microsoft/react-native-windows https://github.com/microsoft/react-native-windows
- andymatuschak 7y ago
  I can't suggest anything, I'm afraid—I haven't worked with Windows and Linux targets using React Native. But it appears that there are React Native rendering targets for Windows and Linux (https://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows and https://github.com/status-im/react-native-desktop https://github.com/status-im/react-native-desktop). I'd probably start by looking there. And of course, because React Native can build to web, one could ship Electron apps for platforms with lower priority for your business.
tonyonodi 7y ago
What app are you using it for? Is it public (yet)?
- andymatuschak 7y ago
  An unannounced project. Certainly this thread would be more interesting if I could point you to an app or even a codebase!
debt 7y ago
Catalyst is pretty weak. I think that's why Electron and RN are still more appealing.
- andymatuschak 7y ago
  What are you finding weak? There are certainly quirks, but I'm enjoying it relative to the alternatives!
lioeters 7y ago
Thanks for the comment - I wasn't aware of Catalyst, or that React Native is now actively integrating with it to support building native apps that run on iOS + macOS. Here's the most prominent issue I found that's tracking progress: https://github.com/react-native-community/discussions-and-proposals/issues/131 https://github.com/react-native-community/discussions-and-pr... It does require macOS 10.15, so I imagine it will take time for the late majority and laggards (I am one) to catch up to the latest goodness. --- As much flak as Electron gets, I think it serves/served a purpose by opening up cross-platform app development to a wider audience, lowering the bar for better or worse. Commonly raised complaints about CPU/memory usage, file size, non-native UI, seem unavoidable due to the need of bundling Chromium. (Unless someone figures out a standard way to use a single shared install of the runtime.) With React Native, it's also paving the way for a huge audience of developers who otherwise might not have been able to build cross-platform mobile apps. I'm one of them, very excited for the opportunities. > ..live reloading, hot code push, pleasant abstractions.. apps can use [native UI] controls.. > ..use the same development tools to ship polished software on desktop, mobile, and web. > builds to macOS, iOS, Android, and web out of the same Typescript project Indeed this sounds like a delightful way forward! Edit: I wonder, what's the story with Linux native apps? Ah, mentioned in a sibling comment, React Native Desktop: https://github.com/status-im/react-native-desktop https://github.com/status-im/react-native-desktop
nerder92 7y ago
The same is true for Flutter also, since the desktop support for both MacOS, Windows & Linux is available in the master channel at the moment. Actually I prefer this future instead of a JS dominated world.
- andymatuschak 7y ago
  Ah, but what I like about React Native for desktop is that I can render native AppKit controls and create an application which looks truly at home on macOS. Flutter, as I understand it, doesn't aim to provide access to native controls. Just as an example, it would be quite challenging to duplicate the effect of the blurring effect view used by macOS sidebars and the hyper-saturated "vibrancy effects" of controls on top of it: https://developer.apple.com/design/human-interface-guidelines/macos/visual-design/translucency/ https://developer.apple.com/design/human-interface-guideline...
me551ah 7y ago
Xamarin Forms is another brilliant option. Out of the box it can target Android, iOS and Windows. If you use catalyst then the iOS app can be ported to MacOS. C# is a nice language to use too.
sgt 7y ago
As a user I don't want a React app. I want a native app. I can understand why you as a developer don't have time to maintain the different platforms, but for a UI app running on my laptop or desktop I care about one platform and that is macOS. It's okay if it's Mac only and many apps are.
- scarejunba 7y ago
  Yeah, but let's be honest. Most users don't want a specific app. They want functionality. They'll pay for functionality in a React App while eschewing a native app without the functionality. The practice of this means solving the problem the fastest is the most important part. And if someone can rapidly build a native app so be it, but if they can only rapidly build React apps that's what they should do. Or they can do otherwise and they'll learn.
  - franga2000 7y ago
    > Yeah, but let's be honest. Most users don't want a specific app. They want functionality True, but they also want to be able to run it without bringing their crappy laptop to a crawl. Devs excuse their inefficient code with "modern hardware is fast enough", but it ceases to be fast enough when the majority of your apps are inefficient. Try running Slack, Discord, Skype, Spotify and a couple Chrome tabs on a last-gen laptop. And now try to run something actually useful (Office, a game, whatever). You can't. I've seen completely non-technical users say "ugh, another web app". Alternatives are few, so users won't use something else, true, but that's not an excuse to keep making inefficient apps. (I realize this doesn't apply nearly as much to React Native, but only React was mentioned above and this is a rant I've had prepared for a while now...)
- ex3ndr 7y ago
  React app is a native app. JS performance is ~the same in UI part - just declare what you want to display and native part will do the rest. It is much much easier to write slow AppKit code than RN one. Actually it is really hard to achieve decent performance with AppKit.
memco 7y ago
There was a recent article from FB about the performance improvements of going native: https://news.ycombinator.com/item?id=22466462 https://news.ycombinator.com/item?id=22466462. I don't know what they were using before and I don't write React Native apps so I don't know how these two pieces of information intersect. But, if they were using React Native before and saw such big gains from moving away is it worth moving away from Electron to something that is still less performant than fully native?

ViViDboarder 7y ago

So what would you suggest then for the non-Mac desktops? Are there React Native based solutions for Windows and Linux?

scarlac 7y ago
Yes, at least officially for Windows. The official fork: https://github.com/microsoft/react-native-windows https://github.com/microsoft/react-native-windows
andymatuschak 7y ago
I can't suggest anything, I'm afraid—I haven't worked with Windows and Linux targets using React Native. But it appears that there are React Native rendering targets for Windows and Linux (https://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows and https://github.com/status-im/react-native-desktop https://github.com/status-im/react-native-desktop). I'd probably start by looking there. And of course, because React Native can build to web, one could ship Electron apps for platforms with lower priority for your business.

tonyonodi 7y ago

What app are you using it for? Is it public (yet)?

andymatuschak 7y ago
An unannounced project. Certainly this thread would be more interesting if I could point you to an app or even a codebase!

debt 7y ago

Catalyst is pretty weak. I think that's why Electron and RN are still more appealing.

andymatuschak 7y ago
What are you finding weak? There are certainly quirks, but I'm enjoying it relative to the alternatives!

lioeters 7y ago

Thanks for the comment - I wasn't aware of Catalyst, or that React Native is now actively integrating with it to support building native apps that run on iOS + macOS. Here's the most prominent issue I found that's tracking progress: https://github.com/react-native-community/discussions-and-proposals/issues/131 https://github.com/react-native-community/discussions-and-pr... It does require macOS 10.15, so I imagine it will take time for the late majority and laggards (I am one) to catch up to the latest goodness. --- As much flak as Electron gets, I think it serves/served a purpose by opening up cross-platform app development to a wider audience, lowering the bar for better or worse. Commonly raised complaints about CPU/memory usage, file size, non-native UI, seem unavoidable due to the need of bundling Chromium. (Unless someone figures out a standard way to use a single shared install of the runtime.) With React Native, it's also paving the way for a huge audience of developers who otherwise might not have been able to build cross-platform mobile apps. I'm one of them, very excited for the opportunities. > ..live reloading, hot code push, pleasant abstractions.. apps can use [native UI] controls.. > ..use the same development tools to ship polished software on desktop, mobile, and web. > builds to macOS, iOS, Android, and web out of the same Typescript project Indeed this sounds like a delightful way forward! Edit: I wonder, what's the story with Linux native apps? Ah, mentioned in a sibling comment, React Native Desktop: https://github.com/status-im/react-native-desktop https://github.com/status-im/react-native-desktop

nerder92 7y ago

The same is true for Flutter also, since the desktop support for both MacOS, Windows & Linux is available in the master channel at the moment. Actually I prefer this future instead of a JS dominated world.

andymatuschak 7y ago
Ah, but what I like about React Native for desktop is that I can render native AppKit controls and create an application which looks truly at home on macOS. Flutter, as I understand it, doesn't aim to provide access to native controls. Just as an example, it would be quite challenging to duplicate the effect of the blurring effect view used by macOS sidebars and the hyper-saturated "vibrancy effects" of controls on top of it: https://developer.apple.com/design/human-interface-guidelines/macos/visual-design/translucency/ https://developer.apple.com/design/human-interface-guideline...

me551ah 7y ago

Xamarin Forms is another brilliant option. Out of the box it can target Android, iOS and Windows. If you use catalyst then the iOS app can be ported to MacOS. C# is a nice language to use too.

sgt 7y ago

As a user I don't want a React app. I want a native app. I can understand why you as a developer don't have time to maintain the different platforms, but for a UI app running on my laptop or desktop I care about one platform and that is macOS. It's okay if it's Mac only and many apps are.

scarejunba 7y ago
Yeah, but let's be honest. Most users don't want a specific app. They want functionality. They'll pay for functionality in a React App while eschewing a native app without the functionality. The practice of this means solving the problem the fastest is the most important part. And if someone can rapidly build a native app so be it, but if they can only rapidly build React apps that's what they should do. Or they can do otherwise and they'll learn.
- franga2000 7y ago
  > Yeah, but let's be honest. Most users don't want a specific app. They want functionality True, but they also want to be able to run it without bringing their crappy laptop to a crawl. Devs excuse their inefficient code with "modern hardware is fast enough", but it ceases to be fast enough when the majority of your apps are inefficient. Try running Slack, Discord, Skype, Spotify and a couple Chrome tabs on a last-gen laptop. And now try to run something actually useful (Office, a game, whatever). You can't. I've seen completely non-technical users say "ugh, another web app". Alternatives are few, so users won't use something else, true, but that's not an excuse to keep making inefficient apps. (I realize this doesn't apply nearly as much to React Native, but only React was mentioned above and this is a rant I've had prepared for a while now...)
ex3ndr 7y ago
React app is a native app. JS performance is ~the same in UI part - just declare what you want to display and native part will do the rest. It is much much easier to write slow AppKit code than RN one. Actually it is really hard to achieve decent performance with AppKit.

memco 7y ago

There was a recent article from FB about the performance improvements of going native: https://news.ycombinator.com/item?id=22466462 https://news.ycombinator.com/item?id=22466462. I don't know what they were using before and I don't write React Native apps so I don't know how these two pieces of information intersect. But, if they were using React Native before and saw such big gains from moving away is it worth moving away from Electron to something that is still less performant than fully native?