Docker-OSX

acts when that step or job succeeds, so if a subsequent step/job fails, you can adjust it and start up where you left off, using the caches artifact to restore the workspace state. This complicates debugging efforts and I personally don’t do any optimization until the pipeline is reliably green each time. I just deal with slow builds and switch to other stuff or work ahead while they run. 2. Fail fast. The CI run should bail out if any critical steps don’t pass, so anything further down doesn’t run for no reason, burning compute time and delaying queued jobs waiting for a runner. While developing the pipeline, watch the logs and when you see something you don’t like, slap the cancel button, or collect a couple things you need to change and iterate with passes with 2-3 changes. 3. Use adequately spec’s hardware. Xcode is resource heavy and compiles need plenty of memory and cpu cores. Play around with what is a good compromise between power and cost. See if your project builds faster with more cpu cores, or faster cpu cores, etc. 4. Cache build dependencies. Mac builds have cocoapods or something close to that, and whatever that package system pulls down can be reused between builds, just remember that cache issues are a pita to spot, reproduce, and regression test, so I’d again not add this in until you’re green. 5. Write your pipeline steps in a regular bash script. Then make your CI jobs and steps just execute the shell scripts. This allows you to develop them all locally, executing the script/step you need and then CI becomes just a wrapper to glue it all together and do some caching and optimization. The more of the process you can work on locally the less you have to run on CI and wait for. Once the scripts are all working locally, wire them into CI and see what breaks. ProTip: whatever breaks on CI due to missing software, deps, configurations, is going to break for any new hire engineer trying to get up and running, so document those things and make sure your getting started readme has them, and you’ll make new hires onboarding suck less :) As for useful error messages, or lacktherof, I’d like to introduce you to programming, we’ve been waiting for you ;) but for real, useful error messages are the rare exception, and many apis are this way. That’s not to say it’s ok, but you kinda gotta learn to work around it. I’m sure there is enough context to point you in the right direction. Also, the errors might be from random pieces in your build pipeline and not necessarily from the actual Xcode build, so make sure you know what is erroring in addition to what the error is trying to say. > At least Googles process is quite simple and can be dockerized. One man’s simple is another man’s “practically impossible”. Simple comes from familiarity/exposure which builds knowledge and confidence. Anyway, you can totally run your builds in docker if you want to, and many do, but I’d personally not introduce more complexity until you have your pipelines running the slow way with the least amount of mental modeling to do. Once you know it all works, then have a go at running the build you know is good, inside a docker container (which in this case is just packing up kvm/qemu/libvirt to facilitate the running of a vm back on the host, but it means you can run mac containers on Linux runners, which will be much cheaper than Mac runners since those are usually Mac hardware) https://github.com/sickcodes/Docker-OSX > Also why do I have to pay Apple $125 a year when it costs $100 in the US? The exchange rate from CHF to USD should be in my favor. Couple theories. 1. They have additional processing or tax expenses when dealing with your currency which they aren’t going to eat the cost of. 2. The higher price could be to deter abuse if for some reason there is an abnormal amount originating from accounts who pay with that currency.

led but they were all doing VR modified aside from Magic Leap, but Magic Leap changed what they were trying to do (peizo driven fiber laser retina projection) to the same (but a nice implimentation) of a waveguide setup. Well produced. Also ugly, stupid, too expensive, and not good enough. Anyway, looking forward to seeing the release. I'm 100% with you on the native container support. I think with how any of this stuff works to break the rectangle, native container support is crucial. Does it start going through the browser? WebASM? WebGPU? WebRTC? Vulkan not CUDA? OSX via Docker with Nvidia GPU passthrough over mTLS and then run docker containers in a yet to be released version of OSX that has native container support. https://github.com/sickcodes/Docker-OSX

ed graphics are available on mac-host-to-mac-guest, and to my knowledge only mac-inside-mac. (But the “outside” mac can probably be a virtual machine as long as it has a GPU. Even if it’s a passthrough device. Should be technically possible at least and I would guess that it just works.) Finally, un-accelerated graphics in a macOS VM are surprisingly fast these days. At least on my Linux machine in qemu-kvm, recent versions of kernel / qemu etc. It’s noticeably slower than having properly accelerated graphics but muuuuch faster than I was expecting from macOS VMs I’ve used before. Finally, headless access to virtualized macOS goes really fast. Working on a mac VM through mosh-shell is excellent.