
Ask HN: Why desktop apps are moving to browser but mobile apps to native? - beefield
This is something I have been wondering fir a while. It looks like on the desktop there is a clear trend of more and more stuff being done in browser instead of native apps . But in the mobile ecosystem everyone are pushing their native apps. Why is this difference?<p>Is it UX differences? Economical incentive differences? Someone with wested interested pushing things in one or both? Just a fashion thing?<p>And is this trend sustainable? Or is that going to reverse or are thing going to migrate into either native or browser apps in both ecosystems?<p>I just do not get my head around why this is happening.
======
jamil7
I've thought about this quite a lot too. I think other people's comments about
fragmentation are quite correct. I'd also just add the UX and DX angle. After
developing and releasing a few apps in SwiftUI and playing around with Jetpack
Compose, to me developing mobile UIs for the web feels much slower in
comparison and end result is always lacking and developer tooling is a little
all over the place. I know it's not that important to everyone but I do feel
that I'm able to produce a much higher quality UI/UX natively and faster than
I could with web technologies. I think there is also just a fundamental
difference in how we use our computers with a mouse and keyboard vs the way we
use our phones, there is a much higher level of fidelity of interactions and
subtle gestures on mobile that are quite hard to replicate on the web, it
always just feels a bit off. Desktop apps with a lot of input and forms and
clicking around suit the web's model much better and I think in that context
the web is excellent. Having said all that I think developers should be free
to choose how they want to develop and distribute their apps as my opinions
aren't shared by everyone, I support opening up more web APIs to make web apps
more useful on mobile as there are likely whole classes of apps that would
work well there.

------
josuepeq
It’s funny how this became the case; Apple pushed Web Apps until they realized
that native App Delivery is a profitable revenue stream.

In 2007, Steve Jobs’ originally intended “iPhone OS” apps to be only browser
based web apps; way before Google uttered the term “Progressive Web Apps.”

Apple’s early web app SDK didn’t win too many fans. As it turns out, users
were not impressed with the contrast between the robustness of first party
native apps, and the lagging fit, finish, and performance of Web apps in
Safari on a 2G device. In 2008, native App Store arrives.

Ever since the App Store debuted with iPhone OS 2, Apple has chose not to
implement and champion improvements in mobileSafari that make Web apps work as
well as they do on Desktop.

This is strategic, App Store is a lucrative business that gives Apple absolute
control over iOS. They heavily promote development for native apps with Swift.
They give developers much more to work with in terms of stimulating user
engagement and tracking; and users prefer the polished experience of a native
app with fewer compromises.

Apple continues to prohibit adding any app with a Web Engine other than
WebKit, hindering any further improvement possible with other Web Engines.
Imagine someone could deploy an app with a modern web engine that allows a
user to have a new web based App Store that bypasses the Apple app review
process.

It took Apple forever to half implement Service Workers and other Progressive
Web App standards.

Apple doesn’t have the same control over what goes on the desktop. It’s a
fragmented mess.

There’s now only two major mobile platforms, but there are PCs with 32-Bit ARM
and x86, 64-Bit ARM64 and X64 processors running variations of Windows, Macs,
and Unix / Linux operating systems. It’s just not economically viable to try
and target them all unless it’s an app that produces content. Users that
produce content usually do so on system resource intensive apps from the likes
of AutoDesk and Adobe on Desktop - but this is also changing.

~~~
dangus
Everybody keeps citing how “Steve Jobs wanted web apps” from Walter Isaacson’s
biography, but I don’t think he was all that strongly dead set against them:

He was against them “partly because he felt his team did not have the
bandwidth to figure out all the complexities that would be involved in
policing third-party app developers.”

[https://www.cultofmac.com/125180/steve-jobs-was-
originally-d...](https://www.cultofmac.com/125180/steve-jobs-was-originally-
dead-set-against-third-party-apps-for-the-iphone/)

In my opinion, I don’t think Steve was actually against an App Store by any
sort of philosophical ideal. He was working with a much smaller Apple was
trying to get a 1.0 product out the door.

The iPhone barely worked long enough to run the demos for the original
keynote. I recall reading that it was a miracle that the software got through
it without crashing. “Web apps” was the excuse for the App Store not being
ready: personally I think it was part of the plan by that point.

