Apple can't possibly get rid of kernel extensions - that's the only way to really extend a system in new and innovative ways (user-mode drivers are more like glorified serial-port applications). So much of Apple's platform today is made up of features that were only possible by extending the OS (e.g. Multi-Finder).
Apple's going to have trouble if they keep on hindering the people that made their platform and support their ecosystem.
Here's to the crazy ones.
The misfits.
The rebels.
The troublemakers.
The round pegs in the square holes.
They're not fond of rules.
And they have no respect for the status quo.
Apple 2021:
> Follow our poorly-explained, underdocumented, and arbitrarily applied rules or we'll ban you from the App Store.
> Apple can't possibly get rid of kernel extensions
they are though. It's getting harder and harder to get them loaded (on an M1 Mac, getting an extension loaded will require 4 reboots and a journey through the recovery environment).
I'd say that within the next 2-3 macOS releases, kernel extension won't be loaded at all any more and only user-space APIs will be available for third-parties (including drivers).
From a security perspective, this is a huge benefit to users of course, but I agree that at least for advanced users, the ability to patch the kernel at random would still be beneficial for some use-cases.
There's a lot of software which runs on macOS that depends on kernel extensions: think about hardware accelerated operations in Photoshop, or how does Apple plan to support any PCI Express expansion cards in the Mac Pro line - or Thunderbolt accessories for their laptops?
hardware accelerated operations will be covered by whatever drivers ship with the OS or can be written by DriverKit.
The times when Photoshop has required kernel extensions to be loaded are long gone. The UX around kernel extensions has been very bad for years already (granted - just a trip to the system preferences, but still), so Adobe really couldn't afford such requirements already.
Not quite, given that macOS has userspace replacements for some kernel extension functions and has been gaining more as time goes on.
iOS is far more restricted in this regard — for instance, writing a driver for your USB HID device isn’t possible there, but it is on macOS, and that capability isn’t disappearing. I don’t think iOS has any of the new virtualization APIs added in Big Sur, either.
That said, the userspace APIs need to be made much more robust before kexts are deprecated, and so to me that is what Apple should be pressured to do. Kernel extensions should be a last resort, not the go-to solution, because the reality is that they’re a security nightmare and have been readily abused (remember the mess with Dropbox of all things installing a kext?)
> Not quite, given that macOS has userspace replacements for some kernel extension functions
Similar to ios - you can't install any kernel extensions to it without Apple's special permission, and have to do everything with whatever API they have implemented snd exposed.
(In macOS's case crippled APIs with backdoors - e.g. application firewalls that use these new API cannot block some Apple apps.)
> I don’t think iOS has any of the new virtualization APIs added in Big Sur, either.
It will - Apple is moving both ios and macOS towards the same goal of converging them into one product. We saw that with multi-tasking advancement and other features in ios with iPad Pro's, and the crippling of macOS from Catalina onwards.
> for instance, writing a driver for your USB HID device isn’t possible there
It is possible through the "MFi" (Made for iPod/iPhone) programme: that's how custom iPhone accessories that use the Lightning port work: they get to write their own user-mode driver for the USB port. Ditto for "Classic" Bluetooth devices.
> Apple can't possibly get rid of kernel extensions
Have you seen what Apple's been doing for the last few years? They don't care if your app or workflow breaks. If you make enough money on your app, you'll jump through any hoops they prepare.
I don't believe that is correct. It's true that you need to configure your code signing and entitlements through the Apple developer portal, but I don't believe it has to be distributed through the mac app store to run with those entitlements.
the original article quotes https://developer.apple.com/forums/thread/81281, so I guess the App Store requirement is a thing at least for some people. Not all entitlements work the same way - some can be configured through Xcode, some require special signatures provided by Apple through other back channels and some are only available to Apple themselves.
Wireguard is using the newer and non-deprecated NetworkExtension framework which requires an entitlement that's only given to app-store apps.