WebExtensions API session on WWDC 2020 was interesting – I think the last part is something important to zoom in on because although the WebExtensions API hasn’t been fully implemented (link) Apple are interested in eventually implementing it fully with the focus right now on the most heavily requested features being implemented first. What I am hoping is that in the long run there will be a feature complete API that’ll give developers two options for extension – native code or JabaScript based on extensions using WebExtensions API.
There hav been a few developers looking at the announcement such as Raymond Hill who is the lead developer for uBlock Origin. He noted that although it is a step in the right direction it is missing features (link) the uBlock Origin requires. There is an opportunity for Safari to squeeze into a power user niche where Chrome is making life difficult with the move to manifest v3 (Firefox appears to be getting some love from the power user community who have decided to adopt some aspects of manifest v3 but not the divisive features that have angered many extension developers.
Apple has made some big investments into Safari over the last year as seen by the technology previews they put out regularly to developers. The session at WWDC 2020 not includes covering new APIs that are now supported but also dealing with compliance when compared to other browsers (link). Where I work we have a website that makes extensive use of web workers but issues with Apple’s implementations resulting in the website suddenly not working (buttons won’t work etc) until the cookies and cache are cleared then everything gets back to normal – hardly the ideal experience for an end user.
Driver Kit and System Extensions is being expanded to support more hardware as Apple moves to close off the kernel to third parties and as noted before Apple is dog fooding that by moving some of its own drivers out of kernel space into user space as seen by the below screenshot from macOS 10.15.5 System Profile:
I’m sure once the PCI and SCSI Driver Kit matures I’m sure we’ll see Apple move of its drivers move out of the kernel – maybe even see GPU drivers moved out of kernel space which will help with security (check out the security change log relating to the kernel and how man relate to GPU drivers) which should result in a more secure and robust kernel – not that I’ve had an issues mind you *touch wood*.
Architectural differences are covered (link) and the part that surprised me is that OpenCL and OpenGL are both supported (although deprecated) because I would have thought that Apple would use the move to a new platform to remove old technology but I guess one big change is enough for most developers handle at a time. It will be interesting to see how long OpenGL and OpenCL hang around in macOS, it will also be interesting to see what the performance of OpenGL games are like – whether there is a noticeable improvement over OpenGL running on Apple’s own custom GPU vs AMD or Nvidia GPU (which depends on drivers that Apple have very little or no control over).
A consistent narrative I’ve seen online in forums and on YouTube is about the massive improvement in performance of macOS, iOS etc. So I had a check through WWDC videos and found this session (link). So it appears that not only are we see a refresh visually but also a refresh under the hood. With the focus on reducing memory usage I wonder whether this is bought on by the fact that RISC based processors tend to punish developers with bad performance if they don’t spend the time to properly optimise their code.
The move to ARM will particularly interesting given that the Apple SoC is made up of dedicated modules that require developers to spend time taking advantage of those features through the use of frameworks provided by Apple rather than using the CPU was the dumping ground then hope that it’ll solve the problem of a poorly optimised code base which fails to use the frameworks that Apple make available to developers.
This is why there is so much focus on optimisation – the full benefit of the Apple SoC is made apparent when developers make use of what Apple has to offer. For me, I tend to wait for Apple’s second or third generation hardware but we’ll see what the hardware is like – given that they’re going straight from x86-64 to ARM64 is should mean avoiding the whole situation of shipping devices with 32bit CPUs then even with the transition to 64bit CPUs not every device can run 64bit macOS. The other example of avoiding 1.0 is the Apple Watch (the very first one) which was limited in many ways such as lacking GPS built in thus requiring it to be paired with an iPhone. The more recent example would be when Apple launched the iMac 4K with the AMD Radeon R9 M295X which only just had enough grunt to run the display with very little headroom left over if one wished to play games.
With all that being said, given that Apple’s ARM SoC is a mature platform and along with acquiring experience regarding building Mac’s with high resolution screens I feel pretty confident these days that Apple know what they’re doing. I guess the speculation in the tech world will be over which Mac will receive the ‘Apple Silicon’ make over first and whether there is some rebranding or whether all of the products retain the same branding. Oh well, we’ll need to wait and see what happens but what ever the case maybe the next few years are going to be interesting times.