6 ms·

With Apple, it is all about exerting control and crippling softwares that don't align with their goals. Don't be surprised if Apple suddenly forces developers t

With Apple, it is all about exerting control and crippling softwares that don't align with their goals. Don't be surprised if Apple suddenly forces developers to only use their virtualisation API on macOS, just like they did for application firewalls (that are no longer allowed to have their own custom kernel extensions for "security" and "stability"). They are slowly squeezing macOS to make it more and more like ios.

coldtea 4y ago
>are no longer allowed to have their own custom kernel extensions for "security" and "stability" Why the "scare quotes"? Sounds totally justifiable. Third party kernel extensions have always have had issues with both security and stability.
- webmobdev 4y ago
  It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Now that Apple is forcing macOS developers to use their APIs, these software developers are at the mercy of Apple which is exactly what Apple wants - they will now be forced to negotiate with Apple for any changes or new features they want. Apple can now cripple a system developers ability to provide the kind of system software they want to offer to user. End result is that Mac users and developers both lose.
  - coldtea 4y ago
    >It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. They don't have to be "the only one who knows how to write such bug-free or secure system software". They just have to disallow a class of potentialy buggy and insecure software running with kernel level access, and that's enough to keep tons of additional attack vectors off the OS. I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension.
    - webmobdev 4y ago
      > I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension. Which is all ok till you consider that experienced developers that make good system software can offer better software than Apple, which often may have no incentive to support softwares that isn't aligned with their business interest. Application firewalls is an example, because they can also prevent Apple software and services from data-mining a users personal data. (You may trust the Apple codebase on which all Application firewalls on macOS are forced to run, but what if I don't and want alternative? And if you say, "Then don't use macOS", note that's a very anti-consumer view and is toss to everyone's consumer rights). Virtualisation is another example where non-Apple options can be better than Apple's as Apple would prefer that you do everything on their OS than use alternate ones. Or when you don't want to use Apple software because of the terms you have to accept to use it.
      - coldtea 4y ago
        >and if you say, "Then don't use macOS", note that's a very anti-consumer view Not much more "anti-consumer" than "if you prefer formal attire, then just don't buy Levi's - as opposed to insist the make black suits and bow ties". Though I understand the convenience - I'd like to have the option myself in some cases. What I dont like is third party companies forcing you to install a kext if you want to use their product, for non essential reasons (that could be handled in userland). At least this forces them to work with userland APIs (looking at the "haxie" peddlers out there).
  - mbreese 4y ago
    This isn’t the way Apple wanted it to work. In a perfect world vendors would write good kernel extensions that were stable and wouldn’t crash a system. Instead, in the real world we got vendors that wrote horrible and unstable code that was required by IT departments. For example, instead of implementing a firewall using Apple technologies, in a stable manner, we got an “enterprise” firewall kext that would crash whenever a USB network card was plugged in. And I mean crash the computer. My USB-C dock was absolutely worthless because of this exact issue. Vendors forced this on Apple. IT departments that were primarily Windows shops would just blame Apple instead of the vendor. Because their software worked for Windows, so why was it only a problem for Apple? I know the IT department at my $WORK had this mentality. Now at least I have a stable system and I don’t miss not being able to add my own kexts.
    - webmobdev 4y ago
      There are also examples of popular applications with kernel extensions that have been used by thousands / millions of users without any issue for years now on various macOS versions. Why should such system developers be punished with an inferior alternative, especially when it also serves Apple's interest by being anti-competitive too!?
  - saagarjha 4y ago
    > That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Apple definitely cannot write bug-free code, but your claim that third-party software worked fine without issues is factually incorrect. Third party kernel extensions have historically been a major source of instability and crashes.
    - webmobdev 4y ago
      > but your claim that third-party software worked fine without issues is factually incorrect. That's a misunderstanding of what I was trying to convey. To clarify - I was specifically talking about existing application firewalls and VM applications for macOS that use / used kernel extensions and already have a large userbase on macOS. Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Especially when we consider how such a move is also anti-competitive and anti-consumer, and thus helps Apple's business. Forcing developers to make an expensive migration from their own tried-and-tested and stable codebase over which they have full control, to use Apple's OS API's is a developer hostile move. Even more so when you consider that a developer will now have to rely on Apple to fix bugs or add new features - which Apple may have no inclination to do so so if it feels it isn't aligned to their own business interest (thus anti-competitive). I personally have been using some of these applications that install custom kernel extension, and my macOS (3 versions of macOS over a period of a few years) has never crashed or become unstable because of them, so far. If an application that used a kernel extension made my system unstable or crashed it, I obviously wouldn't use it and will uninstall it. But completely taking away my choice as user to customise my OS with kernel extensions, and reducing my choices (as a customer) by taking away the ability of developers to offer a non-Apple custom software solution that is better is also obviously anti-consumer.
      - dwaite 4y ago
        > Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API. Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore. Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update? Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.
