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.
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.
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.
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.
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.
- 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... )
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.
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.
(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.
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.
camera,bluetooth,qrcode scanner, fingerprint/face id for authentication, don’t have good equivalent api in web standards.