4 ms·

I make a living developing software only available on Windows and macOS. That said, if I didn't need to interact so much with the operating system, I'd be makin

I make a living developing software only available on Windows and macOS. That said, if I didn't need to interact so much with the operating system, I'd be making a web app. It all depends on what you want to make though. Video editing software? Native app. CRUD app? Web app. You may also want to consider pricing implications of both. Desktop software can usually be sold for a higher up front cost, but it's tough sell to make it subscription based. SaaS would make your life a lot easier if you have a webapp. People are starting to get used to paying monthly for a service anyway. Pro tip: If you decide to make a native app, don't use Electron. Instead, use the built-in WebBrowser/WKWebView components included in .NET and macOS. Create the UI once using whatever web framework you want, and code the main app logic in C#/Swift. Although the WebBrowser control kind of sucks right now, Microsoft is planning on releasing WebBrowser2 which will use Blink. I think they might also have it where the libraries are shared between all apps using it, to further reduce bloat. The old WebBrowser component can be configured to use the latest Edge rendering though by adding in some registry keys or adding this meta tag: <meta http-equiv="x-ua-compatible" content="ie=edge">

dvdhnt 6y ago
> Pro tip: If you decide to make a native app, don't use Electron. Instead, use the built-in WebBrowser/WKWebView components included in .NET and macOS. Create the UI once using whatever web framework you want, and code the main app logic in C#/Swift. Although the WebBrowser control kind of sucks right now, Microsoft is planning on releasing WebBrowser2 which will use Blink. I think they might also have it where the libraries are shared between all apps using it, to further reduce bloat. The old WebBrowser component can be configured to use the latest Edge rendering though by adding in some registry keys or adding this meta tag: > > > <meta http-equiv="x-ua-compatible" content="ie=edge"> Great to know, thank you.
OkGoDoIt 6y ago
I understand the concept of making a native app to include using the native UI platforms. What you described is hardly more native than electron, which is basically a web app at heart. Or maybe there needs to be a consensus on terms. Do people consider electron apps to be native? I would put them in some weird middle ground, but definitely closer to web technologies than native development.
- enos_feedler 6y ago
  With Electron, it feels more like starting from web and making it behave like a native app, from the standpoint of operating system app handling (task bar, notification). It can also fill a gap left by web for exposing a filesystem and other things that are native to some abstract computer. Using WKWebView for UI is different in that you are starting from a native app and using web technologies to leverage code sharing and programming model of the user interface (js, css, html). I think for this view to make sense you have to see web apps and native apps as fundamentally different things, which I believe they are.
- arithma 6y ago
  From a capabilities point of view, they're native. You can access the OS api just like any other native app. From a developer side, it looks like developing a webapp without the usual limitations of API access, albeit at an extra cost of marshaling or build-complexity. There really is no reason to think of HTML/CSS/JS as Web only though.
- neurostimulant 6y ago
  The main complain about electron app is due to their bundling of complete web browser runtime, which is over a hundred of MB, not to mention the big memory requirements. By using platform's built-in webview component, your app size will hardly any bigger than the total size of the zipped html+js+css of your app. If you're going to use web stack to develop your desktop app anyway, might as well try using native ui webview first if you don't need any electron-specific feature.
antaviana 6y ago
We sell our B2B desktop software as a subscription since 2012 (previously it was freeware). The key is to make it only available as a subscription (no permanent licenses) and it does not have any cloud component. We managed not to fall in the trap of making two types of licenses (suscription or permanent) to maximize early revenue (we could affort to wait). We seek a marriage relationship with our users not a hook up. This increases the value our users extract knowing it will not go away in the long term and the lifetime value of customers is a lot higher. We know that some customers will not accept a subscription-only desktop application but in B2B world they are fewer than it might seem.
doteka 6y ago
For a personal project I am currently using this approach and can confirm it works great. I wrote just enough PyObjC to get myself a trayicon in the Mac menu bar, which shows a popover containing a wkwebview to localhost. Then I have all the app logic in Python, exposed to the webview through a bottle server, and Svelte for the UI. Highly recommended.
- CameronNemo 6y ago
  Do you distribute Python with your application too then? How well does that work?
  - fbelzile 6y ago
    It sounds like a macOS app, and python is distributed with the OS already. Just watch out for Apple trying to take away scripting language support in the future. There's also an upcoming Python version change in macOS 10.16 to look out for.
    - doteka 6y ago
      I actually use py2app to bundle the whole virtualenv into an .app file. Worked pretty much out of the box after fiddling a bit with pyenv (you have to build your python version with framework support).
mb_72 6y ago
Great to read about someone in a similar situation to me. I work as the developer and maintainer of a niche-market financial / real-estate application. This application has been developed and supported since the late 80s, first being done in Turbo Pascal, then Delphi, and then under my stewardship we moved to C#. I refactored the calculation and report production code into a library, and since that time we've built a Mac version and Web version, all utilising the same 'core' library. This means that for critical calculations and data output we - my business partner, who is the 'domain brains', and I - can do all the hard work on the Windows version (with which we are most familiar and comfortable, and IMO VS on Windows is still miles ahead of VS on Mac), and then 'just' do the GUI work for the other versions. We did look at doing exactly as you said, i.e. using a web view within Windows and Mac, however I couldn't really get things working well enough at the time (as TBH I am bit of a noob WRT web development, and just pick things up as necessary as we go along). For our market, there is strong demand for the desktop versions, and this is even with a subscription model; people get access to the most recent major and minor versions of the software as well as phone and email support while under subscription. When their sub runs out they are entitled to minor version updates, but nothing else. My biz partner is very good with people and very knowledgeable in the domain we operate, so this kind of arrangement suits everybody. Oh, and I get to work remote, and have done with him for ~15 years. The current situation really makes one appreciate fortunate arrangements such as this.

