[tomduncalf]

I’ll be interested to see how React Native on desktop progresses.

The developer productivity and consistency gains of working on one codebase rather than 2 or 3 cannot be argued with, and I’m confident more and more software will be moving in this direction regardless of the opinion of (what is probably) a fairly small number of hardcore users.

However, I do agree that Electron can give a sub-optimal experience compared to a native app in many cases. React Native could potentially provide a good compromise - write your app in JS but it renders using native UI widgets, resource usage is lower because it’s just using a JS engine rather than a full browser.

It would probably be more work than Electon because each platform will have differences in how it renders, but much less work than building separate native apps.

Last time I checked on RN on MacOS (well over a year ago) it was quite immature, but with Microsoft pushing it on both Windows and Mac, it could become a realistic option soon (if it’s not already).

Not sure if there’s anything on Linux? You could maybe fall back to Electron, with the the UI rendered via react-native-web to turn it back to HTML.

[ChrisMarshallNY]

Native will always give the richest user experience, and deliver the most up-to-date tech.

That said, most applications are really windows onto server-based algorithms, so the need for a “pure native” UX is a lot less, these days, than it used to be.

The one big skunk at the hybrid picnic is that we are “dancing with a gorilla.” That means that we don’t get to change the step, or stop, until the gorilla says so.

If we are dependent on any external framework (not just ones like Electron or RN), then we are at their mercy, wrt to adapting to platform and environmental changes.

I know folks that have written code that won’t run on current versions of the OS, because an SDK they use, has not been updated.

[Sebb767]

> Native will always give the richest user experience, and deliver the most up-to-date tech.

No. It could, but when there's only one developer working on that app for three platforms and they prioritize Windows, you gain nothing.

Native will, of course, be a bit faster and have more features, but for that you need to have a dedicated developer that knows the specialities and can make use of them. But if you want to have a mostly up-to-date app with a small developer team, cross-platform apps will be a better experience.

[microtonal]

Native will, of course, be a bit faster and have more features, but for that you need to have a dedicated developer that knows the specialities and can make use of them.

This is why a lot of people are upset. AgileBit was that dedicated developer that developed top-tier macOS apps (like OmniGroup). Many people have poured hundreds of dollars into their product because it was such a great Mac app.

And now that people are locked into cloud storage and a subscription [1] and AgileBits suddenly morphs from an independent Mac developer into a VC-funded Electron developer, a lot of people feel betrayed. Of course, perhaps people shouldn't be surprised, AgileBits is a business after all. But the AgileBits founders always projected this image of being a community and of them cherishing their users.

Who knows, maybe they still care and genuinely think this is the best choice for their Mac users, in which case there is a serious disconnect. Or perhaps, they are not that nice, warm company anymore and this is just a cold business choice.

[1] Which adds to the irony, because one of the main arguments for subscriptions is always that it brings in continuous funding for development, allowing continuous roll-out of new features to users.

Turns out that before subscriptions, Mac users would just not buy the new Electron version and it would hurt AgileBits. With subscriptions, Mac users can hate the Electron version and they will pay for it anyway.

[benhurmarcel]

> And now that people are locked into

It doesn’t take a lot of effort to switch password manager, there’s no significant lock-in.

[ChrisMarshallNY]

> when there's only one developer working on that app for three platforms and they prioritize Windows, you gain nothing.

Which is why hybrid is so popular. It’s not a good idea, generally, to have one developer, working native, on all platforms. You need a team. A fairly expensive team.

I ran a team that provided “engine” code (C++) for native apps (on a couple of platforms) for decades.

I’m fairly familiar with the trade-offs.

[ryandrake]

> I ran a team that provided “engine” code (C++) for native apps (on a couple of platforms) for decades.

Same here. The best approach I’ve seen is code is 80-95% C++ business logic, plus a small platform-specific GUI shim in the native language to keep the nice platform look and feel. All the major PC and mobile platforms still can call into and out of C and C++. This is the way! It has been tried and true for years.

[ChrisMarshallNY]

Yup.

[tomduncalf]

> Native will always give the richest user experience, and deliver the most up-to-date tech.

Oh yeah, not arguing with that at all. But I think the commercial reality is a lot of companies will think the trade off of using a cross platform framework like Electron is worthwhile, the UX is “good enough” for most users and the development process is much more efficient.

Of course, users might vote with their feet and go to other apps which are native, but I suspect this trend is here to stay and so it’s good to consider what the “least bad” hybrid option is.

[ChrisMarshallNY]

It’s not a new trend at all.

Cross-platform app frameworks have been around for decades.

One of the nice things about writing native on Apple, is plugging into the latest tech. Not always a big deal, but there are some apps that use that as their biggest selling point.

Also, if we are doing low-level stuff (like Bluetooth connectivity), the app framework can be a very stubborn gorilla.

[tomduncalf]

All great points.

One thing I’d say in regard to low-level stuff is React Native allows you to fairly easily call into native code with its native modules functionality.

I work on a iOS/Android music learning app with a C++ audio engine and React Native UI (and Unity for the interactive parts) and it works quite well, for example we call into native code for connecting to Bluetooth hardware.

But you are right, given enough developers and time, native is probably always going to deliver an end result which feels more “right” on the platform.

[sofixa]

> Native will always give the richest user experience, and deliver the most up-to-date tech.

Really? Hoping your user has updated their OS to ger the latest version of the toolkit/SDK/etc. to be able to "deliver the most up-to-date tech" vs being completely dependent on tooling you fully control ( framework, Chromium/Electron version, etc.). I forget the name of Apple's latest UI kit, but it doesn't work on macOS versions below the latest/latest-1. How can you deliver the latest tech then?

[ChrisMarshallNY]

It’s always a trade-off; regardless of the infrastructure that we choose.

The #1 imperative, is that the app must work on the current shipping OS. It doesn’t have to be “studly,” but it needs to work, and work well. On Mac and iOS, that’s a lot more important than on Android/Windows.

[gorbypark]

React Native on Windows and macOS works decently well these days. The macOS port is lagging behind the Windows one, but only by one major version. There are still some third party modules that don’t work on the desktop ports, but the support is getting better by the day. I have one small app in production that supports Android/iOS/Windows/macOS and web, all in one code base. Definitely a game changer, especially with how magically good React Native Web works. I’m using RNWeb for web-only projects, it’s that good!

[tomduncalf]

Nice. I will have to give it another try. One thing that was a blocker for me at the time was no react-native-svg on Mac for rendering custom UI widgets. Doesn’t look like this has been resolved yet but that was quite a specific use case I had.

[gorbypark]

It seems that macOS support was added to react-native-svg in version 12.1.1 (which is the latest version), it appears they just haven't updated the docs/README yet to reflect that. See https://github.com/react-native-svg/react-native-svg/release...

[tomduncalf]

Oh this is super cool! Thanks so much for sharing :D

[Fire-Dragon-DoL]

Any news about it for linux (gnome or kde?)

It's frustrating not being able to develop something for the 3 oses i use at once (windows, linux, android)

[gorbypark]

There are a few half-finished and seemingly abandoned ports to linux. React-native for Windows/macOS is being developed by Microsoft to support their Office teams (afaik, some screens in Office for mobile are react-native, and they want to use it on the real desktop version as well). Unfortunately since Office isn't available for linux, Microsoft isn't doing a port as well.

[Fire-Dragon-DoL]

That's sad, but I can see that making sense.

[tomduncalf]

A fallback option for Linux could be to render the React Native app to HTML/CSS/JS using react-native-web, then package it in an Electron app. Depending on the level of native integration this could be tricky though.