iOS 12.2 Beta: Progressive Web App Capabilities
twitter.com
twitter.com
I am very happy, that I never had to go through the pain of submitting my "app" to Apple store or paying any fee. I never even owned any iOS device.
This is great for user rights and moves the needle more towards a decentralized and open ecosystem, while maintaining strong security guarantees to the end-user.
Better performance, better battery use, better integration, more platform features available, better look and feel, and so on...
- "better integration, better look and feel" - it depends a lot on available web standards, which are constantly improving.
You forgot about disadvantages: Developers need to develop several versions of their app (they could spend that time on improving one version). They need several devices for testing (luckily, there are Unity and Xamarin). Authors have to pay fees for having their product in various "stores". Big corporations (such as Google, Apple, Microsoft, Steam) can throw you away anytime for any reason, accuse you of various violations. But noone can prevent you from going to a website.
How is that even remotely controversial? With native you run direct native code, in C/C++/Obj-C/Swift/etc and optimized native UI libraries. With a PWA you run a browser engine, a DOM rendering pipeline, and on top of it you run Javascript, and on top you run one today's frameworks. Guess what uses less battery? Ever did a comparison of native vs Electron apps on the desktop, where it's easy to compare?
(To preempt a facile counter-argument: yes, a native app can be coded very silly, do busy wait or whatever, and eat all the cpu/battery/memory. We're interested about baselines and what happens "everything else being equal").
>- "better integration, better look and feel" - it depends a lot on available web standards, which are constantly improving.
Doesn't matter how much they improve, they will always not be 1:1 with the access to the smartphone OS's SDK libs a native app has.
Nor would be the exact same look/feel as the platform (which native gives you), ever compare to someone's ad-hoc UI or re-implementation of the native L&F.
>You forgot about disadvantages: Developers need to develop several versions of their app
That's a disadvantage of the developer, not the user. Why would I as a user care? So that I can get more worse apps more easily?
Besides, WPA still need testing -- especially if they use the "available web standards, which are constantly improving".
>Authors have to pay fees for having their product in various "stores"
Still good in my book. Puts a somewhat higher barrier for crap.
In your "native iOS app", you call the OS interface to add UI elements and accept events. What makes you think, that it requires less performance / battery / RAM, than doing the same through a browser?
Let's say that the browser environment adds extra 30 MB to every program. But the rest of the memory is fully in your control. When you see GMail using 300 MB of RAM, its the fault in GMail, not in the browser.
But everything else is not equal. If I don't have to develop a native app for iOS and Android, I can dedicate double the amount of resource to the PWA version (or triple, if I was planning to do it anyway), which means I can decide to make it performant (or add more functionality, if I don't care much about my customer's battery).
ChromeOS still runs a Linux underneath, and could run apps without a web layer, DOM, etc, if allowed.
When most of us call for "native apps" we don't mean "first class OS support" we mean "as little BS layered crap as possible on top of the CPU" -- so AOT or even a low level VM fits that, a web rendering engine, the DOM, and JS, does not.
As for the second part, that is exactly what Chakra within UWP does on Windows.
Again, I explained what I mean by native apps (which is what everybody means). What "we get" and whether we "like it or not" has no bearing as to whether they're native.
When iOS at first had no public Obj-C SDK and only allowed web apps, those web apps weren't magically "native" just because that was what Apple encouraged/allowed.
"The only type of apps that are encouraged/supported by the vendor" is not the same as them being native apps.
At which point do you draw the line between bitcode on watchOS, ART on Android, and Chackra on UWP?
I hear this line so much you'd think the web app world is full of the most amazing light and high-performance web apps out there, that show the best of what we can do with our web browsers. But no, it's just full of bloated ever-growing ever-more-resource-hungry framework-heavy web apps wrapped in Electron.
It's just cost-cutting, let's not pretend it's anything but. Slack is a great example of this. A text chat app that could be done natively and isn't. And the reality is it saves them money and it's acceptable to have it just as a web app. It is not, however, in any single way better than a native app could be.
Because there are, in almost all cases, different market segments. iOS users generally want a different app from Android users. For most companies, they’ll constitute different demographics, support profiles and needs. Smearing then together for cost cutting reduces product-market fit. (This reduction may be worth the cost reductions at low scales or low population differentiations.)
The freedom point is valid. But that makes PWAs a good back-up, not primary choice, for apps.
As a user, it's enough for me that you support one platform, the one I use, as best as possible.
Also: modern smartphones are very similar to each other. Sure there are differences, but for the most part they are minor.
I think you accidentally replied to the wrong comment. It sounds like you're responding to lettergram's comment, which also complains that PWAs bother him: https://news.ycombinator.com/item?id=19011910
Versus the parent comment from reichardt, which speaks favorably of PWAs.
You're bothered by X? Yeah, I'm bothered by non-X as well...
So if I get to choose between mobile Web, and the likes of React Native, Ionic or Cordova, then I rather bet on mobile Web and let the browser do its work, instead of dealing with FFI and tooling integration issues.
Also PWAs are actually native apps on some OSes, like ChromeOS and Windows.
If it's just WASM and no-DOM, then it might as well be native.
If the DOM and JavaScript are the main sticking points, how would you feel about web apps being implemented with WASM and targeting WebGL/WebGPU as the rendering target?
Are you feeling more favorably towards technologies like Flutter? https://flutter.io/
In that case, what would make them "web" apps anymore, as opposed to apps running on a low-level VM and a GPU library? They'd be more like e.g. Java+OpenGL apps. Just that they launch from a web browser? All kinds of non-web technologies do that as well.
>Are you feeling more favorably towards technologies like Flutter?
Yes, though I'd prefer they targeted the native SDK's UI widgets.
Yes, distribution via the browser sets apart web apps from native apps. This includes several advantages that I value very much.
1. Cross Platform: If your device runs a modern web browser than there's a high chance it will run any web app that adheres to open web standards. Browsers are unique in that regard because all major vendors make a good effort of working on and implementing the same specifications. Today almost any consumer device is able to run JavaScript. In the future this will include WASM.
2. No gate keepers: Google or Apple can stop developers from publishing an app on their platforms, but they can't stop developers from publishing a web app. To me that's a central promise of the web and severely limits corporations and nation states abilities to taking control of or censoring content.
Two key arguments in favor of wasm against native: fully cross platform, security sandbox.
For simple apps, "better integration, more platform features" isn't necessarily a factor: If the "web platform" provides the features I need, having access to more features doesn't make my app better.
If you don't like PWAs, they are easier to identify and avoid than "non-native native apps", so good for you too?
In addition PWAs will only become more capable. WASM will have direct access to the web apis and opens the door to implementing PWAs without JavaScript. I'm keeping my eyes on WebGPU, which I believe could deliver huge performance benefits to webapps. At this point having no support for push notifications is probably the biggest holdback for PWAs.
And fair enough, I'm all for developers not being tied to a single language to develope apps. If my understanding is correct than WASM and WebGPU will allow for development of apps with any language of your liking and performance will only depend on how close to metal you can develop with said language.
I'm more of a JavaScript developer but I would be very interested in how developing web apps with Rust and WebGL would look like.
Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc.
Forcing web app IAP? I don't see them pulling that off successfully.
I am also a little uneasy with PWA, on quality, safety and without some sort of App Store firewall guarding it. But then I also don't see the point of KFC, McDonald, or every restaurant / services sector require an App for their business. When it could be on the Web or as Web App.
On your second point I wholy agree that not every fast food chain or coffee shop needs a native app on their customers phone. Starbucks PWA shows the way.
(I also believe it's not a huge priority)
So happy about that! I almost thought Apple would deliberay cripple the PWA experience on iOS just enough in order to not be competitive to native apps. This is a huge step towards PWAs becoming a real contender in the app space. Starbucks and Twitter PWAs show what's already possible. Very bullish on this development.
Anyway, Apple seems to have changed their mind rather quickly after releasing the App Store.
Instead they want to control the interface, likely for their own gain, but also som added security. So, I get it. However, the whole buzz word and excitement is good, but it’s annoyingly stifled to begin with
Is it just the name you’re objecting to? Do you believe it’s a bad idea to strive for feature parity between native apps and the web? I seriously can’t tell.
1. Apple and google are going to set a new set of APIs. And likely edge out the importance of other browsers.
2. They went the app route to begin with... they could have always gone the PWA route (especially the last few years). I don’t know why I have to have a native app if the entire web is now mobile friendly.
All other iOS "browsers" as Chrome, Firefox or Edge, are just wrappers around Safari.
I’d like to know whether PWA developers need to register as developers with Apple. Hopefully not, although I don’t see how Apple wants to prevent the use of third-party payment systems without forcing everyone to get their apps signed.
Doesn't seem to be working well. A few people I know got burned trying to use it and expecting universal functionality across all browsers.
Do you speak out against implementing apps in JavaScript or is your criticism pointed at PWAs specifically?
Now, with PWAs, it will become a lot easier to 'publish' 'apps' for iOS, which means that even crappier icons will find their way to your homescreen than would have if all of Android's apps were available for iOS.
That is how I understand 'contaminating' at least.
Some background: I used to have an Android phone and for the last 4-5 years I've had an iPhone. Sadly I still need to help lots of family and friends with Android phones when they are having problems, so I am still familiar with the apps for Android.
Contaminating as in "with their mere presence", doesn't have to be an exploit...
Sadly, the turning point will probably be when browsers and/or WASM add enough DRM type functionality.
Why? There doesn't seem to be anything inevitable to me. A chat web app today still uses more resources and has less features than 1997-era ICQ.
If wasm/web were good enough, one app would run on Android, iOS, desktop, etc.
If that's the case, we don't need to have multiple mobile OS platforms either...
Edit: That's roughly why Chromebooks are doing well. The OS is less important on laptops already, for many.
Are they doing well? Read some stats to that, but have never seen one in the wild (except in airports, where they rented them to waiting passengers).