I fell into the same trap a while back. Bought a mac, fixed some OSS I maintained (and I do note the documentation was quite crap "Well, Apple. I made it... despite your directions"), the next OS X update killed it again, gave up, sold the mac.

Felt like an enourmous waste of money and time.

> Felt like an enourmous waste of money and time.

And it certainly was. But sometimes you have well-appreciated macOS users that you have not yet managed to convert out of it. In that case, instead of throwing away your money you can easily [0] install a Catalina vm inside linux or windows. With a quite small effort, you can readily check that your program compiles and runs on that shitty system.

[0] https://github.com/myspaghetti/macos-virtualbox

Is it legal? I thought you can run MacOS only on Mac hardware.

This is a TOS problem that I could personally not care less about. The bigger issue is that even though you're running in a VM, you're not going to get all the necessary hardware working for Mac OS. For me, I couldn't get my graphics drivers properly set up and as such couldn't get any OpenGL stuff to work as it would be on a real mac, so it was a no-go.

At least you can XCode working and do macOS builds.

It's against the Terms of Service, which may or may not have legal implications based on where you are. However, Apple doesn't really give a shit unless you're going to profit off of it. The Hackintosh community has been around for ages and Apple doesn't do anything unless someone starts selling pre-installed Hackintoshes.

I don't see how such a thing might be illegal, but the current century never ceases to amaze me. In any case, it is just a (very popular) shell script that downloads a few publicly available files and runs them in a controlled environment. It does not harm anybody.

It's technologically doable, but running MacOS on non-Apple hardware is against the ToS.

Is it? Anyhow, it does not mean that it is illegal, which was the original question. I guess most ToS are not enforceable in practice. The worst that may happen is that you "lose the warranty" of your macOS install and you cannot ask Apple for support. No big deal.

So I'm not an expert, but isn't it still simply pirating software? I mean what's the difference between this and pirating Photoshop for example?

Adobe sells Photoshop, Apple does not sell macOS (and freely publishes download links for the latter.)

Apple does sell macOS (as a part of MacBook, iMac etc).

The difference is that the cited shell script downloads software that the copyright holder himself makes freely available.

It is like downloading binary freeware.

The ToS are a separate issue, but I doubt they'd hold in Europe for example.

Just because software is made available using a public web server does not mean that you are free to use it as you please. It's distributed along with a ToS agreement that governs its use.

Bringing in words like "illegal" can be fraught because I don't think we've seen a court case (in the US at least) about exactly how binding a "click-wrap" agreement actually is, but there's no question that projects like the one linked upthread violate the terms of the software license.

Aeah, how much more proprietary and strange are the Apple API's going to get? They'll have control over the entire vertical, and can put all kinds of undocumented crap right in the silicon.

even to the syscall level, like the MAP_JIT flag to mmap() https://developer.apple.com/documentation/bundleresources/en...

not optional and requires special app entitlements to enable. So you are not going to write portable code that has a JIT without apple-special code.

And that JIT has additional considerations on Apple silicon, where there is specific hardware that needs to be taken into account: https://developer.apple.com/documentation/apple_silicon/port...

I ran into another quirk with MAP_JIT recently, but going the other direction in time.

If you supported an older platform (High Sierra, which up until recently was... valid...), you would need to explicitly _not_ pass MAP_JIT into mmap there. It makes total sense once you find the bug, but it was also an easy one to overlook.

Tracking that down was kind of annoying.

A JIT is a major potential source of malware enablement and thus a security consideration.

applogies if its an ignorant question but, if the os had proper access protections, even with a buffer overflow or other exploits to an app itself, how can that enable malware just by having a JIT?

It cannot; Apple's security policy towards third-party JITs is misguided. Such a feature is useful if you are interested in providing defense-in-depth for a JIT that you have taken effort to secure and would like stronger, hardware-backed mitigations for. The API should really be opt-in for the apps that want it–the real consumers of it are going to Chrome and Firefox.

JIT requires bypassing exploit mitigations e.g. W^X. JIT doesn't make an app that's already been subverted any more dangerous than it would otherwise be, but it makes it easier to exploit the app in the first place.