This code in WKView: - (void)dealloc { _data->_impl->page().setIconLoadingClient(nullptr); _data->_impl = nullptr; [_data release]; _data = nil; [super dealloc]; } ...seems like it would be susceptible to the same problem described in https://bugs.webkit.org/show_bug.cgi?id=174751. If ~WebViewImpl is called after setting _data->_impl to nullptr and one of the pending callbacks that get invoked when invalidating the callback map calls on WKView to do some work involving the _data's _impl, we'll probably end up with a null deref.
Interestingly, this isn't normally an issue when closing the page because Safari actually tells the WebPageProxy to close() very early in the teardown process. That's not to say there shouldn't be a mechanism at the WebKit layer, though, to ensure that we don't crash if the WKView is released through some other codepath in Safari that doesn't explicitly close() the page before continuing with teardown.