You can't, unless you run qemu there. Which you can do, but it kinda defeats the purpose. And in the best case scenario you still gonna need some changes to host, like extra kernel boot parameters most likely.
It might be interesting if you can get the linux->darwin kernel and system library translation layer good enough that the binaries in the docker image are the macos programs, NOT qemu. But that's still far off, I think.
Though maybe you can enlighten me -- why the heck would you want to? It's in a VM -- you already have fantastic isolation. Why clutter it with an extra layer of packaging that to my naive eyes adds no more value?
Like, a cool hack might be running macos...._slowly_.... on a SBC like a raspi :D But when you have real virtualization, what's the use of docker? (honest question)
Docker uses a single Linux kernel for all containers. Docker containers are much lighter weight than VMs, since each VM must run a full kernel instance.
Yes, that's what I said. (although in a comment below this one. ;))
A container is much lighter weight than a VM, yes. (and so is a chroot)
But the MacOS userspace isn't running on the linux kernel, it's running on darwin. So, macos-in-docker would be an entire qemu installation in docker, with a macos image inside that.
EDIT:
Ahhh, because it doesn't make sense to run a full operating system in a container, only a single program, I'm guessing that what OP really wants is some way to dockerize a specific (or several) macos apps. To do so, you'd need a way to wrap the linux kernel do it can provide a darwin like api, as well as the same for any required libraries.
They made a MacOS to Linux translation (not virtualization) layer of sufficient quality that you an run a decent amount of (text only) native binaries.
Docker offers a simple way to provision the VM - install software, configure networking, execute apps... Docker itself is not a VM or isolation, it uses other tools for that (linux containers in the past, not sure how it works today), it's value is in the ease of use provided by its tooling.
I'm familiar enough with Docker to know of it as a combination of lxc, cgroups, and probably other things so that I can have 1 machine, 1 kernel, and yet multiple userspaces. These userspaces are not (as i understand it) Securely Isolated from eachother, but enough so that if there existed some monstrosity of a complex piece of software, which required lots of dependencies and customization, it might make sense to put it in a chroot, or a docker for the CoW benefits.
But what I'm not following (and again, I don't get the point of Docker, I don't use it, so in trying to learn I'm assuming you must know more...) is how it assists provisioning the VM as you say. Sure, it could _change_ the provisioning of the _host_ (i'm calling the inside of the docker container the host in this context). But it's not like the binaries being executed in the container is the mac operating system. It's a VM that within THAT is the mac operating system.
If I have mac running on a VM on a linux host, I still need to log in to that mac guest to configure networking, execute apps, install software.... So how did adding docker to the picture make it easier?
You're able to create files in Dockerfile, that could be used for configuration + the stuff about networking. AFAIK macOS has a textmode as well that should work similarly to other Unixes, but I'm not sure about that, but if so, you should be able to execute commands just like with a Linux VM. Yes, there'd need to be a bridge between the macOS VM and the Linux docker container.