Convopage
See the entire conversation
“Apple: shame on you”; the moment at #JSConfEU from my talk for not publishing any docs, updates or changelogs on the current PWA implementation on iOS (and now iPadOS)
youtu.be/cybhV88KLfI?t=…
187 replies and sub-replies as of Jan 03 2020
Yes babby love
We can probably do more on documenting web standards support in WebKit, but PWA is a Google-invented term afaik. I see it mentioned in a roadmap document w3.org/2018/12/web-ro… and called a "de facto app format" in a group report w3.org/2018/12/webmed…, both from last year.
By the wife of a Google employee, also used by the community and even Microsoft, Intel and Samsung and many more. Also the community uses a community logo, contributed by a Samsung (Internet) employee
cc @slightlylate
& I worked up name together, with no org support (everyone hated it! only got on board w/ name months after my personal blog post)
Also suspect @torgo, @AaronGustafson, @boyofgreen, & @andreasbovens would push back on the idea it's somehow Google-driven.
MSFT and Samsung have been hosing PWA events *we didn't even know about* and they both beat us to Desktop PWAs by multiple years!
We collaborated with folks at Mozilla on Service Worker design and Manifest format extensions. And @boyofgreen and I sketched out the rough "plan" for PWAs together in...what? '12? '13? This has been broad collaboration from the get-go.
To this day, it's harder for me to get Google PM, DevRel, and BD excited about PWAs than it is to collaborate with external folks on solving these developer needs.
Every.
Single.
Time.
(and because it's both true and because I'll pay for it later if I don't, cc: @dalmaer @Paul_Kinlan @bgalbs @b1tr0t @thaotran)
I wouldn't say it's hard to get DevRel support on pwa, but we have to go deeper on every facet - speed, offline, installability, UI, UX, capability... Our team ends up focusing on those areas because that is where we can help a lot.
The comparison was relative.
Agree with @torgo that PWA is a design pattern. I used the term "pinned apps" to mean something similar before "PWA". It was a useful label, but now the pattern is established I just think of them as web apps. PWA is often used to refer to Chrome-specific installability criteria.
We discussed this at MDN PAB meeting last week. PWA should always mean cross-platform installable web app, not any browser-specific criteria. developer.mozilla.org/en-US/docs/Web… I would like to work together to build this page up to become the source of truth about PWAs. /cc @chrisdavidmills
Progressive web apps
Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps. This set of docs tells you all you need to know about them.
developer.mozilla.org
Sounds good. Perhaps it could be more explicit that PWA is a design pattern. PWA is really just a shorthand term to refer to a collection of web standards that make web apps more like native apps (installability, offline, standalone, app icons, push notifications etc.)
I have thought about installability criteria like a permission, or a trade: sites that do the work to meet user expectations of other apps on the homescreen can get/show the prompt.
It's a quality bar as much as anything.
jumping into this old thread (on a digital vacation). @slightlylate is correct. I think of PWA as a way to frame where the web needs to go. Call it architecture, call it a design pattern, call it marketing. It's a way to get us all on the same page and I think its working.
I agree. But AJAX, HTML5, SPA, PWA, ..? It's an evolution. Eventually we just call them all web apps.
What would be nice would be better user-facing terminology and marketing. "Add to home" is hard to explain.
It would be great if "install the web app" was widely understood.
I believe "Add website shortcut" is good enough. Although with WebAPK it's a real install and that would be confusing.
But "Add website shortcut" isn't a brand. Lots of browsers let you add shortcuts to any website, so "shortcut-addable website" doesn't mean your site has any particular properties. The "PWA" brand is (fuzzily) meeting some criteria for being a "real app".
I'd love to work out a consistent set of requirements for sites to meet that is agreed across browsers, rather than having this or that browser's criteria be what developers are shooting for.
This would only be valuable once checks imprpve. Chrome behaviour is largely deficient to ensure goals are met, at will likely need further bolstering (post better offline handling detection) to gate install on speed. Slow sites should not be installable.
/cc @b1tr0t
Offline is a bit of an interesting case too. What do we consider “offline handling”? Is a “you are offline notice” good enough? What's the bar?
Twitter’s PWA, for example, doesn't actually work offline. And that's intentional, due to the nature of the product.
I mean personally I’d like to see the twitter PWA have better off line support. I’d love to be able to reward cached tweets, reply to them, etc to be synced later. That’s what the mobile app does.
At a minimum, the SW needs to respond with a document with low latency (sub-second) under all network conditions (online, flaky, offline) or you haven't really won anything for the user. Our install checks aren't good around this and *must* improve.
Completely agree.
Installability is a privilege to be earned by sites that do well by the user, namely by meeting app-like minimum bars to interactivity -- that is, it always loads in ~constant time when you tap the icon.
While I agree with what's a good ux. I'm not sure about the web platform removing abilities if you don't meet a set of quality score calculated automatically based on goals not defined by standards or even the user. I'm not convinced yet that it will be for good
Dropping Alex since he's in vacation.
By “removing abilities” are you talking specifically about installation?
Today the ability in discussion is installability but the same approach can be extended to anything else. When it's about security and privacy, the answer is clear. But when it's about user experience, what is good or not is not written in stone and it may rely on the context.
There are two pieces to this, right?
1) Whether a web site can be installed and
2) Whether a browser chooses to promote website installation via its UI.
Based on my understanding, the piece in question is the second one.
Crazy idea: talk about this F2F :)
AFAIK users can always Add to Home from the browser menu.
Not on desktop and on Android, ATH menu is king of an obscure pattern if the author can't offer installation from its own UI
But 2 is also related to the beforeinstallprompt event fire that allows a
3) Whether a web author can promote installation from the content
Also, on Chrome desktop, no 2) involves no 1).
I wasn’t aware of onbeforeinstallprompt enablement governing the "Install" menu item in Chrome. Is that a recent change?
For those who aren’t sure what we’re talking about, here’s the Installation experience in Chrome Canary.
That menu experience is in stable today on all desktop platforms. As far as I understand and based on my tests Chrome checks PWA Installability criteria on desktop: it enables Install menu and fire beforeinstallprompt (also Install button at omnibox on beta). No criteria, no menu
I think that change must have corresponded to my full-time move over to Edge Canary as my daily driver.
We can reason about what’s exact criteria for «Install..» native button. In my yesterday’s thread/experiments the engagement heuristics is not part of it: twitter.com/webmaxru/statu…
It would be cool to update this item in the criteria list then :) Also, I believe this criteria is more for firing "beforeinstallprompt", not the installability fact itself. Example: I open random #PWA and DO NOT interact but I still see "Install..." in 3-dots menu and onmibar
Please drop Marion & Frances.
Edge dev (Chromium) shows the install menu not matter what to all websites.
For what it’s worth, we (Edge) are experimenting a bit in this space. For example, @NeptuneSystems’ Fusion dashboard is a web app, but not (yet) a PWA:
funny timing. I updated the Add To Homescreen library recently. It abstracts away the browser/platform differences as much as possible.
The PWA Add to Homescreen Library
Managing the differences between each browser and platform's progressive web app installation process is daunting. The Add to Homescreen Library makes this easy
love2dev.com
Also, from a dev perspective that continues to be asked to trigger prompts according to all sorts of rules by stakeholders the fluidity of Chrome's beforeinstallprompt trigger is very frustrating.
Thanks!
Removing a few folks from the thread per their requests.
It a content doesn't deserve installation (and it's a technical limitation), why does it deserve rendering at all? That's why I think this might end up bad and it doesn't feel part of the spirit of the Web platform
Apologies! Enjoy!
I tried to be polite but... hey try talking F2F then insanely huge twitter threads :)
Drop me too please.
We will :-)
Just in case, you can mute threads yourself if you're not interested.
As a stop-gap, we're investigating treating slow-starts as crashes.
Anyhow, on holiday and won't respond here more for a while.
Enjoy your holidays!
If they content doesn't do well for the user for installability, why bother rendering it as a next step, or with a yellow omnibox saying "be careful this is a crappy website" 🤔 that's why I say it end up like an app store but without human interaction for QA
Personally I think any web app which provides a web app manifest should be installable, the browser just might not suggest that you install it.
Otherwise PWAs may suffer the same fate that physical web beacons did when Google started filtering based on arbitrary quality metrics.
> Personally I think any web app which provides a web app manifest should be installable, the browser just might not suggest that you install it.
💯
Strongly disagree. Businesses will invest in PWAs by the promise of better engagement. A PWA should be installable, always. Speed is arbitrary and depends on context. Installability is not a privilege, it's the only point of building a PWA in the first place.
Agreed. @CharlieCroom & I have discussed at length.
I'd even take just my DMs persisting to be honest. I hate trying to go back in long DM threads to find links & key info. If it's been downloaded to my device already, I'm totally cool keeping it forever.
The problem with slow websites should not be installable is that those kind of requirements difficult to define cross platform, cross device, and cross context end up badly or just creating another app store saying your app is too ugly to be published here
Probably. Here is an example. We have native apps and a PWA. The PWA mini-info banner, on Russian, always says "Add to homescreen <app_name> application" (or something like that). Key thing -- it uses word "application". So how users should know what will be "installed"?
That's a user interface problem. I don't think that's what we're talking about here (that's up to browsers to figure out). This is about an agreed criteria for whether sites are "installable as an app" as opposed to as a shortcut to a URL.
I thought it's here about UI/UX and how users see it. If it's about what to do on tech side then whatever :-)
I think "website shortcut" is selling it short.
It has always been the intention that user agents compete on installability signals (w3c.github.io/manifest/#inst…). But I'd like to see browsers call it "install", rather than some other clunky term.
This is why I've been arguing since 2015 for a coherent visual brand for this.
Right. My hairdresser/window cleaner/elderly relative all know what it means to "install the app" from an app store.
I'd like the same understanding for "install the web app" from a browser. It's hard to "brand" a cross-vendor feature, but consistent terminology could help.
That's exactly right. I wrote a little about the naming a couple years back
Naming Progressive Web Apps
I got an email a few weeks ago from a German technology magazine asking me some questions about Progressive Web Apps. I responded, but the email eventually bounced and I assume the sender never got…
fberriman.com
Great explanation, thank you for (re-)sharing.
Thanks for driving this forward Dan. I'll put together a spec for the docs update today, and start pestering potential authors '-)
Looks like I will be taking on updating/expanding the PWA documentation on MDN in Q3/Q4 this year. I expect you and I will exchange thoughts...
Happy to help too.
Here to support in any way we can as well. @samsunginternet has your back on this!
That’s great! I’ll be sure to reach out again as planning starts to pull together in terms of my schedule and such. Should be soon.
Any of you interested in being directly or somewhat directly involved in at least making sure we have a solid plan for documentation for PWAs please ping me privately with a contact email.
Not sure how to ping you privately, but let me know if I can help somehow (my DMs are open)
So are Eric's I think
Sorry - my DMs are now open. :)
Since we have so many PWA aficionados here, I’d like to provide this link:
twitter.com/lukolejnik/sta…
My privacy analysis of Progressive Web Applications (web app manifest). Interesting user tracking and cookie respawning potential/risk; transparency. Progressive Web Apprehension. #PWA #PWApprehension
Tracking users with rogue Progressive Web Applications
Welcome to the privacy analysis of Progressive Web Applications. With new features in steady supply, the web is changing in exciting ways. One of the more interesting trends is the concept of Progressive Web Applications (PWA [https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/] ). PWAs use modern and powerful web features to further blur the boundaries between web and mobile apps. In practical terms they let users to “install” web applications to the smartph
blog.lukaszolejnik.com
That’s a useful link to share, thank you. It’s something that should be considered when planning this documentation.
Yep. Starturl is a known way. :\ but it only really matters on install - there's an argument for removing query string, but you could still make a unique URL for the manifest; spec groups should work it out
There's a thread on the manifest spec devoted to this.
Privacy Review: handle start_url tracking · Issue #399 · w3c/manifest
To summarize @npdoty comments in https://lists.w3.org/Archives/Public/public-privacy/2015JanMar/0117.html there are concerns about start_url containing special ids or simply something that hints th...
github.com
This has to do with manifest, not the PWA Pattern as it also affects display: browsers AFAIK. Similar issue affect bookmarking and Add to the homescreen on Safari iOS before manifest.
Sure, but as that’s related to PWAs it should be kept in mind. We do want to be sure to have a good discussion of security and privacy.
The manifest is the point, not pwa per se. Firts point is spot on, the idea of any platforms mechanism to get anything on to a home screen is a vector for super cookies.
That’s a good point.
That said, I still took that more as a reminder we need to contemplate the security issues and either explain why concerns are unjustified or how to mitigate them where they are legit.
The good news (to some extent at least) is that users control the installation of web apps which then use the start_url. In normal websites, start_url abuse currently possess no issues.
Users also have full control over what they click on; or what they install, etc :)
Yep. The only potential caveat to that is something maybe pre-installed by a workplace or something like that. But one would hope that that would not be a vector of abuse.
Not only known but also demonstrated, and indeed what matters is the url (and the cookie-like mechanism).
I guess one "solution" is to let the user browser ask the user "do you want to remove all the installed icons/apps and bookmarks?" when deleting all data, but I guess users won't see the relationship between both actions.
Maybe you know this but just in case, the fastest solution in these cases (it happens to me sometimes) is to use the mute conversation option. I guess it's available somewhere on every Twitter client on the contextual menu of these messages.
It’s not available in @tweetbot, which I think is one of the most used Twitter clients on iOS and macOS… 😥
There is a 'mute this conversation' option in Twitter, but yes, I will remove you if I reply!
The right messaging for that notion—the option to delete PWAs that have been installed when deleting browser data—is an interesting problem. Perhaps UX that says “The following apps are associated with the data being cleared. Would you like to delete the apps as well?”
It's further complicated when you consider OS integration as well. Does the OS delete data shared with the browser when users uninstall an app? They have a shared data pool, but users aren't used to that.
Enterprise needs? :)
PWA is *not* a Google-only invented/driven thing. Many ideas (like A2HS, standalone mode, etc.) came from Palm/HP/webOS and Firefox OS (and later from Chrome OS) where all apps are *web* apps.
Many hardware- and OS-specific web APIs (like NFC, SMS, Contacts API, etc.) were originally implemented in Firefox OS. And only later were adopted for PWA (Web platform) by Project Fizz and adopting right now by Project Fugu.
See whatwebcando.today.
At the launch of the first iPhone in 2007, Steve Jobs announced that web apps, developed in HTML5 using AJAX architecture, would be the standard format for iPhone apps. No SDK was required, and the apps would be fully integrated into the device through the Safari browser engine.
I.e. PWAs (with a different name). This model was later switched for the App Store.
That idea lay on the surface, but Google is one of the first companies that put significant efforts into promoting (and more importantly, implementing) PWA.
The problem is this?
Or is the problem that when in 2015 @phae and @slightlylate coined the term "progressive web apps", Alex worked at Google?
Unfortunately, the web wasn't really ready to be the API behind full-on apps back in 2007. But Jobs's announcement and the ensuing enhancements to the web that followed, were a factor in getting things moving in that direction, I think.
I guess you found out about our secret plan to steal credit for PWAs 😝
Steal? Huh? I think you meant "appropriately claim". Shoutout to you, @boyofgreen, @AaronGustafson, @Justinwillis96 and the whole team for the long-term collaboration.
❤️ how we've been able to more together than apart, making it all work through standards. Thank you!
💯
A key piece of the underlying tech—Service Workers—may have originated at Google, but the PWAs have definitely been embraced by the community writ-large.
They didn't originate at Google! They were a collaboration with Mozilla engineers and tons of other folks who were interested in the "fixing AppCache" circa '12:
labs.ft.com/2012/08/fixing…
Blame @triblondon!
Fixing app cache
At FT Labs, we are on a mission to fix app cache, for the good of mankind web developers. Over the last few weeks a couple of important meetings have taken place bringing together developers and browser vendors to try …
labs.ft.com
Yes, we collaborated heavily and have invested the most in terms of engineering to make them a success...but that's because we very much want a path off AppCache for our biggest apps.
I stand corrected. I mistakenly thought it was @jaffathecake’s baby.
I was in the room (I think I was still at Lanyrd at the time, maybe), but certainly can't take full credit. I only became spec editor many years later.
And here I thought it sprang forth from your head fully-grown, like Athena!
Could we also thank Lanyrd?
I believe that’s where @jaffathecake learned how messed up AppCache was, as I remember from his talk @ParisWeb 2012:
Application cache #ParisWeb #Performance #Web API #Web mobile
The Application Cache is one of the cool bits of HTML5, allowing sites to work without a network connection brings us much closer to native app-like behaviour. However, from HTML5 roundup articles…
paris-web.fr
It wasn’t me, I wasn’t there and I never even heard of it and even if I did do it so what I had every right.
I can attest to that. We loved AppCache. It was like a trusty friend. Why would we ever have thought of replacing it?
And Web App Manifest was mostly Mozilla and Intel, though I did interact a lot with Googlers especially when they were implementing the add-to-homescreen feature, which later got to be known as PWA
That I knew.
Please, don’t remind us we lost Firefox OS… 😥
I mean, Mozilla lost FFOS by not having a coherent strategy or the discipline to follow through, but I've got KaiOS devices on my desk and they're the best feature phones I've ever used.
I agree KaiOS devices are great feature phones. But Firefox OS devices where smartphones. I really miss them.
My hope is that Kai eventually pushes back into touchscreen devices. The HW/SW balance I see on the Kai featurephones is better than the Android Go devices on my bench.
I also hope to get some smartphones powered by KaiOS.
I intended to buy an Android Go device to try it, but didn’t yet.
Sorry, I didn’t understand “HW/SW“.
Sorry, meant Hardware and Software balance. Lots of Go devices are wedged into a really tight spot on a FLOPS/pixel basis.
Ok, I understand. I wanted to try the Alcatel 1X, the first Android Go device available in France.
Have one on my desk! (except it doesn't get updates)
It's fun in a d-pad sort of way.
I’ll try to get one of these. I already own too many devices, but I like to know how our projects behavein different contexts.
I own a Nokia 8810 4G with KaiOS.
But also 2 "true" old Firefox OS smartphones.
I still miss Firefox OS on touch devices.
I even had a game in the featured apps of Mozilla Marketplace.
Admittedly, the term “Progressive Web App” is somewhat confusing; it’s at once both a marketing term and technical baseline. But, to be honest, it’s still less confusing than Apple’s “HTML5” back in the day (which was more about proprietary CSS than standardized markup).
That is always how I compared them. When regular people and companies said "HTML5" they meant HTML5 + CSS3 + geolocation and much more.
Basically the same with PWAs today, it basically means the modern web plus installability, though technically you can restrict it to web app manifest and service workers - though many include push notifications for historical reasons
Yeah. I was running an agency at the time and we were working on a Chrome App at the time. We were told it had to be “HTML5”, but they wanted way more than markup. And a heck of a lot of stuff that never gained wide adoption (e.g., WebSQL).
That's exactly right. I wrote a little about the naming a couple years back
Naming Progressive Web Apps
I got an email a few weeks ago from a German technology magazine asking me some questions about Progressive Web Apps. I responded, but the email eventually bounced and I assume the sender never got…
fberriman.com
I wrote Google-invented. My suggestion is simply to use the name of standards if you're looking for standards support. When I DuckDuckGo 'web manifest site:webkit.org' I get relevant links.
WebKit
Open Source Web Browser Engine
webkit.org
Web App Manifest listed as “in development” but in fact it’s being shipped partially for more than a year. Which part is implemented and which part isn’t? You never talked about it; no mentions at Safari changelogs, webkit blog (maybe it’s not WebKit-related), or at any video
(No comment)
Forget about “PWA”.
Web standards, such as Web App Manifest that Safari on iOS is currently partially implementing: no docs or info. Call them homescreen webapps instead of PWAs (Steve’s term): you change implementation, add features, change lifecycle but no mentions at all ever
"If you google PWAs on iOS …" is what you say in the talk and what you show links for.
Yes, because that’s what the dev community is searching for.
In fact, you created an app recently with Create-React-App (Feedback Assistant), you enable SW and you kept the Web App Manifest. How CRA call that thing? PWAs: facebook.github.io/create-react-a…
React is not from Google.
Create React App · Set up a modern web app by running one command.
The production build has all the tools necessary to generate a first-class
create-react-app.dev
If you don’t want to say it PWA, don’t say it. But, if you implement a web feature or API, I don’t see how you can justify don’t talking or blogging or documenting about it. It’s the “unspeakable” 🤷🏻♂️
Is the lack of full support because of a fear for app producers to move from the (profitable?) AppStore to something more open?
The standards work did not fully take privacy and security into account. WebKit is the only browser engine to enforce partitioning for ServiceWorkers afaik, and not too long ago we got botnets built on ServiceWorkers:
New browser attack lets hackers run bad code even after users leave a web page | ZDNet
MarioNet attack lets hackers create botnets from users' browsers.
zdnet.com
Thanks for the link! - I'll read up on that /cc @kennethrohde
You'll find that many proposed web standards don't protect privacy because the vendor behind the proposal has no modern privacy protections in their browser. I.e. the proposed standard doesn't regress privacy protections in their browser so they don't take it into consideration.
That report was technically desestimated. Despite that, it's true that service workers on WebKit at least have a blog post and the partitions part is interesting. SW is on Safari on macOS as well. When you touch ios only implemented APIs the void appears.
That’s perhaps something for you to cover in your next talk – “Safari is the only browser that protects users from the privacy problems with ServiceWorkers.” Should be a nice change. 🙂
love this convo
Thank you for your suggestion for my next talk. Nothing to do with what I say but thanks.
I still don't get anything related to what I said and what lot of devs are asking from your team 🤷♂️ you just want to take the conversation to unrelated "arenas" as an answer.
From my first reply: "We can probably do more on documenting web standards support in WebKit."
When you assert with a "probably" and continues with a "but" is kind of 🙄
If you are taking the critic and planning to do something about it, great! That's my point and I and *probably* many people will be glad to see that in action. *But* I've been saying this for years 😜
I mostly say probably since it's not my decision. The web tech I work on is fairly well documented (IMHO) but I like to write. We always take serious feedback into consideration. But we're pretty tired of Google-related hate campaigns to be frank. At least I am.
There are some things that are well documented, I agree; and when you see nothing, outdated or wrong information on other parts for years like what I'm saying, it's frustrating. I'm not a Google employee and if you read or watch content I produce I'm always pushing all browsers
I'm not saying you are a Google employee. I'm saying the push for PWAs have been bundled up with a bunch of hate, and "Shame on you!" easily falls into that category regardless of what your real message is. I'm sure you see the haters here on Twitter daily, just like I do.
WebKit is an open source project with many participating organizations. I'm saying we, the WebKit project, which you can join right now, could probably do better on documenting our standards support.
That's one of the issues: most of the things I'm talking about might be out of the WebKit team; maybe Safari, maybe who ever is responsible for the Web.app and Web1 processes on iOS. That's out of the open source project, but directly related to the WebKit team😕
Firebase Hosting | Fast and secure web hosting
Firebase is Google’s mobile platform that helps you quickly develop high-quality apps and grow your business.
firebase.google.com
Well, I've noted your feedback. Thank you for that.
You are welcome and I'm open to discuss details on that feedback of need.
BTW, Almost a million reads 😳 on those three articles on PWAs on iOS is a message saying that I'm not the only crazy dev looking for those answers.
BTW, first article I remember writing (apart from books) about new undocumented APIs and support on Safari iOS (really 9 years ago) "Apple didn’t update yet Safari documentation to reflect these new APIs." mobilexweb.com/blog/safari-io…
Of course, but shame on you is still my status on it (I was talking about info/docs). Honestly, I can't believe that you didn't talk about the manifest support (what works and what not) after 15 months. Really. I'm not criticizing people but the company.
You may honestly in private say "we can't", "we don't have resources" or whatever, and it might me probably true. But as a user of a company offering a browser that is almost a monopoly on that device, I have the right to request a proper UX and for that devs need proper info
That's totally understandable. I just want to point out that home screen web apps on iOS was very buggy and wasn't going any further. Even before Google started pushing.
Now they are, you have good progress, especially in comparison to previous years. But..
But it would be great to understand where you're heading, maybe "how you're committed" and why you weren't before. @firt keeps mentioning docs because having docs somehow says that you're at least committed for devs to use it.
Also, if I may, what it would be great (for me, as a web dev) is to have "stable add to homescreen experience for users". Not all the features Google has. Not pursuing web and native app parity. But at least not lacking feature in comparison to Safari and **stability**.
We all do care for the users. I know you too. So it's hard to offer "add to homescreen" experience to them when it isn't stable. It's a nice feature and it would be great to have it on Apple platforms to other to the users. ❤️
Up until recently, we were the only big browser taking web privacy seriously. We effectively became the privacy reviewers of new web proposals. So to get anything done, we focused on the most important specs, did the privacy work the spec writers didn't do, and implemented.
Privacy is great and is very much appreciated. I know a lot of devs and users who love Safari for that. Are you saying that the blocker (or one of) is that many specs aren't privacy oriented and that's why Safari isn't implementing them?
If so, I bet webdevs can come to Chrome's spec issues and ask, a lot, to do privacy fixes. There is no reason for webdevs to blame Safari for not implementing non-secure features. The misunderstanding comes from "Google wants to move web forward and Apple doesn't because of Apps"
I’m not talking about privacy oriented. The spec writers come from browser vendors that offer users no modern privacy protections. So the specs don’t take privacy into proper consideration. We then have to do all of that work to not regress privacy.
Just to clarify, I was talking about things you implemented and never talked about it or documented in any way; not features I may want you to implement. So the privacy first argument (which is appreciated) I'm not sure applies here.
Look at ServiceWorkers, caching and suggestions around SRI and built-in JS libs, Web Package, Clear Site Data … all with the power to circumvent tracking protections if you don’t do a threat analysis from a privacy perspective.
I'm not a Google employee. In fact, I've been writing about "PWAs/home webapps" on iOS for 9 years 😳 and that's part of my vision that one platform shouldn't be the way to do things on the Web platform. I agree most content on this is Chrome-influenced.
That paper was pretty terrible. It exaggerated the potential of a bug that had been fixed months earlier.
Good feedback on our info about Web App Manifest. We could do better. Any other specific technologies where you'd like to know more?
The biggest points today are:
—Web App Manifest: what works, what not (and if we can expect them such as events in the he spec)
—Splash screens
—What to expect from homescreen app engine: lifecycle, in app browser for out of context navigations & how to open Safari instead
—Old meta tags are deprecated but sometimes without clear replacement such as black-translucent status bar
—Some important bugs seem solved on iOS 13 beta 1 (incl SplitView on iPad)but we find them as a surprise (sometimes a nice one); Safari change log docs don't talk about that
If you have ever added to the homescreen a webapp with a manifest (trying to avoid the unspeakable word) such as Uber, Twitter, Instagram, Starbucks or even your Feedback Assistant in the past 2 years and try to get a good experience from it, you know what I'm talking about.
+1 to Web App Manifest support. If you could make
github.com/GoogleChromeLa… obsolete, that’d be great.
GoogleChromeLabs/pwacompat
PWACompat to bring Web App Manifest to older browsers - GoogleChromeLabs/pwacompat
github.com
Background SW sync, and background push notifications in PWA for iOS?! Also webauthn API integration to Touch ID (please!)
Indeed you could do better regarding documentation and roadmap. We web entrepreneurs are dependent of @firt R&D to know what is going on on Apple/iOS side.
Webkit is supposed to enhance web platform and but it doesn’t communicate about it.
also, “add to home-screen” option on webkit iOS implementation of web share API
I am not a Google person and I've been talking about and presenting about PWAs since 2016 - and my message is always that PWAs are and must be cross-browser, cross-device. PWA is just a design pattern. We are trying to do more on MDN to emphasize this.
“iPWA” maybe, as a compromise. @johnwilander ppl are annoyed because you release major / breaking changes unannounced and leave us to blackbox test and hack workarounds. It’s obviously going to piss people off when you waste their time like this. Can’t see how you can defend it..