I’ve implemented a WKWebView for a purely personal app with very specific but very minimal requirements and… “just” is doing a lot of heavy lifting here. You can “just” use the API and you get a fully functional web browser without any UI, but you certainly aren’t going to attach any meaningful custom UI to it that way without digging deep not just into internals at the binding level but at the WebKit level. I’m not saying it’s a bad design either, but it’s definitely not a trivial investment.
Don't want to be snide, but you're talking about the high barrier-to-entry for implementing a nice, customized WKWebView in a project that isn't a web browser. In such a case, the WKWebView brings with it a bunch of complexity that wasn't already there otherwise.
If your project is itself a web browser, then all that complexity is already inherent to the project, whatever you choose to build it with. It's just that the "digging deep" would be in the docs for how to glue Apple's low-level DOM/JS/etc library frameworks together in mostly-undocumented ways; rather than in the docs for how to feed WKWebView the right delegate logic in just the right place to get it to do something that'd be easy if you were directly doing it yourself.
Didn’t take it as snide but even just the delegated logic isn’t so simple. Most of my personal project was just a specialized browser, and really basic functionality was much more complex than I’d hoped. I got it good enough to use and haven’t maintained it since because it was just for my own use, so maybe the APIs have become less complex since.
