This would be interesting to see, I'm guessing the implications are being able to build iOS projects without requiring a Mac at any stage of the development process.
The pioneer of software dictatorship will probably make this impossible or illegal as soon as it gains any traction though. And people will probably congratulate them for it in the name of "security".
As a “closed iOS” advocate, I personally believe the ability to do development outside of a macOS is a great idea. I’ve long wanted to make iOS apps, but I don’t have the money to shell out for a Mac. Yes, Hackintoshes are a thing, but you need certain hardware to do so, and even then, it’s still difficult (last I checked).
For casual app development I just run MacOS in a free VMWare instance on my Windows machine. It has no graphics acceleration but otherwise works flawlessly.
IIRC, macOS EULA expressly requires that the OS be run on Apple hardware. If it's run in emulation (which is permitted), the host must run on Apple hardware anyway.
Apple is not a software company, it's an electronic appliance company, like Samsung.
Of course, apple won't go after individuals who violate this provision. But is a cloud vendor or a CI vendor tried to pull that off, Apple would smash them.
If you don't agree to the EULA you don't have a license to use MacOS at all, which means you downloading it is (in many countries) a crime.
The question whether or not a EULA is enforcable is only relevant for products you bought which have software preinstalled - it is often argued under First Sale (and similar) that the EULA isn't applicable.
Anyone aware of any options for Hyper-V? Last time I tried this it was pretty impractical to have VMWare/VirtualBox co-exist with Hyper-V for things like Docker and WSL2, but maybe that has changed?
Newer versions of VMWare work under a Hyper-V host [1]. I'm not sure if macOS runs properly in that mode though. I also had some success a while back running macOS under WSL2 using KVM [2], though it was pretty buggy and a pain to set up.
This has been possible for a long time. For the install media, Apple hosts them and will give you the dmg file for free.
The only concern is the terms of the EULA so that's why the earlier poster says "for casual development"
There are a lot of guides online, including "one command" shell/powershell scripts that will automatically pull down the right files for you, and use the vmware/virtualbox api to create the vm automatically, and patch the bootloader to get Catalina or Big Sur loading, etc - if past experience is any indication, people probably already have Monterey beta loading fine already.
again, it's not a matter of "how" it's whether you (or Apple lawyers) care about the EULA.
in addition to what @barkingcat said, for vmware to be able to boot a macos virtual machine you'll need it to unlock it for that OS. Search for vmware unlocker is a free utility that depends on your vmware version, run it once and you're done.
It's very doable, it takes like 10 minutes if your internet is reasonably quick and if you're lucky you might even get GPU acceleration out of it. I used this to set mine up: https://github.com/foxlet/macOS-Simple-KVM
I can appreciate if this is too much money for you, but I recently bought a 2014 macmini i7 16GB and 512SSD on ebay for $440 shipped to my door. I needed something that could handle bigsur for some app development, and that was the best $/effort solution I found. Add another ~60 for a usb switch and cables, and I can easily switch between my primary and mac.
In general, there's a pretty good second hand market for macminis, and if you shop around you can probably get something usable for under $350 shipped.
Actually it is easy to build Hackintoshes, even with AMD.
Catalina is running stable with Apple ID and all the bells and whistles. In the past when Apple ignored updating Mac Pro Trashcan for several years, we have build a monstrous PC with Hackintosh to run FinalCut.
Search for Open Core Catalina.
I had a hackintosh back in 2009, and recently decided to go at it again and built a custom PC with all the components from https://www.tonymacx86.com/buyersguide/building-a-customac-h....
After a week I never managed to get the OS to install without the installation process crashing towards the end, so it's not "actually" easy even if you know your way around a computer.
Believe me now is so damn easy that it's funny.
Now you have a lot of tools to load kexts and configurations.
In the old days we loaded kexts manually:)
It's not legacy code until the day Apple definitively axes Intel models. The writing is on the wall yes, but they are still selling Intel Macs and they are not deprecated yet. The majority of development still happens on Intel Macs.
I built an 11th-gen Rocket Lake 128GB Hackintosh with Thunderbolt Display support+2 LED Cinema Display recently and it's been great. Thunderbolt 3 support on a Hackintosh has been nice. Just hoping for Thunderbolt 4/Maple Ridge drivers/11th-gen iGPU drivers if ever.
I've never been an iOS or Mac developer, but I have had a few 5,1 Mac Pros. The release of m1 mac minis pretty much killed the used market for those, but you may still be able to find one for cheap. I was able to find a few 12-core 24-thread dual xeon models for around $250, but had to be patient. Add in 64GB of ECC RAM and an SSD upgrade, to Mojave or Catalina, and you have a beefy enough development system for around $500. Those 12c/24t will get smoked by an m1 mini for a lot of tasks, but if memory matters then it's probably still the best bang for the buck. Also, you'll need to find a GPU....
I do think consoles should be required to be open (as I think all phones should be), but I am sympathetic to the idea that consoles are somehow in a different class than phones or desktop/laptop computers. Consoles feel like purpose-built game machines, whereas phones feel like general purpose computers, albeit small ones.
Really, though, I don't have a good reason why I think it might be ok to lock down a purpose-built game machine. So maybe that's just not ok either.
You'd need to emulate macOS hardware, not iOS, to do that. In that sense, what you describe is already possible (running Xcode in a macOS VM on commodity hardware).
I did this exact think back in 2012 with a PhoneGap/Apache Cordova app. It had to use Xcode to run the app in the iOS Emulator. So I spun up a virtual machine on my Linux box. It worked extraordinarily well!
In the case of the poster you are replying to. Yes, Swift is open source and there are compilers for other platforms. The problem comes in with Apple's SDK and their proprietary libraries. Those are what are required to build an app that'll run on an iOS device. Those only run on macOS/OSX.
These days, unfortunately, it is not possible. Well, you can virtualize MacOs, but you can not connect iOS device to it, nor you can run a virtual iOS device inside it.
Apple went out of its way to deliberately disable physical phones connecting to a virtual MacOS.
Any other USB device can be connected, but not an iphone.
VmWare Player with USB configured to version 2.0 did the trick for me. I tested it with an iPAD Pro and iOS 14. The VM was running the newest macOS release from a few months ago.
It works quite well for me. Simulator works fine (though graphics are slow) and so does connecting a physical phone (by passing through the USB controller).
I'd like to chime in here that it's very fucking frustrating that the best & most convenient free tools for virtualizing macOS aren't available on macOS, considering macOS has shipped with a damn hypervisor for years. Setting up a vanilla installation of arbitrary, older version of macOS for testing, or for maintaining build environments for long-support-life Mac software, should be one command, shipped with the dev tools. But no, instead it's "pay for a 3rd party solution" or "break the EULA and run it on Linux".
(yes, I'm aware of a bunch of fragile solutions involving VirtualBox, but they tend to be slowish, that's also supposed to be paid if you're using the extensions for commercial operation IIRC, and several versions of macOS/OSX remain a huge pain in the ass to set up on it regardless)
a motivated individual can still accomplish it, there are multiple ways documented on the web if you google a little.
its however not permissable, as you cannot buy apple software without agreeing to their licence, which disallows running it on anything but apple hardware.
There's no difference in the binaries built by Xcode running directly on Apple-branded hardware and Xcode running in a macOS VM in a generic (or perhaps metal, if nested virtualization isn't available) ec2 instance.
Well, may be I am unlucky one, but I just tried and freshly installed MacOS in VirtualBox VM can see any other USB device except iPhone XR.
This setup used to work find a few years ago but stopped a at least on 2018.
Will try VMWare.
Hypervisor.framework (and Virtualization.framework) in macOS run a Apple written hypervisor. This hypervisor implements VirtIO for its devices and can run macOS VMs (with full graphics and hardware acceleration, at least on the M1). One could conclude that it was implemented this way to allow compatibility for macOS on different hypervisors (and also so that Linux would just work on theirs).
Speculation: I would be surprised if there isn’t a team internally working on a stripped down variant of macOS (or just Darwin + drivers?) designed for deployment as a server so that they can drop a bunch of racks of Mac Minis (or, with budget, some kind of blade arrangement with a Apple Silicon chip on it) into a datacenter and build a huge build farm (using VMs to run iOS and macOS, or jails if they ever get some kind of container setup). It would be dramatically better than having to manage x86 and all that extra bloat of average servers once you got through the growing pains. And they could guarantee security way better.
I think Apple's silicon runs a very high margin, I imagine. Will the savings from running datacenters on their own silicon be big enough to offset the lost opportunity of selling more M1?
I don’t think the demand curve is matching supply at this point, and the processors, while powerful, will be outdated in a relatively short timeframe. Utilising them in a build farm would be one way to put any excess to good use.
And for Trillion dollar firm a way to get into a big and never touched now business. The Apple server and business object aside, the m1 might be a good line of business to try. This is particular so now Apple is not controlled by intel on their product development.
The next will be the gpu market.
No need to do the extreme just the one that can handle normal server load, flight simulator, even just 2k AA game.
Someone is doing the market analysis (not selling but real market segment under analysis), really what market one can hold the trillion dollar company.
I am not sure they can do Apple car which is mainly about hydrogen or electron capacity. But server and game …
Probably only in that they're both qemu forks. That one you've shown is more about using qemu (probably with hypervisor.framework) to run multiple Intel macOS instances for server consolidation and dynamic provisioning. It's probably not any closer to running iOS than upstream qemu.
I want to get Android or iOS on QEMU with USB passthrough so that I can isolate it and pass it its own modem. (say a Quectel modem via a miniPCIe to USB card)
Is this possible as it stands? At least in bits and pieces I can put together?
I see in the instruction they're using iOS 12. Is it possible to run iOS 15? Does the image need to be jailbroken? Is there anything that allows to download and install iOS apps from the app store and run them?
Only for future releases. If it works currently for iOS 12, it'll keep working for those builds of iOS 12. I fail to see how Apple can break what already works for code they can't/won't change.
Wrong. There are people who would like hardware kill switches but are required to run either iOS or Android apps for work. With iOS in a VM, you could truly "log out of work" and shutdown that part of your phone when not needed without carrying a second work-specific device.
And they would not want to do that on a Librem phone. Librem phone is for the tiny subset of people who want a computer with a free BIOS as well as a fully-free Linux distro like PureOS.
> Why isn't it _actually_ a fork though? I don't like when projects do this and don't actually make it a fork.
From Wikipedia:
In software development, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software.
This seems exactly what happened here.
Are you asking why they didn't use Github's "fork" mechanism?
Github's "fork" mechanism creates a relationship between the two repositories that the developers of this software may not want. For example if the "upstream" ever becomes unavailable, all Github "forks" are auto-deleted. This is surprising to some people and definitely not what an independent separate development would want.
At first glance that sounds awful, but presumably if it was remaining active, it would simply exist again (just not as a labelled 'fork') on next push?
Bit weird/worrying as a user or whatever looking for the repo on Github between deletion and push, but probably not a big deal in the grand scheme of things?
This is _actually_ a fork. A fork is a separate repository sharing history with another.
The GitHub UI's concept of a "fork" is unrelated to Git. GitHub doesn't detect you made a proper fork if you don't use its API or UI to do so, and requires contacting customer support to change it.
I read a blog post a few years back discussing some issues with Github's fork feature (as opposed to just creating a new repo that isn't explicitly linked to the original within Github's UI). From a quick search, I believe this[1] was it, and I remember finding it fairly compelling.
It was an interesting read because Linus has repeatedly dismissed github for kernel development, and he never explains why in detail (as a consequence most news reporting his soundbites are not very informative either)
I'm assuming they mean it wasn't forked by clicking the "fork" button in GitHub, which creates a link at the top of the new forked repository page connecting it to the parent repository.
It is a true fork though, both projects have the same commit history.
