By Ricky Kirkendall
With all the exciting new updates to Xcode and Apple platforms announced at WWDC this week, it’s a good time to reflect on the state of cloud development for Apple platforms. While the platform capabilities, Swift language, and supporting toolset have steadily advanced over the years, setting up Macs for cloud development is still weirdly painful.
On AWS, you are not spinning up a normal VM. You are provisioning bare-metal EC2 hardware. It takes a long time to become usable, it is metered by the day, and the cheapest option still costs more than a dollar an hour. Even after so much of the industry has leaned into the benefits of cloud development, I understand why so many teams still end up building and shipping iOS apps from someone’s laptop.
Macs feel familiar to Linux users, but the moment you try to make them behave like cloud boxes, the assumptions start breaking. Remote access, networking, lifecycle management, identity, cost controls, IDE support, and developer ergonomics all become real problems.
So this week, when a customer asked us to make Mac instances usable inside Crafting sandboxes, I was interested for two reasons. First, Mac cloud development is annoying enough that making it feel simple would be genuinely useful. Second, it was a good test of what agents can do when they are working inside the right environment.
For Linux workspaces, Crafting already makes remote development straightforward. You can open an SSH session with one command, or open a remote session in VS Code, Cursor, JetBrains, Zed, or whatever IDE you use. The question was whether we could create a similar workflow for Macs.
The answer ended up being a small Crafting CLI extension backed by AWS identity federation, EC2 Mac lifecycle management, sandbox hooks, and SSH configuration.
From the developer’s perspective, it should be easy:
cs mac Sandbox/Workspace
Underneath that, Crafting provisions the Mac, connects it to the right network, configures the sandbox as a jump box, writes the local and remote SSH settings, and opens the shell or IDE session. When the sandbox starts, the Mac becomes available. When the sandbox terminates, the Mac gets cleaned up.
I built the working version in roughly two hours.
The interesting part was not that an agent wrote code quickly. Models are already good at writing code. The interesting part was that the agent had a real place to work.
It had a full, batteries-included sandbox. It had the relevant repos checked out. It had the Crafting CLI. It had documentation. Most importantly, it had AWS credentials through identity federation so it could run lifecycle hooks, inspect generated files, query AWS, test SSH, and iterate when something failed.
That is what made it able to work end to end.
For this kind of project, writing code is less than half the job. You have to test against a real AWS account. You have to wait for real infrastructure. You have to figure out which SSH settings belong on the local machine, which belong on the jump box, and which connection strings IDEs will accept. You have to run the thing, watch it break, and fix the actual failure.
An agent that can only produce text can give you a plausible implementation. An agent working inside a real environment can get much closer to done.
I made a plan, gave the agent the relevant Crafting repos and docs, pointed it at the AWS EC2 Mac material, and had it inspect how our existing CLI opens remote IDE sessions. From there, it worked backward into the Mac connection flow.
It built the Terraform, wired it into sandbox lifecycle hooks, generated the SSH configuration, tested the jump-box path, verified the AWS resource state, and packaged the result as a Crafting CLI extension. By the time it got back to me, I ran the command and it worked.
I try not to overreact to agent demos, but there is still something satisfying about watching VS Code open directly into a Mac in the cloud.
Crafting also makes the Mac part less annoying in ways that go beyond the demo.
The normal EC2 Mac experience has a painful startup cost. With sandbox pools, you can keep ready sandboxes attached to available Macs during the workday, so engineers can claim one without waiting for bare-metal hardware to come online.
You can also make the cloud footprint more efficient. In this setup, the Linux workspace mostly exists as a jump box and control plane for the Mac. It is a thin workload. Crafting lets you put those workloads into a designated node pool, run them at higher density, and tune capacity around how many actually fit on a node. That is much better than treating every sandbox like it has the same resource profile.
The same applies to the rest of the workflow. Crafting already has built-in secrets, browser-based remote sessions, a CLI that agents are good at using, and access controls for both users and agents. The Mac workflow inherits those primitives instead of rebuilding them from scratch.
This opens up more interesting development loops. An agent inside Crafting can now contribute meaningfully to Mac-based workflows. You could use Kubernetes interception from a Crafting sandbox to test a beta feature in an iPhone app, all from one environment, without a physical Mac on the desk. CI/CD setups can build and run test suites in the same environments where agents are capable of validating and remediating problems. I would’ve loved a setup like that working as a full-stack iOS engineer.
The ceiling for agents is not only determined by model quality. It is determined by the environment the model gets to operate in. A strong model with no tools can write a decent plan. A strong model with a repo, a CLI, credentials, logs, tests, lifecycle hooks, and a safe sandbox can do much more of the actual engineering work.
Crafting is the layer between an agent and the messy reality of engineering work: repos, CLIs, services, clusters, secrets, test loops, and deployment constraints. It gives agents a controlled place to work and the primitives they need to validate their work against real systems.
That does not replace engineering judgment. I still needed to know what we were trying to build, understand the customer’s network shape, review the plan, and decide whether the result made sense.
But the leverage was different.
Instead of spending a day wiring up Terraform, lifecycle scripts, SSH config, extension syntax, and test runs by hand, I spent my time shaping the problem and checking the result. The agent handled the boring middle because Crafting gave it a place to do real work. That’s the big unlock.
