
Why we maintain desktop apps for OS X, Windows, and a web application - mathouc
https://medium.com/@collinmathilde/why-desktop-apps-are-making-a-comeback-5b4eb0427647
======
vbezhenar
What I don't like is WebView distributed as a "native app". It's not native
app and it's not something I want to install, don't cheat me. Webpages should
stay in browser.

I expect native app to be written with Objective C (OS X/iOS user here),
having very low memory usage, fast startup and offline usage. Also I expect as
much integration with the system, as possible, native controls (not that buggy
emulation without my favorite emacs-like keybindings) and native behavior.

Probably we miss an important piece of technology: installable web-apps.
Website opened in the frameless browser window, identifiable as a different
application which could be easily pinned to Launchpad. With all advantages
that "separate webview" has, but with some important difference: sandboxing.
So I can feel safe when I launch this application, because I don't need to
trust all my files, passwords and system to another application. I've seen
that kind of technology in the iOS: website bookmark could be pinned as a
desktop icon, but it's just a bookmark.

~~~
zippergz
This is what I hate about Slack. It feels like a webapp inside of a very thin
wrapper.

~~~
stephenr
This type of app really bites us (users) in the ass when we try things real
Mac apps have done literally for decades - drag and drop. Drag a file
expecting it to be accepted as an upload, but oh wait no, the web view
navigated to view that file. And I have no back button so I have to quit the
app.

~~~
totallynotcool
That's an issue as most webviews can ad a bit of js and support that feature.
I'd email the dev a bug report.

------
saurik
> At Front for example, people using the desktop app spend on average 34% more
> time on the app that those using the web version.

...maybe I'm crazy, but the primary metric I would evaluate a tool designed to
increase business productivity is not how much time I spend using it, and in
fact would normally be summarized as the exact opposite of this metric...

~~~
gberger
Also, correlation/causation.

It could be that the people who download the desktop app are already the heavy
users.

~~~
prof_hobart
In this case, I'm not sure that's an important distinction.

Whether it's the desktop app driving increased usage or it's heavy users
preferring the desktop app, it suggests that one way or another, the desktop
app is better for heavy usage.

------
hyperion2010
The alt-tab argument is a strong reminder for me that as good as tabbed
browsing is compared to the old IE6 hell, tabs are an absolutely shit paradigm
for window management, better than the windows task bar when you have 100 tabs
open, but it is about time someone sat down and did real and serious UI
research on how to deal with having 100s of windows open at the same time,
because my solution of having 32 virtual desktops can't be it.

~~~
pknight
are you using Windows 10? I'm wondering if the virtual desktops feature was
going to make my life easier managing tons of windows. Your comment doesn't
sound very encouraging.

~~~
hyperion2010
Nah, fluxbox with custom control scripts.

