I'm wondering about this myself. Service worker support definitely paves the way for PNs (because the service worker handles receiving messages via the `push` event listener), but I haven't seen explicit mention of them in this announcement.
In cases similar to desktops with electron vs. native (although with different requirements) where either you need access to significant native features that are not supported in the browser, or if your app is process intensive, i.e. graphics heavy games.
The analogy to Electron makes me wonder if a possible mass migration to PWAs will make the experience on already-slow low-end phones even more atrocious.
it would be the opposite actually, since you don't have to wrap the app in a heavy bundle. avg iOS app size is like 30mb. a web app shouldn't even come close.
This has been a huge differentiator in countries where users are sensitive to data consumption, which is why you see many case studies about countries in India, Africa, etc. getting great traction with PWAs.
Storage space isn't generally the bottleneck on older devices- it's the CPU/RAM. On that count, native apps are usually overwhelmingly preferable.
If these catch on a big way, it'll be catastrophic for more underpowered devices. Modern web pages are already starting to get acutely uncomfortable to use on older iPhones, let alone older Android devices- we aren't yet at the point where performance levels are high enough that we can slap the equivalent of an electron wrapper on everything, smirk at users' devices' vanishing battery life and call it a day.
Apples to oranges. The download size of a native app, while important to keep low, will have minimal effect of the actual user experience post-download. Web applications will in almost all cases be a strictly worse user experience.
That's not necessarily true, depending on what your definition of "non-trivial" is.
I currently use IndexedDB to store over 500mb of data on phones successfully in a B2B application.
The biggest issue in my experience is access to native "well optimized" APIs. (If I want a video feed, it causes significantly more battery draw to do it in a webview vs a native camera feed).
Ah, so in that case yes, it's safe from the extreme majority of XSS, because I use Content-Security-Policy headers.
Any cookies would also be subject to XSS, unless they have the HTTP-Only flag set, in which case the whole point is not worth discussing because JavaScript cannot access it or even know it exists, so it would obviously be useless to any javascript.
Localstorage (and friends like WebSQL and IndexedDB) and Cookies serve different purposes, and having data in IndexedDB is no less "secure" than having it displayed on the page. In both cases an XSS attack means game over.
Not true, many browsers give decent offline data storage quotas. Although one of the benefits of PWAs is that you often reduce your data footprint on your users devices. The extreme canonical example has been Twitter PWA compared to Twitter native.
I have not encountered a single case where a web app offered a better experience than a native app.
There is a reasonable argument that it's cheaper to develop, allowing support for more platforms to be rolled out with less development time. That's the single reason that might be valid.
I strongly prefer the Twitter PWA to the Twitter app. It uses only 279 KB storage on my phone. When Firefox 58 finishes rolling out, I'll play around with using web extensions to customize the app, which is something that will likely never be possible with a native app.
Also the case where you have lots if transient users. Far better to have a first-rmtime visitor experience s mobile-friendly webpage that can act as an app than to throw a "download our app" message at them.
For companies with more reliable visitors, Native definitely has an edge in options, but if a company is trying to build feature and experience parity across platforms, much if that edge is dulled.
I'm not so sure. Developers may be excited at the chance to forgo the App Store / Play Store, but will users get onboard? They've had 10 years of training to download an app from a store. Will the flow for onboarding with a PWA be a complement to that, or just create confusion?
Windows has PWAs in the Windows Store. So the user goes through the install flow, same as any other app, but behind the scenes they're actually downloading a PWA.
But also, consider that people don't seem to really download that many apps. Less than one a month. So I agree with you, in that users may be conditioned to expect a certain workflow, but it's not like it's a deeply ingrained habit that people are doing daily. Also, when you visit a site multiple times, the browser shows a pop-up offering to add the app to your homescreen. So it's low-friction onboarding.
assuming "old school webview app" means something built with cordova (or similar), you no longer have the ability to drop down into Obj-C / Java for extensions/functionality that the web doesn't have or safari doesn't support.
In many cases this doesn't really matter, but could very easily be a complete dealbreaker for someone trying to decide what to build.
Ya pretty much meant cordova. And just for fun lets throw react native into the comparison mix. Now have 5 levels deep of options on the Web App <--> Native scale, all 5 of them still relevant in 2 years?
I've been doing React professionally for 3 years now. I've messed with React Native out of curiosity and to see if it would fit my needs.
React Native remains a hard sell for me. The idea behind it is that knowledge of React is where the learning curve is. Which is a flawed premise. React, itself, is dead simple. But ditching years of CSS and DOM knowledge and learning the React Native component API and quirks regarding iOS and Android? That's a massive hill to climb. Even with JavaScript by your side. I'd rather try Cordova+React if I had to. And if I truly wanted native performance, then it's Obj-C for me. Might as well suck it up and do it right in the first place.
I've found the transition to the native components to be the easiest part. Really feels no different than using components just like you would on the web. Hard part is that the documentation for everything has tons of missing pieces and the error messages suck.
This case study is nonsense. There is no case in which a native app will be 148MB in size, while a web app with comparable functionality will be 233kB. None.
Quite aside from anything else, the Starbucks PWA is a strictly worse experience than the native application.
Interesting. So please let us know your about your experiences and strategies on maintaining applications across several platforms (iOS, Android, Tablet and Desktop) while keeping binary sizes small with comparable functionality and good user experience. I'm willing to learn and improve on that topic.
I worked on the PWA from its inception until the past few months. The size difference is real, and I'd wager that it was 75% at parity with the native featureset at the time I left :)
Which is not what this article is about - the article focuses on PWA meaning 'home screen web app'. My impression is that Apple use case of Service Workers is for improved caching rather than trying to make "Save to home screen" sites better.
PWAs work without connection, or with a very lousy or limited data connection, without having to download a lot of stuff the moment you need it the most. In other words, the vast majority of advantages of native apps.
Their exciting for web devs (which are a large group), as they allow us to create apps that approximate native apps (the really big feature being offline support).
Its a good thing the Safari App and Apps from facebook et all don't share the same Cache etc. I don't want facebook to be able to know which sites i have visited before from other Apps or Safari.
Not for the reason you mentioned (because that itself is a nonissue), but I'm glad there exists the sandbox that native apps and the Safari app are completely isolated.
So unless I’m mistaken, PWAs in their most “ideal” form (vs how Apple has implemented them) kinda hang around after I’ve visited them, can use some arbitrary amount of disk space, leave background processes running, and can send push notifications even after I’ve navigated elsewhere. It sounds like to some extent they effectively get to install themselves on my device without my permission, with visiting the site in question acting as consent. Am I incorrect?
If all the above is true, I can’t say I’m too happy with the feature as a user and hope there’s a universal off switch buried in settings somewhere. If I choose to use a website over a native app it’s due to its ephemerality, so I have no interest in web apps that stay past their welcome.
If on the other hand the behavior is 100% opt in, that’s fine as long as I’m not shown banners trying to sell me on the PWA all the time.
Just like a native app, the process requires user approval ("add to homescreen" vs "install"). A large difference, however, is that native apps go through Apple's approval process.
Workbox is my team's (Google Web DevRel) library for making it easier to manage caches (there's lots of gotchas you can potentially encounter if you roll your own).
Its crazy isn't it. First we had desktop applications, then webpages that try to be desktop apps, now websites are changing their very definition to being desktop applications (using the browser as a framework).
It's similar with the UI. First flat, then 3D, now back to flat. Its crazy.
In truth, _all_ iOS apps were web apps in the beginning. Steve Jobs wanted all apps to be based on HTML5, but developer pushback forced Apple to change its mind. iOS didn't get native apps until almost a year after the iPhone was announced.
This article focuses on Web App Manifest, and Service Workers (Caching). Safari on macOS definitely has Service Workers, but I'm not sure Web App Manifest support on desktop (nor am I clear on how that would make sense)
I was speaking about the concept. So essentially using ServiceWorkers, Web App Manifest etc. to produce something that resembles native apps.
Why would it not make sense? I was just thinking about giving macOS the same functionality as iOS (so "installing" web-pages), having them in the dock and giving them a different UI. I have some electron apps installed on my mac that don't need much more functionality and could just be converted to a PWA if supported on macOS.
Are there some quick, easy and usable UI-frameworks for buttons etc. and other common UI-Elements? I am a bit out of the loop in the web-ecosystem, but the PWA look very interesting.
Ionic. I found it to have the most polished components. Better than Framework7. Also, you get a PWA with zero additional config when developing your SPA with Ionic. I’m happy with it.
This article doesn't mention what is in my opinion the worst part of iOS PWAs (or web development in general).
The engine that runs a PWA (or web-view, or app added to the home screen) is completely different than the one in safari.
The "WebView" engine, (specifically a UIWebView, WKWebView, or SFSafariViewController) don't have some features turned on, like WebRTC. And there are rendering differences between the 2 engines.
I was really screwed by this recently. I saw iOS 11 was to get WebRTC and getUserMedia support, so I tested out a POC and found it worked in safari. So I started building it out in safari, mostly just turning on the feature if it was supported in safari, and when I went to go test a production version of the app added to the homescreen, it was failing.
Turns out It's not only not supported on the WebView, but it still advertises that it's supported, and you just need to catch the failure when you go to use it to know that it's not supported...
Now I either had to tell my users to REMOVE the bookmark on the homescreen if they were to use this new feature, and warn people to NEVER add the app to the homescreen as it would break the feature, or just forgo the feature entirely, which is what I ended up doing.
Oh god, please not another substandard / badly maintained embedded engine. One Microsoft Outlook was enough for history. Getting emails to look right was a pain for so long.
I might be wrong but iOS decided from the early days to separate safari and webview.
What would be interesting to know is if it is two different libs/renders/codebases or just degradation of features as op pointed out with webview, etc.
From my research when I had this issue, (and i'm going from memory here, so forgive any inaccuracies) it looks like it's because Safari uses Safari's rendering engine, while WebView's use "WebKit" with a lot of modifications.
As far as I heard from various sources, they are in many ways completely separate codebases, and the reasoning is that since WebKit is very tightly integrated with the OS, it takes them much more time to include new features into WebKit than it does in Safari.
There might be, but from past experience it wasn't a good idea to do so.
This is a B2B web-app, and in a previous version (more of a predecessor) we had it open in safari, and we found that people wouldn't ever close the tab they were using, leading to hundreds of open tabs.
It also means that if someone went to the home screen, they would have to tap "Safari" to get back, and in my experience they didn't know to do that, so they would just click the homescreen shortcut again, opening a fresh new tab, and need to sign-in again...
This makes my blood boil. Safari is literally the IE of mobile. I don't get why Apple is making it so hard to deliver PWAs nicely?! I mean, they can fight it, but they'll at best delay the inevitable... Perhaps that's their game: delay until they have in place a system as lucrative as the app store but for PWAs.
Trust me, It made my blood boil too. I unfortunately let my anger get the best of me and ended up getting in an argument with an Apple engineer online where I said some things that I really regret.
But it did almost really fuck up my job, because we had promised a client that functionality, and like 2 weeks away from delivering had to back out and go with a fallback plan of staying up all night for many nights those 2 weeks coding something in cordova that would give me similar results.
It ultimately was my fault for not testing the feature in the correct way before committing to it, and it did turn out good for me (although it's far from ideal, having getUserMedia in WebViews is ideal, and I will be switching to it the second it's available and stable), but it was not a good time...
That is a painful experience. Hope you were compensated well in some way. One more thing, not limited just to Safari standalone mode: their CSS rotation animation was buggy as hell (maybe it still is). If you rotated more than 180 degs, the CSS engine would rotate in the opposite direction (basically, it would ignore the sign of the intended rotation and just take the shortest path to get from state A to B)! Only solution involved some very ugly JavaScript.
Funny how sometimes with software and the way it is distributed, we can either have a handful of engineers figure it out the first time and distribute it correctly, or let the rest of the world of engineers reinvent the tandem bicycle for the k+nth time. I'm glad they are working on it, sorry you had to go through that. Sounds like you are a super ninja though and did not mind the extra grapple. You know, I often send in feature requests and application feedback. Probably once a month to Apple, or a website, or some service, because that's how they get better. In the end, we are all somehow serving one another (it's not just clients and customers and experts) and I think that it's important to appreciate how we got here - meaningful conversation and discourse.
It's just a matter of priorities. Of course Google wants you to stay within the browser and of course Apple would prefer native apps.
But their financial motives don't discount from the pros and cons of their approach. If anything, we need both in order that both actually have a reason to keep advancing.
I've been tracking this same "bug". do you have any sense for when webrtc will be in wkwebview? some thread somewhere said it's one full release lag behind when Safari gets a feature
I was told by an Apple engineer that they are working on it, and that it was a technical limitation not a political one. But since big additions like that tend to only come in major version updates, I'm expecting iOS 12 or iOS 13 if it misses that release.
i'm waiting on the same feature :) i find it hard to believe it's a technical problem. i suspect it's politics around letting web apps having functional parity with native.
The worst thing about trying to make something work in the browser for mobile is getting the UI to utilize the full height. This is common when the UI needs to have both something stickied on the top and bottom of the page. Both Chrome Android and Safari will cut off content if that content is 100vh with their URL bar that comes and goes as you scroll. Then you have full screen mode which iOS does not support but Chrome does, except that on Chrome invoking the keyboard does not tell the page anything about the height that it's taking up.
The only browser that gets everything correct is Samsung's default browser. This is pretty ridiculous and the hacks available with current APIs aren't very good compared to if these browsers worked properly with 100vh.
Just a reminder that if you want the WebKit team to be aware of bugs or things that do not properly work or features/standards that need to be better supported, file bugs at https://bugs.webkit.org
They also have a mailing list, and one of the things they asked before this SW work started was 'let us know how important this is to you and what your use cases are'. I bet they are still listening and that they would love feedback.
So this means the experience of extracting any useful information from any website I click on from a google results page is going to keep getting worse.
We already have popups to log in, popups to sign up for newsletters, popups to take surveys, popups to install the app instead of viewing the website, full-screen ads, popups to enable notifications, popups for a site to access my location, popups about enabling cookies, and popups telling me to stop blocking popups. Every site now thinks just because I'm clicking on it from a search result page means I want to engage in some semipermanent relationship with them, before I even get a chance to view the site. Now we just add one more thing to the pile of things every website under the sun will try to get me to do just because I clicked one link.
Remember when web pages were just documents you could view?
96 comments
[ 3.1 ms ] story [ 163 ms ] threadhttps://developer.mozilla.org/en-US/docs/Web/API/PushEvent
In many cases(including mine) it now makes more sense to go PWA first instead of native.
Twitter PWA: 600KB
Native Android Twitter: 23.5MB
https://developers.google.com/web/showcase/2017/twitter#lowe...
This has been a huge differentiator in countries where users are sensitive to data consumption, which is why you see many case studies about countries in India, Africa, etc. getting great traction with PWAs.
Disclaimer: I'm on Google Web DevRel team
If these catch on a big way, it'll be catastrophic for more underpowered devices. Modern web pages are already starting to get acutely uncomfortable to use on older iPhones, let alone older Android devices- we aren't yet at the point where performance levels are high enough that we can slap the equivalent of an electron wrapper on everything, smirk at users' devices' vanishing battery life and call it a day.
I currently use IndexedDB to store over 500mb of data on phones successfully in a B2B application.
The biggest issue in my experience is access to native "well optimized" APIs. (If I want a video feed, it causes significantly more battery draw to do it in a webview vs a native camera feed).
IndexedDB is subject to the same origin policy, so only javascript executed on my domain can access the data for my domain.
Combined with a good Content-security-policy means I'm in control of exactly what code gets to access those resources.
Any cookies would also be subject to XSS, unless they have the HTTP-Only flag set, in which case the whole point is not worth discussing because JavaScript cannot access it or even know it exists, so it would obviously be useless to any javascript.
Localstorage (and friends like WebSQL and IndexedDB) and Cookies serve different purposes, and having data in IndexedDB is no less "secure" than having it displayed on the page. In both cases an XSS attack means game over.
See link below for per-browser storage quota: https://developers.google.com/web/ilt/pwa/live-data-in-the-s...
Disclaimer: I work on Google Web DevRel
I have not encountered a single case where a web app offered a better experience than a native app.
There is a reasonable argument that it's cheaper to develop, allowing support for more platforms to be rolled out with less development time. That's the single reason that might be valid.
For companies with more reliable visitors, Native definitely has an edge in options, but if a company is trying to build feature and experience parity across platforms, much if that edge is dulled.
https://www.thurrott.com/windows/windows-10/135665/pwas-comi...
But also, consider that people don't seem to really download that many apps. Less than one a month. So I agree with you, in that users may be conditioned to expect a certain workflow, but it's not like it's a deeply ingrained habit that people are doing daily. Also, when you visit a site multiple times, the browser shows a pop-up offering to add the app to your homescreen. So it's low-friction onboarding.
https://techcrunch.com/2017/08/25/majority-of-u-s-consumers-...
Disclaimer: I work on Google Web DevRel
In many cases this doesn't really matter, but could very easily be a complete dealbreaker for someone trying to decide what to build.
React Native remains a hard sell for me. The idea behind it is that knowledge of React is where the learning curve is. Which is a flawed premise. React, itself, is dead simple. But ditching years of CSS and DOM knowledge and learning the React Native component API and quirks regarding iOS and Android? That's a massive hill to climb. Even with JavaScript by your side. I'd rather try Cordova+React if I had to. And if I truly wanted native performance, then it's Obj-C for me. Might as well suck it up and do it right in the first place.
The PWA is 233 kb compared to 148 MB iOS native app.
https://formidable.com/static/Formidable-Case_Starbucks_PWA....
Still not practical. APIs available to the web ecosystem are always going to be one level abstracted or behind their fully native counterparts.
Quite aside from anything else, the Starbucks PWA is a strictly worse experience than the native application.
https://developers.google.com/web/progressive-web-apps/check...
Disclosure: I work on Google Web DevRel, the team that owns that site
https://developers.google.com/web/showcase/2017/
Disclaimer: I work on Google Web DevRel, which owns developers.google.com/web
I don't use Android, but I've never seen this work using any browser on MacOS, Windows or iOS.
They'll even open in a seperated window.
Three dots > More tools > Add to Desktop
[0] https://w3c.github.io/ServiceWorker/#cache-objects
If all the above is true, I can’t say I’m too happy with the feature as a user and hope there’s a universal off switch buried in settings somewhere. If I choose to use a website over a native app it’s due to its ephemerality, so I have no interest in web apps that stay past their welcome.
If on the other hand the behavior is 100% opt in, that’s fine as long as I’m not shown banners trying to sell me on the PWA all the time.
https://developer.mozilla.org/en-US/docs/Web/API/Cache
Workbox is my team's (Google Web DevRel) library for making it easier to manage caches (there's lots of gotchas you can potentially encounter if you roll your own).
https://developers.google.com/web/tools/workbox/
It's similar with the UI. First flat, then 3D, now back to flat. Its crazy.
Obviously the apps Apple shipped on the original iPhone were native apps.
Even before the official App Store was announced, developers reversed engineered their way to native apps.
It wasn’t a good look for Apple: it could create native apps but 3rd party developers couldn’t, especially game developers.
HTML5 wasn’t nearly as capable 10+ years ago as it is today and developers let it be known that wasn’t tenable.
Apparently allowing 3rd party native apps was the right thing to do.
This article focuses on Web App Manifest, and Service Workers (Caching). Safari on macOS definitely has Service Workers, but I'm not sure Web App Manifest support on desktop (nor am I clear on how that would make sense)
Why would it not make sense? I was just thinking about giving macOS the same functionality as iOS (so "installing" web-pages), having them in the dock and giving them a different UI. I have some electron apps installed on my mac that don't need much more functionality and could just be converted to a PWA if supported on macOS.
https://developers.google.com/web/progressive-web-apps/check...
Check out the case studies for why businesses are (rightfully, IMO) interested in PWAs.
https://developers.google.com/web/showcase/2017/
Disclosure: I work on Google Web DevRel team
The engine that runs a PWA (or web-view, or app added to the home screen) is completely different than the one in safari.
The "WebView" engine, (specifically a UIWebView, WKWebView, or SFSafariViewController) don't have some features turned on, like WebRTC. And there are rendering differences between the 2 engines.
I was really screwed by this recently. I saw iOS 11 was to get WebRTC and getUserMedia support, so I tested out a POC and found it worked in safari. So I started building it out in safari, mostly just turning on the feature if it was supported in safari, and when I went to go test a production version of the app added to the homescreen, it was failing.
Turns out It's not only not supported on the WebView, but it still advertises that it's supported, and you just need to catch the failure when you go to use it to know that it's not supported...
Now I either had to tell my users to REMOVE the bookmark on the homescreen if they were to use this new feature, and warn people to NEVER add the app to the homescreen as it would break the feature, or just forgo the feature entirely, which is what I ended up doing.
I might be wrong but iOS decided from the early days to separate safari and webview.
What would be interesting to know is if it is two different libs/renders/codebases or just degradation of features as op pointed out with webview, etc.
As far as I heard from various sources, they are in many ways completely separate codebases, and the reasoning is that since WebKit is very tightly integrated with the OS, it takes them much more time to include new features into WebKit than it does in Safari.
This is a B2B web-app, and in a previous version (more of a predecessor) we had it open in safari, and we found that people wouldn't ever close the tab they were using, leading to hundreds of open tabs.
It also means that if someone went to the home screen, they would have to tap "Safari" to get back, and in my experience they didn't know to do that, so they would just click the homescreen shortcut again, opening a fresh new tab, and need to sign-in again...
But it did almost really fuck up my job, because we had promised a client that functionality, and like 2 weeks away from delivering had to back out and go with a fallback plan of staying up all night for many nights those 2 weeks coding something in cordova that would give me similar results.
It ultimately was my fault for not testing the feature in the correct way before committing to it, and it did turn out good for me (although it's far from ideal, having getUserMedia in WebViews is ideal, and I will be switching to it the second it's available and stable), but it was not a good time...
But their financial motives don't discount from the pros and cons of their approach. If anything, we need both in order that both actually have a reason to keep advancing.
Native apps capture depth, webapps capture breadth.
I actually think they're both doing the right thing by their users even if I don't agree on each individual choice they make.
I was told by an Apple engineer that they are working on it, and that it was a technical limitation not a political one. But since big additions like that tend to only come in major version updates, I'm expecting iOS 12 or iOS 13 if it misses that release.
The only browser that gets everything correct is Samsung's default browser. This is pretty ridiculous and the hacks available with current APIs aren't very good compared to if these browsers worked properly with 100vh.
They also have a mailing list, and one of the things they asked before this SW work started was 'let us know how important this is to you and what your use cases are'. I bet they are still listening and that they would love feedback.
We already have popups to log in, popups to sign up for newsletters, popups to take surveys, popups to install the app instead of viewing the website, full-screen ads, popups to enable notifications, popups for a site to access my location, popups about enabling cookies, and popups telling me to stop blocking popups. Every site now thinks just because I'm clicking on it from a search result page means I want to engage in some semipermanent relationship with them, before I even get a chance to view the site. Now we just add one more thing to the pile of things every website under the sun will try to get me to do just because I clicked one link.
Remember when web pages were just documents you could view?
Honestly? Fuck the web.