Every use-case? That's not happening. Sounds like you're using quirks that Apple either doesn't want you to use any more or wants you to do differently. Reading between the lines sounds like hidden APIs or overloading but I don't have enough experience with this library to comment.
Literally every company I've done any iOS development for for since iOS came out had things that they used to be able to do with UIWebView, but can't do with WKWebView. In some cases, it was core functionality, and the products got dropped entirely. In other cases, features fell permanently by the wayside. Either way, it's a major pain that WKWebView still hasn't reached feature parity with UIWebView after all these years.
In particular, it isn't possible to change out the network machinery under the hood. You use Apple's networking stack, period. Want to do something interesting, such as changing the caching behavior? Too bad. You get what Apple gives you.
That's probably precisely the point.
Unfortunately, that makes it much harder (or, in some cases, impossible) to do interesting and useful things, such as:
- Providing a permanent on-device cache for your app's help content.
- Using custom protocol compression.
- Providing an in-app VPN browser that doesn't route everything on your device through it.
- Writing functional or unit tests that involve web views.
That last one is a real pain, because it means that on iOS, all of your web-view-related tests depend on the server consistently returning exactly the same results for a given request every time, with high speed and 100% reliability. In the real world, none of those things are typically the case, which is why anybody sane uses hermetic tests, where you fake a server response, periodically updating those responses in a controlled fashion so that minor changes on the server side don't constantly break your tests. With UIWebView, hermetic testing is easy because all of the requests are made in-process, and you can swizzle the networking stack or use custom protocol handlers or whatever. With WKWebView, it is impossible, because the APIs for snagging traffic don't let you capture/replace requests for individual resources (IIRC), don't handle POST requests (IIRC), etc.
Everything that's in your web view can be read by the app anyway, so this isn't actually securing anything meaningfully. All it does is prevent all sorts of very useful networking stack manipulation that can be handy in some shipping apps, and can be absolutely critical for writing proper functional and unit tests.
