hckrnws

Fun fact: the macOS EULA^ contains a "bug" in section 2.B and section 2.B.(iii) that technically precludes 99% of people from running macOS VMs: the EULA does not stipulate any other download mechanisms than directly through the Mac App Store, even though System Settings has been the dominant source of updates for some time.

^ https://www.apple.com/legal/sla/docs/macOSSonoma.pdf

Wouldn’t that be covered by “or through an automatic download”? Regardless, OS upgrades have been done via the Mac App Store and not System Settings for nearly a decade now.

Don't they get pushed via System Settings some time after a major update has been released (usually when the first or second dot release is out)?

Wouldn't surprise me if the source for the updates is the same engine that supplies the App Store.

> Fun fact: the macOS EULA^ contains a "bug" ...

Disclaimer: IANAL, just someone who's work has at many times involved working alongside lawyers drafting contracts.

As always, the problem most armchair legal "experts" forget is you have to consider the agreement in front of you as a whole (and also in the broader context of the contract's jurisdiction). You can't go cherry picking individual clauses.

In your case, we can easily prove your "bug" claim to be erroneous ...

1. We start with the very area you highlight. There are a number of things I could comment on here. But let's stick to one ... note the references to "Apple Software", note in particular the capital letters. This means "Apple Software" is a defined term.

2. All we then need to do is look back and we find the origin of "Apple Software", which is on page 1, the very first clause, 1A. Its a chunky old clause but the TL;DR is its telling you the license agreement applies, both the current version ("Original Apple Software”) as well as any future versions (“Apple Software Changes”) in whatever form they may take ("whether preinstalled on Apple-branded hardware, on internal storage, on removable media, on disk, in read only memory, on any other media or in any other form").

3. Clause 2, as its title suggests, is mostly concerned about "Permitted License Uses and Restrictions". The "how you got the software that is subject to these permitted uses" is, I'd say, largely dealt with in the original definition of Apple Software.

This is a long-standing issue...while VMs on x86-based Macs can log into iCloud (and thus sign into Xcode teams and the MacOS App Store), VMs on ARM Macs have been unable to do so.

Looks like this is coming, although ironically the first beta of the OS lists the following Known Issue:

"Users will not be able to sign-in to iCloud and related applications. (128924562)"

Sigh, but the day is coming when a VM can actually be useful for iOS/MacOS devs on an ARM Mac.

There's still the 2 VM limit that severely limits the usefulness of the feature. Is there any word on whether they are lifting that?

A Mac studio could probably run a dozen or more VMs, but Apples artificial limit makes it very hard to make Apple Silicon build farms.

If you're OK with unsupported means, there are ways of bypassing that limit. See https://khronokernel.com/macos/2023/08/08/AS-VM.html .

I hope this will allow running NetworkExtensions in VMs as well. As it stands today, it's only possible to run NetworkExtensions on physical Apple hardware, making it a pain to apply any modern CI-based workflow to them.

Does anyone knows what is the current status of Apple silicon hardware emulation in qemu?

Yessssss!!!!!!!!

FFS I just got a used MacBook with severely damaged screen because this was not available. :/

They can request to pay more if you want a mac to run virtual machines and login to icloud.

Bring back OSX Server to allow more things than base macOS.