[fbelzile]

I run a bootstrapped desktop productivity software business myself. I'd say the split is somewhere around 70% Windows and 30% Mac (all self-marketing, no app stores). The mobile rush created a huge vacuum in the desktop market that I think enabled people like me to succeed. Not to mention, you're not giving a 30% cut to Apple or Google and can generally charge more than a few dollars for your app.

It's definitely easier for me to develop on Windows. Though, this is mainly because XCode performance is atrocious on my mac mini and packaging apps for outside the app store is pretty tedious. I still use a buggy tool that Apple hides very deeply on their developer portal (it involves installing an ancient version of XCode).

If you require a UI that is pretty heavy, here is my "secret" trick to save time when developing for both Windows and macOS:

1) Buy a basic HTML template online for your app's dashboard.

2) Don't use Electon. Your users WILL notice and complain about performance. Instead, use the native WebBrowser control in .NET for Windows and WebView using macOS to display your UI. Disable right clicking and highlighting using HTML/JS. To the user, it'll feel like any other native app. Add this meta tag to the HTML file to ensure the WebBrowser control knows to use new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge">

3) Use the built in script calling functions to transfer settings back and forth between the UI and main app in JSON. Do the back end stuff in native code.

4) You can then re-use most of the UI code you wrote to easily port over to macOS. Use the same functions and logic you wrote on Windows to make your Swift functions.

Good luck!

[baumandm]

Don't use Electon. Your users WILL notice and complain about performance.

Is this actually true? Slack and Discord are valued at ~$7B and $2B respectively, and neither have found it necessary to move off their Electron apps. I assume both companies have already evaluated whether Electron's performance impacts their their bottom line, and concluded it does not.

Electron is undoubtedly slower and more resource-intensive than other options, but outside of specific audiences (HN readers) I bet most people won't care.

[fbelzile]

You're right. It's a relatively small, but persistent concern people have emailed me about. After a while, the squeaky wheel gets the grease.

I know this because I'm temporarily using a Chrome-based WebBrowser component for called EO.WebBrowser (for edge-case reasons). I'm working on going back to the native WebBrowser control after getting about a few emails a month of emails asking about RAM usage.

It also shows up in the uninstall comments. Quote from a real comment: "The app works, but it uses a lot of RAM."

Slack and Discord are used for work, which might make users think of it a necessary evil. Paying for software yourself that you don't absolutely need and having it use lots of your RAM is a different story.

[nickjj]

> Electron is undoubtedly slower and more resource-intensive than other options, but outside of specific audiences (HN readers) I bet most people won't care.

I think it makes even more of a difference for people outside of the HN audience.

A non-technical person might grab a $400 laptop from Costco with 4gb of RAM which is fairly common.

All it takes are a few Electron apps to exhaust that entire system's resources.

[baumandm]

Fair points.

All I was trying to say was that Electron and other technical decisions should be evaluated by their actual business impact, which vary from app to app.

[anoncake]

But will a non-technical person know which apps are to blame?

[nickjj]

They will be able to determine "before I installed this app everything was good but now it's not" and then they will proceed to blame your app (with good reason).

[ww520]

This is great advice. The HTML/CSS/JavaScript with native browser control is spot on.

[johnmax]

Great, thanks for the numbers and the advice.