Ask HN: Why desktop apps are moving to browser but mobile apps to native?
25 comments
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).
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.
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.
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.
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.
Desktop is dominanted by a single OS. there is still duopoly at least in America on the mobile side.
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.
camera,bluetooth,qrcode scanner, fingerprint/face id for authentication, don’t have good equivalent api in web standards.
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)
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)
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.
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.
I intuitively agree with you, but at the same time I am pretty sure that some apps are just a wrapper around the web app without me realizing it.
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.
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.
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.
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.
> 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.
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.
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/ )
- 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... )
- 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/ )
- 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... )
>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
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.
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
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.
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.
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.
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.
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.
> and users prefer the polished experience of a native app with fewer compromises
Why are apps pushed so hard to users though? If they are so clearly superior users would seek to download them, right? They don't, overwhelmingly so. The average user downloads 0 apps per month.
Why are apps pushed so hard to users though? If they are so clearly superior users would seek to download them, right? They don't, overwhelmingly so. The average user downloads 0 apps per month.
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...
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.
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...
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.
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.
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.
(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.
https://github.com/cdr/code-server is an interesting way of running VSCode in the browser.
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.
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.
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.
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.
Is it UX differences? Economical incentive differences? Someone with wested interested pushing things in one or both? Just a fashion thing?
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?
I just do not get my head around why this is happening.