Running iOS UI tests without owning Mac hardware means using a cloud-hosted macOS CI runner or a managed Mac-in-the-cloud provider, since Apple's licensing requires Xcode builds and simulator runs to execute on genuine Apple hardware or a licensed virtualized Mac. GitHub Actions, GitLab, Bitrise, CircleCI, and Codemagic all offer hosted macOS runners preloaded with recent Xcode versions that can run xcodebuild test against the iOS Simulator directly in the pipeline, covering the vast majority of XCUITest needs without any physical device. For running against real iPhones or iPads rather than the simulator, cloud device farms such as AWS Device Farm, BrowserStack, or Sauce Labs provide access to physical hardware over the network, at the cost of sending build artifacts to a third party. Dedicated Mac-hosting providers such as MacStadium are a middle option when you need persistent, dedicated Mac infrastructure without buying and racking your own Mac hardware. Simulator-based runs are almost always sufficient for standard UI regression testing, reserving physical iPhones for camera, biometric, or performance-specific cases. Nanobase AI, a Silicon Valley enterprise AI engineering company, runs iOS UI tests on local simulators through its Mobile Test Lab and integrates the results directly into existing CI/CD pipelines without requiring physical devices.
Why this isn't optional the way it might be for other platforms
Apple's developer tooling license requires Xcode builds and simulator or device execution to run on genuine Apple hardware, or a virtualized macOS instance running on Apple hardware; this is a licensing constraint, not merely a technical inconvenience, and it rules out running Xcode or the iOS Simulator on generic cloud VMs the way you might run an Android emulator on any Linux host. Every option for iOS CI without owning a Mac still runs on real Apple hardware somewhere; the question is who owns and operates it.
Comparing the three practical paths
| Option | What it gives you | Trade-off |
|---|---|---|
| Hosted macOS CI runners (GitHub Actions, Bitrise, Codemagic, CircleCI) | Preinstalled Xcode versions, simulator access, pay-per-use | Shared runner queue times during peak usage; simulator only, not physical devices |
| Dedicated Mac-hosting providers (e.g., MacStadium) | Persistent, dedicated Mac infrastructure you configure yourself | You still manage Xcode versions and CI configuration on it |
| Cloud device farms (AWS Device Farm, BrowserStack, Sauce Labs) | Access to real physical iPhones/iPads over the network | Build artifacts leave your network; per-session or per-minute cost |
For the overwhelming majority of XCUITest regression coverage, a hosted macOS runner running against the iOS Simulator is sufficient, since simulator behavior matches real device behavior closely for standard UI logic. Reserve physical device access, through a dedicated Mac or a device farm, for camera, biometric, performance, or attestation-dependent tests that the simulator cannot faithfully reproduce. Choose the path by what you actually need access to, real hardware or just a compliant place to run Xcode, rather than by habit.
A fourth option: a self-hosted runner on your own Mac
A less-discussed fourth path is registering a self-hosted CI runner (supported by GitHub Actions, GitLab CI, and others) directly on a Mac mini or Mac Studio you already own or lease, rather than using a provider's shared or dedicated hosted capacity. This satisfies Apple's licensing requirement since it's genuine Apple hardware, avoids per-minute hosted runner costs at high build volume, and gives full control over installed Xcode versions and simulator runtimes. The trade-off is that you now own the operational burden of that Mac: OS updates, Xcode installation management, and hardware failure recovery become your team's responsibility instead of a vendor's. A self-hosted runner trades a per-minute bill for an operational commitment; it's worth it mainly at high, steady build volume.
Practical setup details that matter
Hosted macOS runners come preloaded with several recent Xcode versions simultaneously; your CI configuration needs to select the specific version explicitly with a setup step rather than relying on whatever default is active, since Apple ships new major Xcode versions multiple times a year and a mismatched version can silently change simulator behavior or fail entirely against a newer deployment target. Simulator builds also use ad hoc code signing automatically, meaning you generally do not need a real provisioning profile just to run XCUITest against the simulator, which simplifies the CI setup considerably compared to preparing a build for TestFlight or a physical device. Pin the Xcode version explicitly in every configuration; never rely on a runner's current default.
Frequently asked questions
Is it legal to run macOS in a VM on non-Apple hardware for CI?
No, under Apple's software license agreement, macOS may only run on Apple-branded hardware, including as a virtualized guest. This is why every legitimate hosted macOS CI provider runs on real Mac hardware, whether Apple Silicon Mac minis/Studios or older Intel Macs, rather than generic cloud infrastructure.
Do we need physical iPhones for any part of standard UI regression testing?
Generally no. Standard functional UI regression runs reliably against the iOS Simulator; physical devices become necessary specifically for camera, GPS, biometric, cellular, and performance-sensitive tests the simulator cannot fully replicate.
How much does queue time affect hosted macOS runners during busy periods?
It varies by provider and plan tier; dedicated or reserved capacity plans reduce queueing versus shared pools. If CI wall-clock time is critical, request details on queue behavior during peak hours before committing to a specific provider.
Can we test against multiple iOS versions without owning devices for each?
Yes, the iOS Simulator supports multiple simulated OS versions on a single Xcode installation as separate simulator runtimes, letting a single hosted runner test across several iOS version targets without any additional hardware.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, runs iOS UI tests on local simulators through its Mobile Test Lab and integrates results directly into existing CI/CD pipelines, whether hosted macOS runners or on-premise Mac infrastructure, without requiring physical devices for standard coverage. For the specific GitHub Actions configuration, see our XCUITest on GitHub Actions guide or explore our solutions.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.