macOS in Docker Container

Somewhat off topic but still highly relevant for people who actually want to use projects like this: why oh why do so many build recipes such as Dockerfiles insist on pulling random stuff off the internet as part of the build process? For example, the Dockerfile in this project pulls in two Git repositories and a script at build time.

Besides the obvious build failures on heavily sandboxed build servers with no access to the internet, this forces anyone with even a little concern for security to do a full audit of any build recipes before using them, as merely studying and making available the dependencies listed in READMEs and build manifests like requirements.txt, package.json etc., is no longer enough.

I find this a very worrying development, especially given the rise in critical computer infrastructure failures and supply chain attacks we've seen lately.

The only chance at GPU acceleration is passing through a supported dGPU (>= AMD RX 6xxx @ 14.x, no chance modern nvidia) with PCI passthrough. Intel iGPUs work up to Comet lake, and some Ice Lake, but anything newer will not work.

Apple Silicon build of MacOS probably not going to be emulatable any time soon, though there is some early work in booting ARM darwin

Also Intel VT-x is missing on AMD, so virtualization is busted on AMD hosts although some crazy hacks with old versions of virtualbox can make docker kind of work through emulation

Related:

Docker-OSX: Run macOS VM in a Docker - https://news.ycombinator.com/item?id=34374710 - Jan 2023 (110 comments)

macOS in QEMU in Docker - https://news.ycombinator.com/item?id=23419101 - June 2020 (186 comments)

I set this up a few months ago as an experiment. Worked pretty well until I discovered that for iMessage to work, the application phones home to Apple using your hardware IDs, and this project uses fake values. At that point I started spiraling down the Great Waterslide of Nope, slowly discovering that the fake values are flagged by Apple and they will, as a consequence, flag your iCloud ID as a potential spammer, limiting your access from other devices. Your only option is to use a hardware ID generator script they vaguely link out to, and you can just keep trying values until you find one that "works", but there's not actually a good signal that you found one that works and isn't harming your iCloud reputation.

Worked really great otherwise, though. Very useful in a pinch.

I'd love to try and see if it's possible to simply build for iOS. Say Unity, React Native, etc.

This could be pretty awesome in terms of freedom, even if the build takes 5x more.

I did an interview with Sick Codes a while back where he talked about his approach to this product: https://www.vice.com/en/article/akdmb8/open-source-app-lets-...

Also wanna point out the existence of OSX-PROXMOX, which does something similar for Proxmox home servers: https://github.com/luchina-gabriel/OSX-PROXMOX

I’ve personally been using the latter on my HP Z420 Xeon; it’s very stable, especially with GPU passthrough.

This would be awesome to run iCloud sync on my homeserver. Currently, there is no good way to physically backup iCloud on a homeserver/nas, because it only runs on windows/apple.

Is the redistribution of MacOS images allowed by the license or is this project distributing illegal copies in plain sight on docker hub?

I wonder if progress will halt once newer versions of MacOS without Intel support are released?

Can I run docker inside this container to get MacOS to run inside MacOS? ;)

I really hate when "USB Passthrough" is used in situations when, at best, a "USB over ethernet proxy" is what is happening. That's not passthrough... It introduces a whole range of disadvantages that regular passthrough does not (and advanced passthrough might not) have.

So, to clarify things: it's QEMU running in a container, and macOS running under QEMU inside it.

This is really nice WRT the ease of installation: no manual setup steps and all.

This likely expressly violates the [macOS EULA], which says: «you are granted a limited, non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at any one time» — because the point is to run it not on a Mac. So, pull it and keep it around; expect a C&D letter come any moment.

[macOS EULA]: https://www.apple.com/legal/sla/docs/macOSMonterey.pdf (Other versions contain the same language.)

Note that this project currently provides only x86-64 Docker images, and not for aarch64.

Can this be launched on an M1 Mac? I'm trying to find a way to run a Big Sur VM on my M1 Mac on Monterey/Ventura.

This is SO useful for cross-compilation, and delivering macOS binaries!

Let’s say I wanted to run a headless Logic Pro for programmatic music production. Would I use this? Or should I containerize the application itself? It’s okay if I have to run it on Apple hardware.

Any word if this would run the iOS simulator?

Edit: it actually does!

For some reason I was convinced this wouldn't work, I was wrong. I guess docker can run any image so that makes sense.

Does this work with kde/wayland?

Looking forward to kicking the tires on this to validate functionality in Safari.

If this receives support for an Apple GPU, it will be incredibly significant!

New to containers. How easy would it be to run only the OSX Reminders and Calendar apps, or as stripped-down as possible a system to get these running without the overhead of the OS? The webapp versions of these are crippled compared to the OSX/iOS apps.

Can this run xcode?

Not to be confused with native Mac OS "containers":

https://darwin-containers.github.io/

This parent project is VMs of OSX with a docker interface, I think.

Darwin containers are runc reimplemented in terms of MacOS chroot, so you do some isolation on native macs in a docker style.

Now I just need a flake.nix that does the same thing lol (I don't like Docker...)

How many levels possible? Did anyone already try? I mean MacOS running on docker on MacOS running on docker on MacOS running on docker on MacOS...

Huh, why does this repo have its own glibc? Let's check the commit history:

    Self-host in the repo glibc to emphasize the temporariness of this patch
        sickcodes committed Feb 12, 2021

Seriously though, this is great.

> Docker-OSX now has a Discord server & Telegram! The Discord is active on #docker-osx and anyone is welcome to come and ask questions, ideas, etc.

No forum eh? Everyone should come to the live channels and ask the same questions again :)