Apple just lost its lawsuit trying to ban iOS virtual machines (opens in new tab)

> but we have no equivalent to run OSX programs on Linux ...

It is called darling: https://www.darlinghq.org/

> Is nobody interested in implementing the OSX APIs on Linux?

The reason for wine is that windows has a dominating market position and hence you often have to use some software that is windows-only. For OSX you might want to, but there is no such dire need.

It's a very fast moving target. Apple keeps rewriting and deprecating stuff faster than they can write the documentation. As a newcomer to native macOS development, I'm sometimes struggling to even find working examples.

Is there really that much software out there which runs on macOS but neither Windows nor Linux and has no good alternatives for either Windows or Linux?

There's a truly absurd amount of software out there which runs on Windows but not Linux, it doesn't surprise me in the slightest that way more effort is invested into running Windows software than running macOS software.

There is a project like this: https://github.com/darlinghq/darling

OS X is not developed anymore for a while now. I assume you mean MacOS.

At least in the EU, there's precedent for click-through EULAs like the XCode one being unenforcable.

For Windows, MinGW has an independent implementation of the complete build environment so you don't need any VS tools, import libraries or headers. For macOS there is no such complete build root but the actual tools are available - e.g. clang is always a cross-compiler able of targetting all supported architectures and for the linker Apple's own ld64 is open source and we also have lld now although I am not certain the macOS target status.

> AFAIK you can have clang-cl on Linux

clang-cl is a frontent for MSVC command-line compatibility - you don't even need that for cross-compiling, just -target and then whatever -fms-* extensions you need for your non-portable code. But yes, Clang doesn't come with its own SDK so you will need headers and import libraries and possibly other tooling (although the LLVM procect covers a lot).

It's unfortunately not legal. Makes it also not commercially viable. Cross-compiling is nice, but if the build toolchain requires xcode, then it doesn't help all that much, since the last and most important step has to be done on apple hardware.

It would open your or your employer's business to liability.

We also use flutter, and have extensive native code that needs to be compiled for each platform/abi. What you describe is similar to the setup we used. However, more and more developers have opted to get a MacBook in order to avoid the hassle. It might make sense to just have a dedicated mac computer running a gitlab worker that builds the iOS stuff for us.

Thanks for the tip. We have considered it. Its likely the place to go once we iron out development/product. Its just unfortunate that the basics of such a CI setup is trivial to set up "in-house", for everything except software targeting apple hardware.

Not an option for many from a privacy/security standpoint.

They only way to reach a significant market share is to put up with it, wouldn't that count as abusing their position? They don't have to care, because they know that developers have no choice, and in the process they increase their hardware sales? Imagine if google wanted to produce end-user hardware. Then they limit their SDK/NDK to only work on that new hardware. And, this isn't any magic or special hardware. Just an added EULA that restricts legal use, and lack of developer support. This is pretty much apple has done. Of course, doing something like that on an already established market would be suicide. But, developers would have also to a much larger extent chosen not to target Apple hardware, if it wasn't for the market share. That's why it is abusive and a case of anti-trust. They get away with it because of their market share.

The fact that the practice is widespread doesn't mean that it's not abusive. It just means that most players are also abusive.

Considering a couple years ago, "Apple Hardware" was an intel CPU with an nvidia GPU I've always wondered why you couldn't just throw a million dollars at them so they could stick apple stickers on your rack and let you run MacOS VMs. The company I used to work for had to do crazy gymnastics just to test software and scan for malware on their OS.

Apple almost went out of business allowing macOS to run on non-Apple hardware. I think there are still people there who have an irrational fear from that time.

From a current financial/business standpoint, Apple considers itself a hardware company that includes their custom OS with their hardware. From that angle it makes no sense to allow it to run on non-Apple hardware. Sort of like Sony being ok with the PS OS running on Xbox.

Apple makes it pretty annoying to run VMs on Apple hardware too. Their license agreement has restrictions in it that are kind of unfortunate.

Exactly. At an old job, we had basically a glorified closet full of Mac minis for running our Mac CI builds on; the Linux builds just used EC2 instances.

GitHub uses macOS VMs as part of some agreement under NDA (that supercedes the terms outlined in the EULA).

See previous discussion here: https://news.ycombinator.com/item?id=29419610

Apple is anti-VM - there is a soft limit on how many VMs one can run on their M1/M2 Macs. The number is 2.

It's probably more about lock-in. They likely don't want a migration path out of their walled garden.

> Apple is not anti-VM. It is anti VM-on-non-Apple-hardware. ;-)

Do you mean they allow VMs on iPads already?

This shit is why I use Google products on my iphone: gmail, calendar (with reminders), contacts, etc. (Paid version at that: I pay for google workspace, even for personal use)

I'm not locked in to the Apple ecosystem: I can use it on my Linux desktop, or switch to an Android phone at any time.

And this is why I don't want to buy any Apple device. It seems that it's all or nothing for them. If you have a mix of apple and non-apple devices then you'll have all sorts of compatibility problems.

> I might be cynical but I wouldn't be surprised if it's a ploy to get more people into buying more of their devices.

I’d bet on just not testing that use case because they don’t care enough about it. Thus not catching and never fixing any arising issue or regression.

> You used to be able to have a web interface to Reminders, but they changed it and now you can't add tasks in the web interface.

I just used iCloud.com. Seems to work fine for adding reminders. Are you talking about an API, or the iCloud web UI?

That and their price is why I will never have an apple product too

Not necessarily. iMessage & FaceTime AFAIK are cryptographically locked onto Apple HW. I could be wrong, but my understanding is that each piece of Apple HW ships with a burned in unique private key that Apple records the public key of in it's internal database. That private key would be missing in a VM context.

