All right. It's a really great way to build, positive configurations. Apple loves to throw shiny new versions of OS' at us before we can commit to use them. In real life, they probably have different versions of Xcode. Not that I've ever had an Xcode compatibility problem, but just say you did, you can put on these environments, you can put all the tools in the environment, and keep your base system safe from the slings and arrows of what you might do to test new things.



This is super useful for development because you can then take it to the next level, integrated with multiple different tools, and see how workflows. And that'll help you create a consistent, stable experience wherever you want to use it.



It's also really great on testing and validation. "It works on my machine". Thank you to the dev teams but that is not acceptable, and you have to make sure it works everywhere.



So it's great for giving someone not just the code, not just the build artifact, but the full environment. Like a regression test, they can figure out what went wrong, that sort of thing.



And then obviously, the world we live in today is all about security and access control. Providing these kinds of environments gives you a little bit more control over isolation from hardware and isolation from other things.

Let's dive in. There's local and cloud when it comes to virtualization. There's a million different tools. There's a lot of different flavors. Probably most familiar to Mac users or Mac developers is getting Fusion or Parallels or something like, running, or instead of Windows or Linux apps on your Mac, as you have to and you need to. There are other tools like Anka and Tarte, and there's the parallel to some of those, where some have cloud capabilities, some don't.



A big challenge that has arisen is that VMware sort of gave up on Apple altogether, so they do not support it. And the reason for that is with Intel, VMware just worked because it was Intel. So they weren't necessarily focused on Apple, it was just a side effect.



With ARM, they would have to invest time, money and effort into building a hypervisor like we did with Apple on a hardware and just opted in that. Of course, I left a lot of obvious developers and people that you thought this would do things in a lurch.



So these other technologies are definitely filling in. Not that I'm biased, but I put Orka on top because that's what we do. It's both cloud and local. And then there's the infamous build your own stack. And that's a lot of people I know - People from a myriad of technologies, with different degrees of success.

So let's look at a local workflow.



What we're going to do is install the virtualization tool. We're going to create container, and take that tool and configure an IPS file. And for those of you that are not familiar, IPS is now the standard format for macOS. Used to be image files, now it's IPS.

Then we'll build the initial set up and then we'll put some tools and install them in it. I'm going to use Orka Desktop. Quick little pitch here - Orka Desktop is totally free forever, no licenses. No, nothing.



But we think it's a cool way to use virtualization container from your desktop. It also works with our larger scale products as well. But even if you don't want any of that, it's a neat way to test and customize your local development environments. So I encourage you to check it out on our website. We're going to use that here.



This is a developer named Spike. Names have not been changed, his name really is Spike. He's downloading Orka desktop. What you do from there is provide a name for the VM and he said restore. So you can provide your own image, if you have an image of a Mac that you want to provide that's fine, or from here you can click the latest, and then it it'll go to Apple and download the latest the latest version of the latest OS and dump it into a container that you labeled the test.



From there, we can start up. And much like if you've ever used VMware or anything else before, it spins up a brand new fresh macOS install right on your desktop. This is using Apple Hypervisor Framework. We collaborate and complain depending on the day with Apple regularly on this to make sure the features and capabilities are what we hope to get out of the PM, but the basic set up when you're doing it from an end user perspective, it's just like setting up another Mac, you pick your dark mode, you pick your tooling.



Some things to note - Some things in virtual land can sometimes act a little wonky, but Apple's been doing a good job of correcting it. So things like Apple ID and Apple ID initiation as you move across machines can act a little different than you're used to, but they're all finally getting up to par with the physical machine.



In this case, Spike is starting to set up the development environments so he's of course immediately swapping out things with iTerm2, he's putting on Homebrew, he's adding some tools in, and he's getting the Xcode command line utilities loaded. So that's what we're seeing him do there.



Once he does that, he can sort of drive his own load Xcode. One of the things that you can do for a local workflow that's kind of interesting is, you know, pick your variance, pick your tooling, pick your libraries so you can have a VM with this version of Xcode and this division of OS installed.



You can have a totally different version with Watch and TV OS. So you can have different artifacts and libraries loaded in, and then all of this will become a little more relevant as we talk about passing the VM from person to person, or having them as a reference case for a virtual machine that you can test versus having to reset the physical machine sitting next to you in some way.



Once you have all that up, you can create a project. And in this case, we created a little sample game. And so that's sort of the "Chris downloaded this on this laptop and he's using it to develop something for play."



I think the interesting part, and again, this is the a free tool, is when multiple members of your team have it. One of the things we do above virtualization as we wrap it with containerization and OCI which makes it compatible with registries like GitHub, like Docker, like pick your favorite registry. And then that suddenly gives you the ability to pass it around, share environments, look at versions of environments and even blow things up creatively and freeze certain versions, and then have other people go in and mess with it.



But what we'll do here is take that VM we just felt, and we'll compress and package it. When I say compress and package, I'll explain it a little bit more. We'll label it and push it to a registry, and then we'll pass it around to our teammates.



So for packaging - How do we wrap these? OCI, it's the Open Container Initiative. You see it in Docker a lot. It's basically meta language that you put around a package or a container to explain the contents and how it works. We also enter some compression around that. And the reason is Mac is not Docker, as much as we want it to be sometimes. A container is not really a container, it's a full AVM. So you're talking a 90GB image for something. Whereas in Docker it would be a 90MB image. So that's a pretty radical scale difference. So compression matters a lot. But in this case you can get something like a 90GB image down to a 15GB image which is pretty good.



Again, registries all speak OCI. So whether it's your ECR industry at Amazon or GitHub or something else, you can now take this thing, read short version control it and use it anywhere. And here's some common examples of registries we have listed.



