macOS 10.14 Mojave and 10.15 are, so we’re already warned, bringing quite a lot of internal changes which will affect some of the apps that we use.
The obvious one is the 64-bit requirement: Mojave is the last version of macOS which will run 32-bit apps ‘without penalty’. It’s an important point, but unlike when iOS went 64-bit, I can’t find a single third-party app here which is still 32-bit. My only remaining 32-bit apps on this Mac are Apple’s. If you haven’t checked your own Macs, my free 32-bitCheck tool is in Downloads above.
A more technical change which may have slipped your notice, unless you’re a developer, is that WebKit’s WebView is about to disappear.
Apple has been warning of this for some time now, so most developers should already have changed their code so that their apps will continue to work smoothly when WebView does vanish. But older apps which still rely on WebView may well stop working. The impact could be quite substantial.
One of the powerful features built into macOS is easy access to browser-like windows which render and display HTML. These are part of WebKit, which underpins Safari, the Help Viewer, and features in very many apps. If you use LockRattler, it is how that app shows a page from this blog, when you click its Check blog button.
When I write ‘easy access’, I do mean very very easy. The code below is that used in LockRattler 4.7.1 and earlier to open and display the appropriate URL here.
Once it has worked out which URL to open, all that is needed is the one-liner
A lot of existing apps do much fancier things with WebViews, of course, but they’re an amazingly cheap way to load, render, display, and work with HTML. They have also been available in every version of macOS from 10.2 onwards.
Some time in the future, [NO** possibly even with the full release of Mojave this autumn/fall** NO: see Postscript below: Apple is not changing this in Mojave] that WebView feature is going to be lost from macOS. Code which relies on it being present is likely to stop working. In some cases, that means entire apps.
It has a replacement, WKWebView, which in many respects does a similar job, but has some snags. The problem which caught me out is that, although WKWebView was introduced in macOS 10.10, there were some bugs in its use which weren’t cleared until 10.12 or later. These mean that apps which need to be compatible with macOS 10.11 (and possibly 10.12) can’t use WKWebViews as fully as they should. In particular, you can’t create them using Xcode’s Interface Builder, but have to create them entirely using code – something which Apple has never got round to documenting.
This wouldn’t be a big deal, but as usual the documentation isn’t as helpful as it could be. Using Apple’s example code (which is still in the documentation for Xcode 10) results in the WKWebView window never opening. A bit of tweaking (from wild inspiration) finally produces a functional replacement such as that shown below.
When WebViews are lost from macOS, a great many older apps will still expect to find them, and you should expect their behaviour to be untoward at least. I suspect that will kill far more apps than any future requirement for them to be 64-bit. And there’s no easy way to discover which apps are dependent on WebView.
The good news to end this is that, having migrated LockRattler (my only app which used WebViews) to the new WKWebView, I can at last offer a new version which should work fine when WebViews have long since gone. It also has some tweaks to its ToolTips, and is available from here: lockrattler48
and from Downloads above.
Thanks to @bradeeoh for responding very quickly to confirm that WebView is not going away in Mojave. He points out that “many deprecated APIs remain on the system for many years.”
Thanks also to @provuejim, who points out that a thread earlier this month established that apps which use WebView in iOS 12 can be submitted to the App Store, and confirms that WebView remains in iOS 12, at least.
That is very reassuring – but we do still know that WebView is going away at some time in the future, just not when. If you’re a developer, take heed. If you’re a sysadmin or user, keep taking the updates, as you will need them in the future.