------
llimos
From the developer's point of view, mobile apps give you more ways to retain
the user's attention (a home screen icon, pop-up notifications, hooks for
actions, etc.).

As a rule, desktop apps are used for producing and mobile apps for consuming.
Which means that desktop apps generally don't need to pull the user in as much
as mobile apps do - the user will come back on their own because that's where
they're doing their work.

For apps used for consuming, the user's attention is everything, so mobile
apps are preferred - the user is much less likely to find their way back on
their own.

~~~
collyw
> As a rule, desktop apps are used for producing and mobile apps for
> consuming.

That's an interesting observation. I am not really interested in web IDE's,
but I am happy to use google docs. Though I spend maybe 20 times more time
writing code than documents.

------
Raed667
Web on mobile always feels "off" compared to native. It could be the UI
(Material on iOS sticks out like sore thumb), but also the way interactions
are handled (back button, scrolling, swipe events, dialogs, ...)

We are in a state where we can make decent mobile-first web apps but they
don't hold their own compared to native. It is like an uncanny valley, where a
web-app can pretend to be native but it is off-putting to the average user.

~~~
yummypaint
I always assumed this was intentional to push users to the app so telemetry
and tracking work more reliably, and to bypass adblockers. The reddit mobile
site is a classic example. No new functionality in years, but it's borderline
unusable on a phone these days, and the constant nag screens to install the
app betray their intentions.

------
tyingq
Because there's not an easy way to force monetize (app store) native apps on
desktops, since you would have to take something away that was already there.

------
jasode
_> Is it UX differences? Economical incentive differences? Someone with wested
interested pushing things in one or both? Just a fashion thing?_

The main difference between desktop pc vs mobile is the _availability of
programmable APIs to access underlying hardware_. This leads to many apps
using native API SDK on smartphones but many desktop software (especially
newer software) to be browser apps.

On mobile, the underlying hardware is _changing_ and getting _enhanced_ at a
faster rate than the standard browser APIs can keep up. Although smartphone
innovation is slowing, the new phones released each year still add new
features faster than a standards committee for the Javascript api can adopt.
E.g. front & rear cameras instead of just rear cameras, accelerometers, voice
recognition, fingerprint id, etc. In short, there's a _delta of functionality_
between the native iOS/Swift/Android/Java SDKs vs the web api with Javascript.
If that missing functionality in browser Javascript is important, you'll end
up with native apps.

