Of course, this wouldn’t work for home screen-installed web apps but would extend the functionality of Chrome on iOS
-
-
Replying to @maxlynch @jcesarmobile and
I agree with your idea. It would be an interesting idea. The thing that nags at back of my head is that we add all these features to browsers but app stores will still pump out apps. Google controls 80% of the web browsers and 80% of mobile.
1 reply 0 retweets 0 likes -
Replying to @AutomatedTester @maxlynch and
Unless google says they will promote PWAs over apps I can’t see developers being incentivised to write pure web apps over phonegap apps or pure mobile apps. Maybe I am too pessimistic
1 reply 1 retweet 0 likes -
Replying to @AutomatedTester @maxlynch and
We have considered various approaches over the years, including this one. Several issues make it unsustainable [1/N]
1 reply 2 retweets 3 likes -
Replying to @slightlylate @AutomatedTester and
First, the implementation would be wildly disjoint. It'd be a frankenbrowser that has *some* extra features, but not others. We thought hard about this for Web Payments, e.g., which incidentally highlights a second major issue: features that depend on SWs can't be added [2/N]
1 reply 0 retweets 2 likes -
Replying to @slightlylate @AutomatedTester and
This shows up in many features where extensibility points can't be implemented (e.g. Payment Request Handler). This makes it an even further franken-browser. But we also lack worklets. This puts pressure on us not to design features the right way, which is *bad*. [3/N]
1 reply 0 retweets 2 likes -
Replying to @slightlylate @AutomatedTester and
Perhaps most importantly, fidelity is low and the expansion of possible attack surface area is high. WebKit is tough from a security perspective (we can't add our own sandbox or process model!), exacerbating it via this channel is tougher still. [4/N]
1 reply 0 retweets 2 likes -
Replying to @slightlylate @AutomatedTester and
In the usual usage model for webviews, you're running 1p content and/or take responsibility for content you run (think of it like adding a 3p script to your site). Very different model to arbitrary untrusted content (which is what browsers specialise in). [5/N]
1 reply 0 retweets 1 like -
Replying to @slightlylate @AutomatedTester and
Features that get added this way have to try to emulate WebIDL semantics, which is *super* tricky. And slow. [6/N]
2 replies 0 retweets 2 likes -
Replying to @slightlylate @AutomatedTester and
Cordova features didn't need to hold themselves to the same semantics bar. The design language there wasn't WebIDL, and doing a slightly different thing was OK...the developer was entirely awares, after all. Not so on the web. Everywhere we diverge from spec is a bug. [7/N]
1 reply 0 retweets 5 likes
For all of these reasons, plus unease w/ adding a broken browser to ecosystem, I recommended we steer away from this approach. A tough call, but Apple must be on notice. We see the damage they're causing and won't paper over it while having to play by unfair rules. [FIN]
-
-
Replying to @slightlylate @AutomatedTester and
What does it mean for Apple to be on notice?
2 replies 0 retweets 3 likes -
- 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.