Orka 4.0: Build and Test iOS and Android on one Apple silicon fleet

If you build a mobile app for both Android and iOS platforms, there's a good chance you're paying for two of everything. Take a team running 40 Macs for iOS build and test, because Xcode only runs on macOS, plus about 20 x86 VMs or an emulator-as-a-service subscription for Android build and test, where emulators have always lived.

That team maintains two pipelines, works with two vendors, and pays two bills. When a build or test fails, someone has to work out which of two sets of infrastructure caused it, and the results they need are split across two systems. The release still waits until the slower platform finishes.

With Orka 4.0, the same team runs one Orka cluster. Each Android emulator runs on the same Apple silicon host as its paired macOS VM, so iOS and Android build and test share one fleet, one pipeline, and one provider.

What's in Orka 4.0

What's new	What it means for your team
Android emulators	Run Android emulators to support build and test flows on the same Apple silicon Macs as your macOS VMs, managed with the same tools.
VM User Data	Customize every VM at deploy time with a script, instead of baking a new image for every change.
Fewer stuck jobs	VM disks now survive node outages, resizes finish reliably, and a node recovers by itself after a macOS display crash, which means fewer stuck jobs waiting on someone to log in.
Designed exclusively for Apple silicon	Every image you build runs on every node, with no Intel versions to maintain. Android emulators run natively on the host Mac, with no x86 translation.

Build and test Android on the Macs you already run

Orka 4.0 puts Android testing on the Macs that already run your iOS jobs, instead of on a fleet someone has to size, patch, and secure separately.

‍One fleet to manage. Run iOS and Android tests from the same Orka footprint, with one capacity plan and no separate Android fleet to maintain.

Automatic emulator cleanup. Each emulator deploys alongside its macOS VM and is deleted with it, so nothing is left running on the node after a job.

One tool for both platforms. Manage Android emulators and macOS VMs with the same orka CLI and REST API.

Built-in networking. Orka connects each emulator to its VM and returns the connection address at deployment.

Multiple emulators per VM. Cover more Android versions or device profiles in a single job by running several emulators alongside one VM.

Plan for about 6 GB of host memory per emulator, on top of the VMs on that node. The sizing guidance in our docs walks through the math.

One command starts an emulator:

orka emulator deploy --vm <VM_NAME> --platform android-36 --image-type google_apis --device-profile pixel_9

Keep your device lab or device cloud for the tests that need real hardware; Orka covers the tests that don't.

Works with your existing CI and tests

Orka 4.0 fits into your existing pipelines. Your CI system stays the same, whether that's GitHub Actions, GitLab, Jenkins, Buildkite, or TeamCity, and so do your iOS and Android test suites. The change is where the Android side runs: your pipeline deploys the emulator next to the macOS VM that runs the job, instead of calling out to a separate fleet or service.

The emulator is reached from its VM over an ADB relay, and standard adb commands from the VM work as usual. Your test runner connects to it the way it connects to any other emulator.

Skip the image rebuild

Most macOS CI teams know the golden image problem. A token rotates, a tool needs a new version, or one team needs its VMs enrolled in MDM, and the only way to get the change into a VM is to build, test, and push a whole new image. Multiply that by every team and every Xcode version, and keeping images current becomes a job of its own.

With User Data, the change ships as a script instead. You pass a script when you deploy a VM, and it runs once, as root, on the VM's first boot. Every VM can start from the same base image and set itself up for its job: register as a GitHub Actions or GitLab runner, enroll in Jamf with a one-time invitation, or pull the config a particular team needs.

Orka reports whether the script is still running, succeeded, or failed, in both the CLI and the API, and your pipeline can wait on that before a job starts. When something needs to change, you edit the script, and the next VM you deploy picks it up.

See Bootstrap VMs with User Data to get started.

Plan your move to Apple silicon

Orka 4.0 runs on Apple silicon only. Apple has said macOS 26 Tahoe is the last macOS release for Intel Macs, and the developer tools mobile teams depend on are following: Homebrew stops building packages for Intel Macs in September 2026 and stops supporting them entirely in September 2027.

If you still run Intel nodes, nothing changes today. Orka 3.6 stays supported for Intel through March 2028, and we recommend completing your move to Apple silicon by December 2027. If your cluster mixes Intel and Apple silicon nodes, there are three ways forward:

Upgrade your Apple silicon nodes to 4.0 and move your Intel nodes to a separate cluster on 3.6.
Keep your current cluster on 3.6 and move your Apple silicon nodes to a separate 4.0 cluster.
Replace your Intel nodes with Apple silicon, so the whole cluster moves to 4.0.

Talk to your account team about which option fits your cluster.

What's next

Orka 4.0 also introduces a new self-service upgrade model, so you can schedule and manage your own Orka upgrades. It's available for early access in November, starting with a first set of customers, and we'll expand it from there.

Orka 4.0 is generally available October 28, 2026. To set up Android emulators on your cluster, read the Android emulator docs at docs.macstadium.com, or contact MacStadium to plan your 4.0 rollout. To see it running first, join our live walkthrough with an Android emulator demo and Q&A: Register for the Orka 4.0 webinar. Or read the Orka 4.0 release notes for the full list of changes.