It's possible my data is out of date though because iMessage spam is real & I'm not sure how that's done if it needs a valid private key that Apple can ban.

Yes, and would lead to iMessage spam and FaceTime robocalls.

> One guess: if macOS could be virtualized, it would be even easier to run things like Messages, FaceTime, and Photos on non-Apple hardware

I can be and it’s not hard to do. I assume your referring to breaking the licence agreement?

Doesn't seem to make all that much sense though. The value of their OS is how perfect it works with their hardware. Sure some people want to run MacOS on a standard desktop, but that doesn't seem to be a significant group of people.

Yeah, Apple remembers very well the "clone wars". Steve Jobs came back and killed that off.

This reminds me of when Apple tried to make it so that you can't own an iPhone, only lease it. The effort might be still ongoing, I'm not up to date. A few different turns in history and your sentence would have been "THEIR machine" and "THEIR software".

> what you were not allowed to do with THEIR software

And now cars, door locks, TVs and toilers all have software. So every comoany will be telling you what to do.

This is your daily reminder that, unlike ownership of physical objects, IP os a privilidge granted for advancing sciences and arts. Not for making things worse

I can't buy iOS, but I must use iOS to use the phone they sold me. This is legal, but just because something is legal doesn't necessarily mean that it's ethical or is good for all parties involved. The iOS emulator in Xcode is nothing short of dog shit, and it's not really an emulator as much as it's a halfway house reimplementation of iOS's userland for macOS. I don't believe there's any need to defend Apple's decision to deter people from running iOS anywhere and everywhere.

Their software is no longer their software the moment it touches my machine. My bytes, my stuff. You can delude yourself into thinking "but licenses and EULAs say you can't", but the best Apple can do is beg that I don't, and make my life hard for me to do so.

Which is extremely telling of how little consideration they have for their users.

All you are quoting is a description of how Corellium’s use qualifies as fair use, which is what the person responding to you said.

> The important part here is that it proves Apple does not have the defacto right to claim infringement on iOS. If your emulator is transformative, offers functionality beyond default iOS, doesn't abuse their services and doesn't threaten the iOS market (eg. iPhones) it should be considered lawful.

You are describing fair use. This isn’t establishing the precedent you think it is. Corellium said “hey, what we are doing is fair use” and the court agreed, describing why it was fair use. That’s all. The description of how it counts as fair use is not opening anything new up, that’s just the four factors of fair use that have been there all along.

How did they determine that it didn't affect the iPhone market? As I understand it, companies definitely buy tons of iphones set up on docks next to workstations to ensure everyone in the office can work on ios apps on real hardware, since the ios simulators aren't always foolproof and don't consider handheld ux.

They cost a shit ton though because they have to run on mac mini AFAIK. It would most likely be way cheaper if there were to run on commodity hardware.

In what way is it a breach of contract? It is using someone else's intellectual property without a license. Morally it is no different to using a cracked version of Photoshop, or playing a cracked version of Grand Theft Auto. Quite simply it's breach of copyright.

To be clear, I'm not here to be a scold or a narc. Copyright is overly abused by large corporations. My ability to shed a tear for breaching the copyright of billion dollar corporations is limited. If you want to run macOS inside KVM on your own personal rig, all power to you. I'll cheer you on from the sidelines.

But if you're using this software as part of regular business operations, I'm not going to sit here and pretend that it's morally justifiable. And it's ridiculous to pretend that anyone should have the legal right to Apple's intellectual property without a license — save, apparently, for security researchers.

Breach of contract is illegal, even though its not (in and of itself) criminal.

Whether or not you believe Apple is a monopoly, whether or not Apple is benefiting from their current status as one of two dominant smartphone ecosystems, it is obviously false to describe Apple's restrictions around app sales and payment methods as being "monopolistic policies". The policies Apple has been criticised for were not gained as a result of monopoly power.

This is obviously true because the policies in question were substantially in place by 2009, long before anyone could have said "monopoly" in Apple's direction without being drowned in laughter.

I wanted Epic to win too, but c'mon, 57% market share is not a monopoly.

Eeeh, if only Epic hasn't signed an agreement (as any iOS developer did) where they explicitly agreed with this policy, then it would be so simple.

If I might dream, maybe they also adopt Google's policy of not insisting upon billing developers[0] for the mere privilege of using their platform.

[0] https://arstechnica.com/tech-policy/2022/02/apple-shocks-ios...

The difference being of course, on Apple's stranglehold on its customers. 30% either way, app developers know that Apple users are always willing to pay more and Apple knows this, too. That's why many apps only target iOS.

Besides the income from services within Apple's apps: they could take 30% of an app's purchase price (which is still not justified tbh, the app store can't be _that_ expensive to run), but how do they justify trying to take a percentage of a subscription (like Spotify, Netflix etc) when they have nothing to do with it?

That would be like Apple being able to take a portion of banking fees from me because I have my bank's app installed on my phone (and the bank takes fees), which Apple doesn't do of course because as big as they are, you do not fuck with banks.

27%, if their demands in the Netherlands are still being taken seriously: https://arstechnica.com/tech-policy/2022/02/apple-shocks-ios...

Interesting, I seem to have missed this change from 2021. That's far more reasonable.

I can see wanting Apple to lose, but I can't imagine wanting Epic to win. That was such an ugly parasitic business model: let others take the risks to build platforms, let others operate the platforms, get the courts to mandate equal treatment for Epic to swoop in after the risks pay off.

I'd have to sympathy for the phone platforms, but it would have destroyed the console market overnight. No way consoles work if every penny of customer lifetime value has to be in the up-front sale price.

I'm glad you didn't get your wish. https://www.ftc.gov/business-guidance/blog/2022/12/245-milli...

Hopefully sideloading will also be available in Europe soon

no, it is about running iOS in VMs