------
BinaryIdiot
I love it when companies make software that I use on my mobile phone and it
syncs with a desktop application as well. As a web developer I appreciate web
applications but the experience is almost always better in a native
application (at least I've found very few exceptions).

So I'm happy companies like this still provide desktop applications. It would
be great if it were more of a trend but I'm not sure that it is yet. If there
were better frameworks to use that would allow code reuse across all platforms
it would certainly make this easier.

~~~
gluxon
> If there were better frameworks to use that would allow code reuse across
> all platforms it would certainly make this easier.

I feel that this is exactly what web applications try to solve in the first
place.

~~~
BinaryIdiot
> I feel that this is exactly what web applications try to solve in the first
> place.

Yeah I think so too but I don't think it really did. Native apps are almost
always so much better. The biggest issue is discovery and installation of
native applications that make the web more approachable.

I'd love to see some better development frameworks that let me use native UI
components to build an application that can share business login across iOS,
Android, Windows, Mac OS X and even Linux. It's kind of a hard problem though.

~~~
hobarrera
Qt? It's your best shot for native win32/osx/*nix apps, and you can reuse lots
of code for the android/ios versions (though you'll have to rewrite the views,
of course).

~~~
BinaryIdiot
Whoa, I've used Qt an very, very long time ago so I knew of its existence but
I had no idea they had iOS and Android ports. I'm going to have to look into
that. Thanks!

Yeah I expect re-writing of views. Honestly I think that's unavoidable and
perfectly fine it would just be nice to keep the business logic everywhere I
go.

------
jayvanguard
The bottom line is that if you care about your users and their experience
you'll make a native app for them. Everything else is a tradeoff. There are
definitely many application areas where the web is effectively their "native"
home so that is all you need but I thought this article did a good job of
laying out when that isn't good enough.

------
hobarrera
On the other end, as a user, I greatly prefer desktop apps, because I don't
"lose" them as much. It's easy to lose a chat tab between lots of browser
windows+tabs. A single IM window is harder to lose.

And then there's the integration: both look&feel and functionality can make a
huge difference.

------
incompatible
"Once they find their place in the Windows Start menu or the Mac OS Dock, they
are always visible."

I don't think this is true anymore in Windows 8+. From my limited experience
in using it, once you install something it disappears into a mass of icons and
is never seen again. If you can remember the name you may be able to search
for it.

~~~
titanix2
Sadly the search is also broken. Not only it often opens too slow so the first
letters of the search are not taked in account (the start menu was blazing
fast in comparison) but to add insult to injury even Windows builtin programs
aren't always displayed in the result search (eg. Powershell ISE). So if you
don't know the program exists and don't know its the path, good luck finding
it.

------
i_am_so_hungry
I have just rediscovered the fantastic FreePascal/Lazarus, and have been
thinking up desktop app projects to build. Cross-compile to Windows, Linux and
OSX with native UI.

------
thoman23
I'd like to hear a little more about how this "recent technology" that she
linked to helps me deploy web apps to the desktop. The
[http://nwjs.io/](http://nwjs.io/) site certainly doesn't have much info on
how it can help for this use case.

~~~
xixixao
Just one click through and you arrive at the README:
[https://github.com/nwjs/nw.js](https://github.com/nwjs/nw.js) (the website is
clearly, unfortunately, geared towards people in the know).

nwjs (node-webkit formerly) is a Chromium wrapper that lets you deploy web
apps as desktop apps, simple as that.

------
akurilin
I've been using slack just fine in the browser, haven't had much of a need for
a desktop version of it.

I can just make a separate chrome instance for it and move it into its own
xmonad workspace and switch to it much more conveniently than through alt-tab.

~~~
ashark
The desktop application for Slack is basically the same thing as having a
dedicated browser window anyway, except probably even heavier-weight, at least
in the OS X version. IIRC they use the same JS-on-the-desktop toolkit as Atom,
so it's not a desktop application so much as it is a "desktop application". It
eats ~400MB(!!!!) of RAM on my laptop at all times and I'm sure the only
reason it isn't painfully unresponsive is because modern machines have
enormous amounts of processing power. Totally unreasonable for what it does.

Even at that, it's still not as rough on system resources as a browser tab
with Asana loaded and left open for a couple days, and all of Google's
"applications" are hogs of course. Web Apps: the way of the future! [gag, gag,
vomit]

~~~
tlinton
V8 has an odd habit of not releasing memory back to the OS after mark-and-
sweeps. It's a minor performance boost to let it roll up memory and it isn't
uncommon for it to hog up as much memory until a heuristic (or an OS signal)
tells it to knock it off.

~~~
ashark
Apparently "hey, I'm trying to use this 4GB machine for actual work with a
couple VMs running and you're driving me in to swap hell" didn't come through
as "knock it off".

And that's the story of why I have an 8GB machine now :-/

------
jblok
Wow, there's a lot of hybrid hating here.

Consider this though:

• You have an app that doesn't need to perform actions in sub 10-milliseconds.
11 milliseconds is just fine.

• You don't require access to a whole host of system processes, but maybe
access to the file system, or the clipboard, would be a big help to your
users.

• Your users are not super technical and won't even know what a hybrid app or
native app means.

• You want to get your app to market on multiple platforms in days/weeks, not
months, and without spending a ton of money.

I think hybrid might be a good option there. Not the ultimate best ever piece
of software ever I know, but compromises and all that.

~~~
sandofsky
> You have an app that doesn't need to perform actions in sub 10-milliseconds.
> 11 milliseconds is just fine.

Except you're looking at 3 seconds to power up your cell radio, before you can
actually download the HTML.

> You don't require access to a whole host of system processes, but maybe
> access to the file system, or the clipboard, would be a big help to your
> users.

Until you need more, at which points you're spending all your time extending
your hybrid framework.

> Your users are not super technical and won't even know what a hybrid app or
> native app means.

They do know "it's slow," in the case of Facebook.

> You want to get your app to market on multiple platforms in days/weeks, not
> months, and without spending a ton of money.

Until you spend six months rewriting all your apps.

Hybrid apps, on mobile, trade short term gains for long term maintenance
nightmares. On the desktop, with a high bandwidth connection, and lots of
power, they're less bad.

With a well written model layer on an iOS app, maintaining a desktop UI for
most apps is the work of one or two developers. Sadly, desktop usage isn't
worth it for most consumer facing startups. I've accepted that business
reality.

~~~
EGreg
_Except you 're looking at 3 seconds to power up your cell radio, before you
can actually download the HTML._

You can cache all files in the app bundle with Cordova so the download happens
during the install.

 _Until you need more, at which points you 're spending all your time
extending your hybrid framework._

Cordova makes it easy to build bridges through plugins. Moreover this promotes
proper separation of concerns which lets you use the SAME view layer on
different platforms, changing only the "client api bindings". It lets you
truly think through a crossplatform system design AND the business logic of
whether you'd like your invited users to start on the web experience and
download the app for that + expanded functionality. So it informs your
business model as well.

 _They do know "it's slow," in the case of Facebook._

When Zuck said that HTML5 was a mistake, Sencha made fastbook demo three years
ago to show that facebook could have been sped up and was slow for a different
reason. Since then it's been three years and two generations of phones. Things
are even better now.

[https://www.sencha.com/blog/the-making-of-fastbook-an-
html5-...](https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-
story/)

 _Until you spend six months rewriting all your apps. Hybrid apps, on mobile,
trade short term gains for long term maintenance nightmares. On the desktop,
with a high bandwidth connection, and lots of power, they 're less bad. With a
well written model layer on an iOS app, maintaining a desktop UI for most apps
is the work of one or two developers. Sadly, desktop usage isn't worth it for
most consumer facing startups. I've accepted that business reality._

Business reality you say? Well at least for mobile, it's this:

[http://blog.venturepact.com/8-high-performance-apps-you-
neve...](http://blog.venturepact.com/8-high-performance-apps-you-never-knew-
were-hybrid/)

Hybrid apps have 20% HIGHER RATINGS in the app store than native.

Many top companies heavily use WebViews.

MacGap is getting better and this will become standard for the desktop, too.

Take our own Calendar app for example. It has over 60,000 active users in any
given month ([http://qbix.com/calendar](http://qbix.com/calendar)) and having
WebViews would SIMPLIFY our port to iOS and Android. Here is what we wouldn't
have to rewrite and additionally maintain:

1) The view layer incl all reusable components 2) Caching of view models 3)
The server side communication, incl websockets and realtime

And we get one more bonus:

4) Invited users can click a link and instantly get an account on the web,
after which we can send them transactional notifications until they sign up.
As opposed to being taken to an app store with a description, pictures and
some ratings. Higher virality for the win!

