Hacker News new | more | comments | ask | show | jobs | submit login
iOS 12.2 Beta: Progressive Web App Capabilities (twitter.com)
97 points by tosh 26 days ago | hide | past | web | favorite | 80 comments



I developed a web-app photo editor https://www.Photopea.com, that is used on 100 000 iOS devices at least once a month.

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.


That is a really cool app! I bookmarked and I will definitely check it out later.


Without fanboying to much, I want to add how important PWAs are to breaking the walled gardens of the App Store and Play Store. Apple and Google can and will stop your app from distributing via their stores if they see fit, but they can't stop users from adding a PWA to their home screen.

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.


It bothers me that PWAs are a thing too. If we have a perfectly capable computer in our smartphones, just let a native app (whether it uses a higher level language or not) handle it.

Better performance, better battery use, better integration, more platform features available, better look and feel, and so on...


- "better performance, better battery use" - this is not true at all. What makes you think so?

- "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.


>- "better performance, better battery use" - this is not true at all. What makes you think so?

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.


On the UI front, I'd be interested to see what's possible. For instance, <input type="date"/> creates a native date input. Why not the same for navigation components etc? After all, the vast majority of native apps don't need the processing power of native, they just need the UI.


What has a C/C++/Obj-C/Swift or any other programming language to do with performance? All programs have to be converted to CPU instructions somehow, and if you think that C++ code converts into "better CPU instructions", than a Javascript version of the same program, you are quite wrong.

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.


> (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").

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).


As answered on another thread, PWAs are native apps on some OSes, like ChromeOS and Windows.


The OS, like ChromeOS, having "first class support" for web technologies doesn't make those apps native.

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.


ChromeOS native apps are web apps, like it or not,that is what we get, even Android and the alternative Linux environment run inside VMs.

As for the second part, that is exactly what Chakra within UWP does on Windows.


>ChromeOS native apps are web apps, like it or not,that is what we get

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.


So Chackra isn't a "even a low level VM"?

At which point do you draw the line between bitcode on watchOS, ART on Android, and Chackra on UWP?


> Developers need to develop several versions of their app (they could spend that time on improving one version).

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.


> Developers need to develop several versions of their app

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.


even for PWA. you still need to test your app. on several devices.


That does involve writing two apps instead of one if you want to support ios and android though. Plus, some PWAs are really good. I much prefer facebooks mobile website to their app...


>That does involve writing two apps instead of one if you want to support ios and android though.

As a user, it's enough for me that you support one platform, the one I use, as best as possible.


Well, it's not enough if the company decides to support the one that you don't use! Also, many apps that provide access to a service don't make commercial sense unless they are accessible from both platforms.


So write two apps. Android and iOS are different, have different capabilities and a market size that justifies the effort — assuming your app is worth a damn in the first place. This lowest common denominator development trend is obnoxious. Basically, it “socializes” the experience so that every device is treated equally despite devices having different strengths and weaknesses. We are trying to make devices conform to the app rather than the app conform to the strengths of the device.


There's a trade off here, right? Between focussing on these platform specific UX details, and actually implementing more functionality jn the app.

Also: modern smartphones are very similar to each other. Sure there are differences, but for the most part they are minor.


> It bothers me that PWAs are a thing too.

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.


Nah, I switched what's the point of bother ironically.

You're bothered by X? Yeah, I'm bothered by non-X as well...


I agree with you, but most business do not, specially for internal applications.

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.


That's where wasm enters the scene! Pwa + wasm is I think a little revolution in client app development.


I think the problem is the DOM, not the execution engine.

If it's just WASM and no-DOM, then it might as well be native.


I'm interested in better understanding your concerns.

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/


>how would you feel about web apps being implemented with WASM and targeting WebGL/WebGPU as the rendering target?

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.


>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.

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.


If you don't want to pay fees or simply think having to ask permission sucks, that's one thing. But if you think an App Store somehow is subject to the laws and power of a nation, or actor of the state, and a website is not -- well, I'm afraid I have some very bad news for you about how nation states work.