As just one example, look at the web browsers API compatibility list to see if
there's a standard unified way to query the accelerometer:
[https://caniuse.com/#search=Accelerometer](https://caniuse.com/#search=Accelerometer)

Notice all those red rectangles instead of green ones? Developers notice that
Apple Safari doesn't support the web api accelerometer. That's one example of
pushing developers towards native iOS API+Swift instead of web
Safari+Javascript. Another difference between mobile native vs web is push
notification from apps.

On desktop, the pc hardware has _matured and is more stable_. The motivations
for choosing native would still be accessing hardware specific advantages but
these become more advanced use cases for "power users". E.g. creating arrays
in RAM larger than 4GB in size, accessing GPU, use latest cpu instruction
sets, etc. E.g. a banking app that let's customers check balances and move
money around doesn't need any advanced hardware access and can be written with
Javascript for web browsers. However, CPU and RAM intensive software like CAD
modeling or After Effects video rendering will be written in C++. The lower
resource apps like banking are more common on pc than Autodesk and Adobe.
Widespread adoption of WASM would eventually bring more cpu intensive desktop
apps to the browser but the gap will remain for many years. On the desktop,
there's also a delta of functionality between web browser and native but it's
_less important for common use cases_ so browser apps will suffice.

------
anotheryou
Desktop: native to web

\- finally possible to have big apps in the browser

\- for easy cross-platform

\- can actually be used in hybrid apps, so cross platform includes mobile
browses and apps (more on that see below)

\- good for SaaS pricing

\- bonus: sync across devices

Mobile: web to native

\- notifications

\- icon on home screen

\- sensors

\- performance (a really snappy UI is hard in any browser)

\- easy payment and subscriptions

\- discovery through the app-store

\- integration (share button, storage)

\- Actually you might see hybrids without knowing: menu and extra
functionality natively, actual main-view is just a browser. Feasible since
maybe 5 years, before apps where big because they had to bundle the browser.
(twitter, insta, uber etc: [https://www.excellentwebworld.com/hybrid-app-
examples/](https://www.excellentwebworld.com/hybrid-app-examples/) )

\- and more meta: Apple doesn't want web-apps to become powerful because they
can't get their 30% cut from them. (google is a bit more progressive:
[https://codelabs.developers.google.com/codelabs/your-
first-p...](https://codelabs.developers.google.com/codelabs/your-first-
pwapp/#0) )

------
neximo64
Theres too much fragmentation with desktops and desktop like environments,
Mac, Windows, Linux, Ipad.

It's quite hard to make native apps for all these, previously you would just
go for Windows. So easier to make a web app targeting them all.

For iOS and Android there's less fragmentation so you can either go react
native, a webkit type app and the most costly option: native for each.

~~~
samfisher83
Desktop is dominanted by a single OS. there is still duopoly at least in
America on the mobile side.

------
Kkoala
Desktop apps are moving to browser mainly because most software is becoming
SaaS which is easier to enforce on browser. Also websites are much easier and
quicker to push updates to, most people won't bother updating their native
desktop apps. Maybe the mobile market is not as business software oriented.

------
godot
I may be off the mark but my immediate gut reaction to this question is that
distribution/discovery is partly why. On desktop, web apps are more easily
distributed, especially back in the Windows era. Downloading and installing a
windows program was a lot of effort to casual users. But you send someone a
link, or they click around the web, and they're in the web app immediately. On
mobile, the app/play store makes distribution and discovery arguably even
easier. Similarly after that, the macOS app store appears to drive a
resurgence in desktop apps (for the Mac at least).

------
lapcatsoftware
It's a combination of numbers and technology.

Numbers: Android and iOS each have over a billion users, so it makes more
sense to make dedicated apps for those platforms. Desktop platforms are much
smaller, so it makes less sense to dedicate the resources.

Technology: Chromium is available on desktop platforms, which allows you to
easily make cross-platform apps. Chromium is not available on iOS, because
Apple has enforced a WebKit monopoly. There's not a great cross-platform app
technology that covers iOS, Android, Windows, and Mac, otherwise developers
would probably go for that.

------
schwartzworld
One thing that may influence it is the readily available tooling for web
developers to easily build cross platform apps with web tech. This technology
exists on the desktop too, but I feel like it's not as well recognized. You
can build your frontend in reactjs and your mobile app in react native and
share a lot of code between the too. I can't think of another option that
works together quite so well.

------
collyw
Desktop apps to browser makes sense as it's more platform independent and you
can access them from different machines. You don't need to worry about saving
your data and carryin it around on a disk.

(IDE's are one thing that I don't think are ready for the browser yet, maybe I
haven't tried a decent one though).

Mobile native apps seem to be a bit smoother than web apps.

~~~
agustif
[https://github.com/cdr/code-server](https://github.com/cdr/code-server) is an
interesting way of running VSCode in the browser.

------
ffpip
Mobile apps can track users much more easily. Especially on Android. Web apps
are inside the browser, on small screens.

Desktop apps are a bit too much sometimes. Users don't install apps easily.
You have to download from some random store or Github, install the exe,
configure it, etc.

Just make a website. Runs on every browser on every OS.

------
zzo38computer
Command-line programs should also be considered. So can various types of VMs
(of which HTML might be considered one of the most complicated, but certainly
not the only one available). Also, telnet and SSH should strongly be
considered, too.

------
Barrin92
among reasons other have pointed to I'd also argue that the desktop is simply
becoming a niche platform. A lot of companies built for mobile first because
it's the primary end-user platform, and web tech works everywhere, while a
standalone desktop platform might not be worth it depending on the product.

------
senthilnayagam
mobile phones now come in varied sizes, screen resolutions and many
capabilities. and app has to look native and feel responsive so simple web
views don’t work well anymore.

camera,bluetooth,qrcode scanner, fingerprint/face id for authentication, don’t
have good equivalent api in web standards.

~~~
Raed667
SSO is also a big turnoff for me.

When I have Facebook or Google already on my phone, I hate it when mobile web-
apps open a web-view and make me login to those providers again to use SSO
(which kind of defeats the point)