~~~
sandofsky
> You can cache all files in the app bundle with Cordova so the download
> happens during the install.

Now your apps is resembling a native app, but a whole lot more complicated.

> Cordova makes it easy to build bridges through plugins.

Everyone I've talked to who went down this path regretted it.

> Moreover this promotes proper separation of concerns which lets you use the
> SAME view layer on different platforms, changing only the "client api
> bindings".

Except views are ultimately platform dependent. You've created a leaky
abstraction.

> Business reality you say? Well at least for mobile, it's this:
> [http://blog.venturepact.com/8-high-performance-apps-you-
> neve...](http://blog.venturepact.com/8-high-performance-apps-you-neve..).

That article lists Twitter, which is wrong. I was the tech lead.

(It's also wrong about half the other apps on the list)

~~~
thekingshorses
> I was the tech lead.

How big is the iOS team at Twitter? This is old picture
([https://pbs.twimg.com/media/BYBiL8MCUAAiB7r.jpg](https://pbs.twimg.com/media/BYBiL8MCUAAiB7r.jpg))

------
rhaps0dy
A nice insight at the end of the article that I'd never realized (it might be
obvious to you).

>as long as you browse the web, you keep coming back to google.com to navigate
efficiently. This is why Google wants you to spend time in a browser. This is
why they offer Gmail for free, Chrome for free, Chromebooks at a loss, or why
they fund their own competition!

------
alagappanr
This approach is probably in complete contrast to what Flipkart/Myntra have
been doing in India. Both are widely used e-commerce websites that are going
complete mobile-app only by killing even their desktop and mobile websites.

Two moves in completely different directions. Would be interesting to see the
results down the line.

~~~
ramkalari
Flipkart's customer base is completely different. A large percentage of their
customers will probably never own a desktop let alone access their application
on one. Front is an app targeted for business where the users still use
desktops where it may make sense to have a desktop app.

------
incompatible
I'd say it surely depends on what the "app" is supposed to do. I like to run
Firefox natively rather than as a web app. On the other hand I'll be thrilled
when the local tax office convert their Windows/MacOS software to a web app so
that I can use it on Linux.

------
avinassh
Considering the performance of Atom, is it a good idea to build desktop apps
with Node.js?

~~~
BillinghamJ
Atom's performance problems are not because of Node, they're because they
render with HTML, loading your whole text documents into the DOM as hundreds
of thousands of separate elements.

Using Node JS as the backend to a proper native rendering system would work
fine, and in fact if the application was written to properly handle everything
asynchronously, it may well be faster than an app written entirely in the
native language of the system.

~~~
Tiksi
> it may well be faster than an app written entirely in the native language of
> the system.

So nodejs is now faster than C/C++? I guess Javascript really _can_ do
everything.

~~~
BillinghamJ
No. I said it "may well be", because a naive implementation using a native
language may block while doing IO and be less responsive, unable to do other
things while waiting for external stuff to happen.

Perhaps I should have said "may well be more responsive than".

~~~
hollerith
So, you don't actually know anything about whether native apps block on IO? (I
doubt they do on any modern version of Windows, OS X, Linux, Android, iOS or
Windows Phone.)

~~~
BillinghamJ
Depends entirely on the developer. Most APIs support both non-blocking and
blocking.

------
Wintamute
Slack, Spotify, Atom, React Native ... I think desktop/native apps implemented
using web tech have come on leaps and bounds recently. They started off
clunky, but are now starting to feel like native software imo.

------
codezero
I've been using Front since February and I love it. The desktop app was one of
the key reasons I went with it because it is really fast compared to web
interfaces of other apps I tried out.

------
itsmillertime4u
There are many iOS apps that I wish had equivalent apps on OSX, but sadly they
don't. Ones that come to mind are Netflix, HBO Go, Amazon Video, Amazon Music,
etc.

------
DrScump
"Your users don’t need an authorization to" ... _what_?

~~~
superfad
My guess is she means they don't need authorization to install it if it is a
web app, where as a desktop app may need company sign off to install software.

~~~
hobarrera
In any case, if a company is using an app like theirs (FrontApp), it would be
stupid for IT not to authorize employees to install it. The particular point
really doesn't apply to this sort of tools.

~~~
cwyers
It's more friction. Instead of waiting for IT to approve something when they
get around to it, if in fact they do approve it at all, you can start using it
now.

------
nsgi
Installable webapps cover at least the first two points.

~~~
adrusi
If you distribute your app for desktop, users will install it no matter what,
but with installable webapps users won't install it until it's already part of
their routine.

Of course, users are more likely to try out your app if they don't have to go
through an installation process first, so it's a tradeoff.

------
unimpressive
Bad article title. Doesn't even attempt to show a statistical trend that
they're 'coming back' (I would argue with the existence of app stores and the
like that they never really left). _Does_ talk about the authors experience of
offering a desktop app which is very interesting.

~~~
dang
Ok, we changed the title to a representative sentence from the article.