WebGL as a target would work, except that it has no accessibility affordances. That needs to be solved first.


Unfortunately accessibility affordances usually come after documentation and unit tests, so most projects only care about them when deploying into government regulated scenarios.


> If it's just WASM and no-DOM, then it might as well be native.

Two key arguments in favor of wasm against native: fully cross platform, security sandbox.


Yeah, I'm not against those. In fact, I didn't mean my comment to be "If it's just WASM and no-DOM, then you might as well go full native" but rather ""If it's just WASM and no-DOM then it's more or less native already".


Realistically, the alternative to a PWA is often gonna be a a "native" app build on web tech, or in niche cases no app at all. At least in the niches I'm active in, a bunch of users unhappy with the fact that nobody makes an iOS app for them (but not unhappy enough to cough up the money for someone to make them one) would probably be happy that they can use PWAs instead of using only web apps in the browser.

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?


There are several restrictions in iOS. You can not use much. You might be able to track some users but nothing much you can do without native app.


Yes, that's true. However after using the Twitter PWA for some time, I believe there's a whole segment of native apps which could run just as well as PWAs. My biggest gripe was the Twitter PWA losing state while multitasking. This now seems to be resolved somewhat.

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.


Which webapps are being held back by their ability to quickly dispatch instructions to the GPU?


I believe it's less than people would think but from previous discussions on PWAs it seems to me, that mobile developers just dislike JavaScript and it's ecosystem, rather than PWAs in general.

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.


WebGPU isn't really analogous to WASM. It's a replacement to WebGL. It will still have a JavaScript API with a non-JS shader language, it will just be more efficient.


Buried in that thread are some key details:

    Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc.
Basically, forcing native apps to use their in-app purchases. Won't this trigger anti-trust laws?


They've always forced native apps to use IAP (or no purchase on the device at all; go buy an eBook on Amazon's web site, and you can read it fine in Kindle on iOS) for digital goods.

Forcing web app IAP? I don't see them pulling that off successfully.


I guess Services Worker is fine on iOS and iPhone. Because you rarely have Safari opening all the time. On macOS it is god damn awful. [1]

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.

[1] https://twitter.com/gruber/status/1083810719009787904


Yeah, agreed. User permissions need to become more granular. A web app should not be able to use all CPU power for prolonged amounts of time. Instead the browser should drastically limit computing usage of a web app, till the user gives the explicit permission for more. That way web apps can gain more capabilities but only with the users permission.

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.


nice. Still no push notifications which is a huge no for me when it comes to PWAs at this stage. I know there's pushover but their licensing sucks, not every user can and wants to buy it.


I agree. If Apple would support push notifications for PWAs, it would almost level the playground for most kinds of apps.


That is precisely the reason they are not going to be supported.


I'm not so sure. The Push API and Notification API are two separate things on the web, and one and the same on iOS. It wouldn't be immediately straightforward to wake up a service worker in response to a push event on iOS, so I can believe they are trying to find the optimal way of doing it.

