3 ms·

What about UTM - https://mac.getutm.app/ https://mac.getutm.app/ - based on QEMU? VM applications - Parallels, VMWare, Virtualbox etc. - have long been availabl

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).

saagarjha 4y ago
"Virtualization" in this context is not the framework but a custom hypervisor API rather than Apple's, as some vendors implemented on Intel Macs. I agree with your points about this limiting what you can do, but the replacement API is actually fairly decent in this case–there are some things that could be improved but overall it's not actually that bad.
- webmobdev 4y ago
  I do believe most of the current VMM apps - Virtualbox, Parallels, VMWare - that run on Intel Mac do offer their own custom hypervisor solution mostly tapping on to "Intel Virtualization solution" ( https://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.html https://www.intel.com/content/www/us/en/virtualization/virtu... ) through kernel extensions and / or the macOS hypervisor framework (which I think avoids kernel extension). This is possible because Intel is more "open" and readily shares their hardware literature / SDKs with developers and that is why we have had many custom, decent and performant hypervisor solution on Intel Macs. But Apple has been loathe to release similar literature for their ARM SoCs because they don't want independent competitive alternatives to their system softwares (which is ok up to a point to protect their business, but not if it crosses into illegal anti-competitive behaviour). Apple has great developers and they can surely build a decent hypervisor API solution. But we'll never know if it is the best if no custom alternates are allowed (either due to lack of hardware literature or due to Apple policies restricting such custom alternatives).
  - dwaite 4y ago
    > This is possible because Intel is more "open" and readily shares their hardware literature / SDKs with developers and that is why we have had many custom, decent and performant hypervisor solution on Intel Macs. But Apple has been loathe to release similar literature for their ARM SoCs because they don't want independent competitive alternatives to their system softwares. Are you looking for https://developer.arm.com/documentation/100942/0100/AArch64-virtualization https://developer.arm.com/documentation/100942/0100/AArch64-... ? Access to virtualization features is provided through the hypervisor framework for both intel and apple silicon products. If you have an existing Intel architecture product you might be upset that Apple is going to disable your ability to use virtualization directly via a kext. But, I have a hard time imagining someone really wanting to use their own hand crafted hypervisor rather than the one Apple built on Apple Silicon for running on Apple operating systems - especially since Apple has committed to providing additional hard things like paravirtualized hardware.
    - 4y ago

saagarjha 4y ago

"Virtualization" in this context is not the framework but a custom hypervisor API rather than Apple's, as some vendors implemented on Intel Macs. I agree with your points about this limiting what you can do, but the replacement API is actually fairly decent in this case–there are some things that could be improved but overall it's not actually that bad.

webmobdev 4y ago
I do believe most of the current VMM apps - Virtualbox, Parallels, VMWare - that run on Intel Mac do offer their own custom hypervisor solution mostly tapping on to "Intel Virtualization solution" ( https://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.html https://www.intel.com/content/www/us/en/virtualization/virtu... ) through kernel extensions and / or the macOS hypervisor framework (which I think avoids kernel extension). This is possible because Intel is more "open" and readily shares their hardware literature / SDKs with developers and that is why we have had many custom, decent and performant hypervisor solution on Intel Macs. But Apple has been loathe to release similar literature for their ARM SoCs because they don't want independent competitive alternatives to their system softwares (which is ok up to a point to protect their business, but not if it crosses into illegal anti-competitive behaviour). Apple has great developers and they can surely build a decent hypervisor API solution. But we'll never know if it is the best if no custom alternates are allowed (either due to lack of hardware literature or due to Apple policies restricting such custom alternatives).
- dwaite 4y ago
  > This is possible because Intel is more "open" and readily shares their hardware literature / SDKs with developers and that is why we have had many custom, decent and performant hypervisor solution on Intel Macs. But Apple has been loathe to release similar literature for their ARM SoCs because they don't want independent competitive alternatives to their system softwares. Are you looking for https://developer.arm.com/documentation/100942/0100/AArch64-virtualization https://developer.arm.com/documentation/100942/0100/AArch64-... ? Access to virtualization features is provided through the hypervisor framework for both intel and apple silicon products. If you have an existing Intel architecture product you might be upset that Apple is going to disable your ability to use virtualization directly via a kext. But, I have a hard time imagining someone really wanting to use their own hand crafted hypervisor rather than the one Apple built on Apple Silicon for running on Apple operating systems - especially since Apple has committed to providing additional hard things like paravirtualized hardware.
  - 4y ago