Can’t you add most of those APIs to chrome for iOS? They force you to use WKWebView, but you can access native features as it’s a native app
-
-
Replying to @jcesarmobile @slightlylate
No, chrome for iOS is just a wrapper around WebKit
1 reply 0 retweets 1 like -
Replying to @AutomatedTester @slightlylate
Yeah, I know, it just uses WKWebView, but you can access native features from WKWebView, check
@apachecordova or@getcapacitor as example. If they can, chrome should be able too.1 reply 0 retweets 1 like -
Replying to @jcesarmobile @AutomatedTester and
Cordova’s whole deal was to implement draft Web APIs using their official JS APIs, but built natively, communicated to through WebView bridge features (WKWebView). In a way, Cordova (and Capacitor, though its goal isn’t to implement draft specs), are just browsers w more APIs.
1 reply 0 retweets 0 likes -
Replying to @maxlynch @jcesarmobile and
I’m curious why Chrome hasn’t taken on a project like this, wondering if Apple would get in the way. I could imagine something like this: “Project Cupertino adds support for modern web APIs not available in WebKit, by implementing them natively and using webkit.messageHandlers"
1 reply 0 retweets 0 likes -
Replying to @maxlynch @jcesarmobile and
Of course, this wouldn’t work for home screen-installed web apps but would extend the functionality of Chrome on iOS
1 reply 0 retweets 0 likes -
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
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]
-
-
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 - 8 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.