saagarjha 4y ago
> Don't be surprised if Apple suddenly forces developers to only use their virtualisation API on macOS As far as I can tell, nobody has made a third party virtualization solution for Apple silicon nor is anyone really looking to do so. I don't think this conclusion is particularly surprising.
- webmobdev 4y ago
  What about UTM - https://mac.getutm.app/ https://mac.getutm.app/ - based on QEMU? VM applications - Parallels, VMWare, Virtualbox etc. - have long been available on macOS and so its not as if nobody suddenly wants it just because their macOS is running on ARM SoC. There can be many reasons why they haven't yet migrated to Apple Silicon Macs, some of which may be the smaller userbase, the cost of migrating to a new platform, lack of literature or support from Apple, Apple not allowing them to offer their virtualising application using their own custom kernel extensions or Apple asking them to wait and use their virtualisation API under development. To be clear, I don't believe there is anything wrong with Apple offering built-in OS API solution for applications like firewall, virtualisation, graphic engines etc. The problem is when they say you can only use those and don't allow competition. When a particular type of software on macOS is forced to use just one particular API, it stunts all such softwares using the APIS as they can't really offer any major distinction and can only offer the limited features the API provides. Worse still is when such practices is actually meant to restrict competition to protect their business interest. For example, it is clear that Apple is pivoting more and more into commercialising user privacy (monetised through its services) and advertising (by data mining personal data through these same services). In such a case, existing softwares that offer privacy protections (like application firewalls and even alternate operating systems on macs) are examples of competing system softwares that impede this goal. Obviously Apple cannot directly ban these softwares without negative user backlash. But it can ensure that such softwares are crippled by forcing users to use limited API's and / or by limiting the operating environment they run on. (The frog is slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog - and we developers and users are slowly losing more a more control over our Apple computers and device).
  - 4y ago

coldtea 4y ago

>are no longer allowed to have their own custom kernel extensions for "security" and "stability" Why the "scare quotes"? Sounds totally justifiable. Third party kernel extensions have always have had issues with both security and stability.

webmobdev 4y ago
It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Now that Apple is forcing macOS developers to use their APIs, these software developers are at the mercy of Apple which is exactly what Apple wants - they will now be forced to negotiate with Apple for any changes or new features they want. Apple can now cripple a system developers ability to provide the kind of system software they want to offer to user. End result is that Mac users and developers both lose.
- coldtea 4y ago
  >It's not "scare quotes" - it's to convey sarcasm and justified scepticism. Sure, poorly coded third party kernel extensions can have security and / or stability issue. That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. They don't have to be "the only one who knows how to write such bug-free or secure system software". They just have to disallow a class of potentialy buggy and insecure software running with kernel level access, and that's enough to keep tons of additional attack vectors off the OS. I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension.
  - webmobdev 4y ago
    > I'd rather trust just Apple on kernel-space (which I have to anyway, as they make the kernel), than Apple + any random third party software that wants to run as a kernel extension. Which is all ok till you consider that experienced developers that make good system software can offer better software than Apple, which often may have no incentive to support softwares that isn't aligned with their business interest. Application firewalls is an example, because they can also prevent Apple software and services from data-mining a users personal data. (You may trust the Apple codebase on which all Application firewalls on macOS are forced to run, but what if I don't and want alternative? And if you say, "Then don't use macOS", note that's a very anti-consumer view and is toss to everyone's consumer rights). Virtualisation is another example where non-Apple options can be better than Apple's as Apple would prefer that you do everything on their OS than use alternate ones. Or when you don't want to use Apple software because of the terms you have to accept to use it.
    - coldtea 4y ago
      >and if you say, "Then don't use macOS", note that's a very anti-consumer view Not much more "anti-consumer" than "if you prefer formal attire, then just don't buy Levi's - as opposed to insist the make black suits and bow ties". Though I understand the convenience - I'd like to have the option myself in some cases. What I dont like is third party companies forcing you to install a kext if you want to use their product, for non essential reasons (that could be handled in userland). At least this forces them to work with userland APIs (looking at the "haxie" peddlers out there).
- mbreese 4y ago
  This isn’t the way Apple wanted it to work. In a perfect world vendors would write good kernel extensions that were stable and wouldn’t crash a system. Instead, in the real world we got vendors that wrote horrible and unstable code that was required by IT departments. For example, instead of implementing a firewall using Apple technologies, in a stable manner, we got an “enterprise” firewall kext that would crash whenever a USB network card was plugged in. And I mean crash the computer. My USB-C dock was absolutely worthless because of this exact issue. Vendors forced this on Apple. IT departments that were primarily Windows shops would just blame Apple instead of the vendor. Because their software worked for Windows, so why was it only a problem for Apple? I know the IT department at my $WORK had this mentality. Now at least I have a stable system and I don’t miss not being able to add my own kexts.
  - webmobdev 4y ago
    There are also examples of popular applications with kernel extensions that have been used by thousands / millions of users without any issue for years now on various macOS versions. Why should such system developers be punished with an inferior alternative, especially when it also serves Apple's interest by being anti-competitive too!?
- saagarjha 4y ago
  > That doesn't mean that Apple is the only one who knows how to write such bug-free or secure system software. In fact, in the past most of the popular application firewalls (and VM softwares) on macOS came with their own kernel extensions and have worked fine without issues, and millions of users have used such applications without any issues. Apple definitely cannot write bug-free code, but your claim that third-party software worked fine without issues is factually incorrect. Third party kernel extensions have historically been a major source of instability and crashes.
  - webmobdev 4y ago
    > but your claim that third-party software worked fine without issues is factually incorrect. That's a misunderstanding of what I was trying to convey. To clarify - I was specifically talking about existing application firewalls and VM applications for macOS that use / used kernel extensions and already have a large userbase on macOS. Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Especially when we consider how such a move is also anti-competitive and anti-consumer, and thus helps Apple's business. Forcing developers to make an expensive migration from their own tried-and-tested and stable codebase over which they have full control, to use Apple's OS API's is a developer hostile move. Even more so when you consider that a developer will now have to rely on Apple to fix bugs or add new features - which Apple may have no inclination to do so so if it feels it isn't aligned to their own business interest (thus anti-competitive). I personally have been using some of these applications that install custom kernel extension, and my macOS (3 versions of macOS over a period of a few years) has never crashed or become unstable because of them, so far. If an application that used a kernel extension made my system unstable or crashed it, I obviously wouldn't use it and will uninstall it. But completely taking away my choice as user to customise my OS with kernel extensions, and reducing my choices (as a customer) by taking away the ability of developers to offer a non-Apple custom software solution that is better is also obviously anti-consumer.
    - dwaite 4y ago
      > Their popularity, and relative stability of the kernel extensions these applications used, is proof that Apple's black and white approach of "all non-Apple kernel extensions are bad" is rubbish. Thats not what they are saying though. They are saying, when we have official userspace API, we will remove access to the old kernelspace API. Thats not to say the kext is bad or evil. It is to say you won't be able to accomplish it in a kext using public api anymore. Were there badly written kexts before? Were there kexts with interactions? Were there kernel API and whole subsystems kept in for years because some popular enterprise product refused to update? Absolutely. I'll refrain from mentioning the one I had in mind which hit all three checkboxes.

saagarjha 4y ago

> Don't be surprised if Apple suddenly forces developers to only use their virtualisation API on macOS As far as I can tell, nobody has made a third party virtualization solution for Apple silicon nor is anyone really looking to do so. I don't think this conclusion is particularly surprising.

webmobdev 4y ago
What about UTM - https://mac.getutm.app/ https://mac.getutm.app/ - based on QEMU? VM applications - Parallels, VMWare, Virtualbox etc. - have long been available on macOS and so its not as if nobody suddenly wants it just because their macOS is running on ARM SoC. There can be many reasons why they haven't yet migrated to Apple Silicon Macs, some of which may be the smaller userbase, the cost of migrating to a new platform, lack of literature or support from Apple, Apple not allowing them to offer their virtualising application using their own custom kernel extensions or Apple asking them to wait and use their virtualisation API under development. To be clear, I don't believe there is anything wrong with Apple offering built-in OS API solution for applications like firewall, virtualisation, graphic engines etc. The problem is when they say you can only use those and don't allow competition. When a particular type of software on macOS is forced to use just one particular API, it stunts all such softwares using the APIS as they can't really offer any major distinction and can only offer the limited features the API provides. Worse still is when such practices is actually meant to restrict competition to protect their business interest. For example, it is clear that Apple is pivoting more and more into commercialising user privacy (monetised through its services) and advertising (by data mining personal data through these same services). In such a case, existing softwares that offer privacy protections (like application firewalls and even alternate operating systems on macs) are examples of competing system softwares that impede this goal. Obviously Apple cannot directly ban these softwares without negative user backlash. But it can ensure that such softwares are crippled by forcing users to use limited API's and / or by limiting the operating environment they run on. (The frog is slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog - and we developers and users are slowly losing more a more control over our Apple computers and device).
- 4y ago