(I also believe it's not a huge priority)


I understand that push notifications are being abused by many sites who just try to spam users but a good number of potential PWA's will become possible of push notifications become available. On the other hand I see Apple being worries about losing control over their walled garden if they give too much freedom to the browser.


I will never understand why push notification permission wasn't put behind click activation like many others are. The span of that permission prompt is very annoying.


Thank God for no push notifications on Safari.


"2) State is maintained if it goes in the background. A bit buggy though, but promising"

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.


Me too, I do favour native over Web, but there are a good set of applications that can be made good enough with Web stack, without any FFI or build tooling headaches.


A dream of Steve Jobs is coming closer to his fulfillment. When presenting iOS, he said that people will run web apps (in the browser).


I'm in favor of PWAs but I never understood why Jobs originally planed to distribute apps in such a open way. He must have known that this would drastically limit Apple's power to decide what runs on customers devices. Do you have more information on this?

Anyway, Apple seems to have changed their mind rather quickly after releasing the App Store.


It really bothers me that “Progressive Web Apps” are a thing. If Apple and Google allowed it, there’s no need for a new paradigm - just let the browser handle it. The same way slack sends notifications over the browser on desktop, we could make use of.

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


I don’t quite getting what you are objecting to. Slack cannot send you notifications when you’re not on the website, unless they have access to one of the APIs commonly bundled under the PWA umbrella.

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.


Two things:

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.


For what it’s worth, Apple didn’t go the app route to begin with. They were all in on web apps on the iPhone, and had no plans to allow native app development until developers demanded it. The iPhone didn’t have native app support until around a year after it’s release. They thought browsers had the capabilities necessary to make web apps mobile friendly enough to fill the need at the time, but that was overly-optimistic.


Web Apps are handled by browsers. But it is mentioned as iOS update, because the only allowed browser in iOS is Safari, so only Apple is able to control, how good web browsing in iOS is.

All other iOS "browsers" as Chrome, Firefox or Edge, are just wrappers around Safari.


Progressive Web Apps are handled by the browser. The main difference wrt. "web apps" is that they're not presented to the user with a "web-site" UX. See https://xkcd.com/1367/ for a summary of why that's a good thing.


I wonder whether there’s a difficulty in Apple about how much power to give web apps in light of their privacy play. The browser isolates permissions - Facebook can let me upload a picture in a chat without giving them permission to all my pictures, their app can’t or at least doesn’t. If they had notifications working for PWAs I’d probably drop Facebook Messenger for example.


Is there a real primary source for this?

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.


The resuming state after leaving the PWA is awesome. My hobby project is a PWA but has a bug now since the beta where all user interaction is lost when resuming the state. I have a hunch it has to do with google maps and it's fun trying to figure it out right now.


You still can't save local files with PWA...


sure you can, but the user must choose where to put it, no arbitrary saves.

https://github.com/eligrey/FileSaver.js


https://github.com/eligrey/FileSaver.js/issues

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.


Seems like regular browser compatability issues to me. Specific safari not working, a few edge cases here and there. You have that in all cross browser libraries.


With save the specific problem is that Mozilla guys wanted to move all save capability to local DB + download, and to never allow writes to arbitrary local files, treating it as a security issue, which obviously is a problem for any sort of web apps running locally. Google tried to standardize FileWriter API that never made it outside Chrome, then later dropped it due to aforementioned issue.


Great. Now we can have app lookalikes built with someone's pet JS framework contaminating our iPhones.


"contaminating"? PWAs are contained a whole lot stricter than native apps. Specifically on Android I would worry a lot less about adding a PWA to the home screen than installing a native app.

Do you speak out against implementing apps in JavaScript or is your criticism pointed at PWAs specifically?


In my experience, the Android and iOS app stores differ a lot in general quality, with the iOS apps being the better ones. Partially, I theorise, is due to it being harder to publish on the App Store than on the Google Play Store. This means that lesser developers and companies will publish more poorly made apps for Android than they will for iOS.

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"? PWAs are contained a whole lot stricter than native apps.

Contaminating as in "with their mere presence", doesn't have to be an exploit...


I agree that webapps aren't currently on par with native apps. However, it seems somewhat inevitable that things will go that way. We're just stuck in the ugly transition period.

Sadly, the turning point will probably be when browsers and/or WASM add enough DRM type functionality.


>I agree that webapps aren't currently on par with native apps. However, it seems somewhat inevitable that things will go that way.

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.


Because writing applications for 3 or 4 distinct targets is a waste of time and money.

If wasm/web were good enough, one app would run on Android, iOS, desktop, etc.


That's a lowest common denominator app.

If that's the case, we don't need to have multiple mobile OS platforms either...


I already agreed it wasn't ideal now. I'm suggesting it will improve, enough, in the future. And yes, that would diminish the value proposition of the phone OS.

Edit: That's roughly why Chromebooks are doing well. The OS is less important on laptops already, for many.


>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).




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: