VMware passes through the id of the physical hardware into the guest VM. So if you're running on apple hardware, this works. If you're running on a PC, there are hacks to 'borrow' the serial number of some ancient imac and have it work still (even ancient systems are still allowed to log into icloud, and those ancient systems didn't do any cryptography so all you need is a valid serial number that nobody else is using).
> If you're running on a PC, there are hacks to 'borrow' the serial number of some ancient imac and have it work still (even ancient systems are still allowed to log into icloud, and those ancient systems didn't do any cryptography so all you need is a valid serial number that nobody else is using).
Hackintosh users have to do something similar to be able to sign into iCloud.
The serial number doesn't have to be valid (as in existing on a physical machine) to work, though. It just needs to look valid (be generated using the same methodology as real serials). In fact in order to prevent accidentally using a serial tied to a machine owned by somebody else, the recommended procedure is to generate a serial and check its AppleCare status to verify that it's not tied to a real machine, and if it is to regenerate and check until you find one that isn't.
> even ancient systems are still allowed to log into icloud, and those ancient systems didn't do any cryptography so all you need is a valid serial number that nobody else is using
The ancient random serial numbers are also in a standard format.
> Apple devices manufactured after 2010 generally have 12-character alphanumeric serial numbers, with the first three digits representing the manufacturing location, the following two indicating the year and week of manufacture, the next three digits providing a unique identifier, and the last four digits representing the model number.
But if this serial number was shared between several people, all of whom might have logged in with a different apple cloud id, would that somehow cause apple to trigger something?
i could be completely wrong here, but i do seem to remember something about there being some physical chip in the machine that needed to be present for e.g. iMessage to work. this was a while ago but iirc they also somehow incorporated local Apple ID account management into that system.
Note that the EU's Digital Markets Act will probably stop all that bs, as requiring to use one core platform service to develop for, and distribute to, another (iOS) is against that law.
Third-party app stores and outright website-based app distribution are coming next year anyway.
That's interesting, I did not know about this legislation. I'm not European, but it seems that even outside of Europe, people will benefit from this change.
If Apple was compelled to support a first-class iOS development experience on Windows, all this would do is immovably stunt the continued improvement of iOS development on macOS. There is a material degree of OS integration / cooperation in IOS development with Xcode. If Apple released a second-class development experience I’ve no doubt that you’d spare no time in making similar insinuations that it’s some sort of artificial constraint.
Xcode and iOS Simulator on other platforms would involve porting AppKit as well as writing all-new Darwin virtualization for those platforms. Xcode is thoroughly a Mac native app, and the iOS/watchOS/tvOS/etc simulators currently just run the respective userlands on top of the underpinnings that macOS shares with other Apple platforms.
It'd be rather similar to the situation with Docker, where Xcode and the simulators would run markedly better on macOS than on other platforms due to fewer layers being necessary. Developing for iOS on Windows or Linux would technically be possible but it wouldn't be very pleasant.
Been using Xcode since 2012 and I think it's great. It has it's flaws, sure, but overall I think it's a really good development experience. What do you dislike about it?
I've been using it since it was known as Project Builder and also don't have many complaints. It's not perfect, but it's not bad. I spend plenty of time in the IntelliJ-based Android Studio and haven't found it to be much of an improvement (and in fact, find that its "smarts" get in the way as often as they help).
Well, QEMU has no graphical acceleration for macOS (no virtio drivers for XNU and Quartz) so it's basically unusable - software rendering has been historically borked on macOS, and never well tested.
I'm sure it's possible, depending on the kind of application and the tools you use to build it. But xcode won't build your application if you don't link your account. I believe it needs that to "sign" the application with apple.
There may be ways to get around this but I don't of any.
You can manage your signing identity entirely using Apple's website and just not use automatic provisioning. (I do that anyway even though I build on macOS as I just don't want our build system tied to Xcode just so we can use the automatic provisioning.)
