I wouldn't say WKWebView is 'the old way', it isn't marked as deprecated and just because there's a new class that's easier to use doesn't mean they replace older classes that let you do more stuff. As you've found out, you've run into problems, but I have no idea why you would think not to use WKWebView if you can't do what you need.
That said, in general, never, ever use in app browsers for surfing the web. We use them for specific pages on our website that should interact back to the app, otherwise we tell the system to open the URL in the user's browser
I remember those, but we'd moved to WKWebView almost as s soon as Apple marked it deprecated.
We don't have many web views anymore, we still use a couple for signup and for the user to change their privacy settings because we need to change some behaviours based on the results, so we inject something to know if the user made changes and close the view. But there's no way for the user to navigate out to the greater web from the pages.
Anything else and we instruct the os to open URLs
`WKWebView` has issues that made it untenable for use as a web browser last year, but there's nothing I'm aware of preventing its use for common in-app browsers.
Yeah, it provides all the features of a browser without the UI for them. You embed the WKWebView (not WKView, I mistyped) in your browser app and call methods on it to load URLs, go back and forward, and so on.
WKWebView can indeed be used to spy on users - clicks can be intercepted, URLs sniffed, and custom JS injected (including a way to call back to the app’s runtime via a WebKit message passing mechanism). Considering all other iOS browsers (ok maybe some still run UIWebView) have been made using this component (because App Store reviews enforce this), it’s clear that it has to provide extensive control over displayed contents.
WKWebview is good for a very simple in app link opener, if you want to do a full featured browser around it (Chrome iOS), the public API is nowhere near ready for that.
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.
Apple has been using web views for apps for more than a decade - recognizing that such an object is more generally usable than just "a browser" was a motivation for WebView (now WKWebView) existing as a platform API from the earliest days of WebKit being a thing that existed (The logical extreme being the original WebView API exposed an objc interface to the DOM)
WkWebView is used a lot in apps to present content that isn't immediately obviously web content, rather it is just using HTML/CSS as a presentation layer. One example is the activity feed in Instagram - I only know this because once upon a time the page lost CSS on a reload and I got to see it in all its link-blue-bordered glory.
The Safari controller is for when you're linking out to an external web site and want the user to behave the way they would in a normal browsing session.
Depends on the implementation. Sadly, thanks to Apple, in many cases we are still forced to use UIWebView since WkWebView is so broken for Cordova apps.
> This is an incorrect understanding of how web views are implemented.
No, it’s not. Nothing requires you to use SFSafariViewController.
As you yourself noted, WKWebView exists and grants the application effectively complete control over it.
UIWebView also still exists, and despite being deprecated, remains usable.
Finally, even if everything but SFSafariViewController were removed from the OS, nothing stops the application developer from embedding their own replacement webview implementation.
> However, it would be possible for the platform vendor to restrict use of the web view such that only certain more powerful APIs can be used by browser-style apps, while other less sensitive APIs can be used by all apps.
Such a restriction would be equivalent to the existing SFSafariViewController, but regardless, I must reiterate: absolutely nothing stops the application developer from embedding their own replacement implementation.
> This is because pretty much all of the APIs involve an IPC from the embedding process (e.g. an app under third party control) to another process that actually powers the view under the control of the browser engine (usually the content/renderer process).
Again, nothing stops the application developer from embedding a replacement for your hypothetical sandboxed webview API.
Besides having access to JIT, being multiprocess, getting the backward/forward swipe for free and finally having a decent way to estimate progress, WKWebView is actually worse than UIWebView and less customizable. UiWebView, as slow as it is permits you to do stuff like saving pages for offline viewing, ad blocking, cookie control and so on.
If they use WKWebView I'm not even sure they can implement the features of a plain old browser, never mind include addons/extensions.
That said, in general, never, ever use in app browsers for surfing the web. We use them for specific pages on our website that should interact back to the app, otherwise we tell the system to open the URL in the user's browser
reply