So what we're going to do now, we have another developer, Cameron, and he's loading Orka Desktop on this machine. He's created another VM. Actually sorry. Scratch that. This is still Spike. Spike is on his desktop, he's take his desk VM, and he's putting it in a registry format. All the registry format is, is location plus repository plus EMEA. And then providing credentials. It's going to compress it, push it and load it into the cloud.



The logic of real time and time preparation, your internet speed may vary. Just 15GB times your internet connection to see how that really works. Look at it work in real time. But we don't have all day. In the end, we're going to go look at the Orka Desktop registry.



So that was pushed. What this now does it allows for our friend Cameron to go to his Orka Desktop. He's going to create a new VM and label it something completely different. The reason we did not in this demo just to show, is that we container, the shell you have is completely relative. Call it whenever you want. You're passing around the VM and it's contents, but it's individual river runs it. And so in this case it's not test, it's test run. But he did point to the repository and he did pull it down just like he pulled down the code from above that immediately pulls it from the registry and start it up and load it, and login. This is really useful in case of like this where Cameron wanting to test either the version of Xcode or how Spike configured the toolchain. He has terminal, he has go and has different things. If you're just trying to even collaborate to get a development environment right for the team the way you want it to be set up.



In this case actually, he put some VS code in there and looking at a go project that Spike did and his code, to make sure not that the project is right, but really to make sure that the tooling is the way everybody expected it to be, that all the assets are set up the way they should be.



But back to our Orka Demo. So now we tested and it's downloading and bringing up the Xcode project and you can see Spike created this space for the project we're going to work on together. Our libraries are right, the structure's right, the tools are right. Everything's right. So now we can go and work in our own environment and do our own thing, but we know we're starting from the same place.



But where this gets more interesting and more powerful is as the team starts to work across more environments with all the tools, there's a way to extend this into cloud acquired bring scale and cloud brings civility. So what we're going to do next is take that same desktop and initialize it through our Orka tool so we can deploy it across a fleet of Macs and we can have multiple team members kick off multiple builds with multiple versions of the same time.



And then in this first example, we're just going to spin up the VM in Orka to show connecting, and show spinning up the VM, and show connecting to the macOS on the fly. In the next one we'll integrate our CI tool and go from there.

So in this case, we're going back to Spike. He's hard at work on his desktop. He's pulled up a terminal, it's a command-line. Orka 3.0 has just basically a little CLI agent and you can connect via VPN to MacStadium, and he's simply saying for the same VM, and if you know this last time we put it in the same repository, he's pointing Orka at that repository and saying, "Hey, I want to take this VM that I was passing around to my buddy, I want to deploy." It went, created it on the infrastructure and provided ports and mapped those through the networks. So now he's going in to see and verify that the cloud based machine is what he was looking at. And there he has it.



So the next step is avoiding all this manual stuff and actually going into CI. And this is where, scaling power and repetition get way better because you've been working on the project digitally, you're verifying things and you're QAing back and forth. But at this point you've got known builds with known versions with known tooling, so you're going to extend that environment. You're going to put plugins in, and then the big power up is ephemerality.



In iOS and macOS development, often times we're used to going locally and having machines sitting next to us or in a closet, or wherever we're working on those, and sort of being caught halfway between developer and IT manager guy, having to deal with managing the state of that machine every time, and/or going to Amazon and renting a machine. It does have EC2 around it but it's technically just a physical machine thing gets brought onto your real time and you still have to manage the tooling on site. But what you can do with CI systems, and switch to a purely ephemeral build, meaning let the plugin create the Mac environment for you at the time of execution and scale it to the things you need it to. So now you're out of the business of having to deal with that.



So a pretty popular platform, I'm sure some or all have been using is GitHub. It's where people love and live in their code. GitHub Actions is a way to automate and orchestrate things in that code repository. In this case what we're going to do is create a test called 'my CI' we're going to create a GitHub runner, and we're going to put an action on it.



There's a Hello World script, but we're also going to attach it to that VM that we just talked about. So in this case we're opening the GitHub UI. We're going into our workflows. This is now our cloud developer named Ivan, he has decided that Cameron's file can't be trusted. He's got his window split so you can see the Xcode build starting there. He's got a loop here on the GitHub runner. So you can see it in action. And then that third window is the actual Orka environment. So what happened is he told GitHub that he wanted to build that Xcode build. It went out, grabbed the image, set up the runner. Built the VM, started to excavate the code, it's running. The tests started seconds ago. It's going to run the checks. It's got a version output. It spits it out, it runs the code. And once it's done, it will spit out the artifacts. The developers can now work completely binary and Orka will destroy the VM and the infrastructure's point again.



So that's kind of this going from individual person on the desktop, sharing it with your buddy, all the way up to passing in around the cloud and scaling it up. In this case, we ran a single build on a VM, but it could be a team of hundreds of developers hitting thousands of Macs. So this scale is pretty flexible and infinite within the physics of Apple.



You may look at all that and go, "Hey that seems cool, but gosh that's a lot of work and I don't want to do all that manual stuff." And we 100% agree. That's why there's other tools like Packer. If you're familiar with tools like Docker to build images in layers, and tools similar to that, I can say I want a Sonoma OS and Xcode, or whatever. And then you make minor updates to that for various different versions of your Mac OS and the build environment. And then because Orka is Kubernetes integrated, there's an Orka API that you can do simple commands to create all these VMs and Mac environments on demand. But you can also integrate to anything in the Kubernetes tool chain.



Kubernetes is basically a resource scheduling mechanism to let you do that.