dvdhnt 6y ago

> Pro tip: If you decide to make a native app, don't use Electron. Instead, use the built-in WebBrowser/WKWebView components included in .NET and macOS. Create the UI once using whatever web framework you want, and code the main app logic in C#/Swift. Although the WebBrowser control kind of sucks right now, Microsoft is planning on releasing WebBrowser2 which will use Blink. I think they might also have it where the libraries are shared between all apps using it, to further reduce bloat. The old WebBrowser component can be configured to use the latest Edge rendering though by adding in some registry keys or adding this meta tag: > > > <meta http-equiv="x-ua-compatible" content="ie=edge"> Great to know, thank you.

OkGoDoIt 6y ago

I understand the concept of making a native app to include using the native UI platforms. What you described is hardly more native than electron, which is basically a web app at heart. Or maybe there needs to be a consensus on terms. Do people consider electron apps to be native? I would put them in some weird middle ground, but definitely closer to web technologies than native development.

enos_feedler 6y ago
With Electron, it feels more like starting from web and making it behave like a native app, from the standpoint of operating system app handling (task bar, notification). It can also fill a gap left by web for exposing a filesystem and other things that are native to some abstract computer. Using WKWebView for UI is different in that you are starting from a native app and using web technologies to leverage code sharing and programming model of the user interface (js, css, html). I think for this view to make sense you have to see web apps and native apps as fundamentally different things, which I believe they are.
arithma 6y ago
From a capabilities point of view, they're native. You can access the OS api just like any other native app. From a developer side, it looks like developing a webapp without the usual limitations of API access, albeit at an extra cost of marshaling or build-complexity. There really is no reason to think of HTML/CSS/JS as Web only though.
neurostimulant 6y ago
The main complain about electron app is due to their bundling of complete web browser runtime, which is over a hundred of MB, not to mention the big memory requirements. By using platform's built-in webview component, your app size will hardly any bigger than the total size of the zipped html+js+css of your app. If you're going to use web stack to develop your desktop app anyway, might as well try using native ui webview first if you don't need any electron-specific feature.

antaviana 6y ago

We sell our B2B desktop software as a subscription since 2012 (previously it was freeware). The key is to make it only available as a subscription (no permanent licenses) and it does not have any cloud component. We managed not to fall in the trap of making two types of licenses (suscription or permanent) to maximize early revenue (we could affort to wait). We seek a marriage relationship with our users not a hook up. This increases the value our users extract knowing it will not go away in the long term and the lifetime value of customers is a lot higher. We know that some customers will not accept a subscription-only desktop application but in B2B world they are fewer than it might seem.

doteka 6y ago

For a personal project I am currently using this approach and can confirm it works great. I wrote just enough PyObjC to get myself a trayicon in the Mac menu bar, which shows a popover containing a wkwebview to localhost. Then I have all the app logic in Python, exposed to the webview through a bottle server, and Svelte for the UI. Highly recommended.

CameronNemo 6y ago
Do you distribute Python with your application too then? How well does that work?
- fbelzile 6y ago
  It sounds like a macOS app, and python is distributed with the OS already. Just watch out for Apple trying to take away scripting language support in the future. There's also an upcoming Python version change in macOS 10.16 to look out for.
  - doteka 6y ago
    I actually use py2app to bundle the whole virtualenv into an .app file. Worked pretty much out of the box after fiddling a bit with pyenv (you have to build your python version with framework support).

mb_72 6y ago

Great to read about someone in a similar situation to me. I work as the developer and maintainer of a niche-market financial / real-estate application. This application has been developed and supported since the late 80s, first being done in Turbo Pascal, then Delphi, and then under my stewardship we moved to C#. I refactored the calculation and report production code into a library, and since that time we've built a Mac version and Web version, all utilising the same 'core' library. This means that for critical calculations and data output we - my business partner, who is the 'domain brains', and I - can do all the hard work on the Windows version (with which we are most familiar and comfortable, and IMO VS on Windows is still miles ahead of VS on Mac), and then 'just' do the GUI work for the other versions. We did look at doing exactly as you said, i.e. using a web view within Windows and Mac, however I couldn't really get things working well enough at the time (as TBH I am bit of a noob WRT web development, and just pick things up as necessary as we go along). For our market, there is strong demand for the desktop versions, and this is even with a subscription model; people get access to the most recent major and minor versions of the software as well as phone and email support while under subscription. When their sub runs out they are entitled to minor version updates, but nothing else. My biz partner is very good with people and very knowledgeable in the domain we operate, so this kind of arrangement suits everybody. Oh, and I get to work remote, and have done with him for ~15 years. The current situation really makes one appreciate fortunate arrangements such as this.