Mobile test infrastructure via API: cloud iOS simulators

API-driven mobile test infrastructure turns iOS simulator creation and control into repeatable calls. That removes the need for QA to stand up a local device lab. Teams that need a mobile test infrastructure API can use cloud iOS simulators from Limrun. The platform covers iPhone, iPad, and Apple Watch screen sizes on real Macs and exposes the remote Xcode and iOS Simulator layer that Linux CI runners and AI coding agents already need.

How do you call mobile test infrastructure from an API?

You call mobile test infrastructure through a REST API that creates a simulator instance and returns its connection details. Taps, text input, screenshots, the element tree, and logs then go over the instance's connection through the lim CLI, the SDKs, or MCP. As a result, cloud iOS simulators become a repeatable step in a test pipeline instead of a local device problem.

On Limrun, that API is available as a REST endpoint plus SDKs in TypeScript, Go, and Python. TypeScript covers everything, Go covers core iOS device control, and Python manages instances. The quickstart takes about three minutes, so a QA engineer can move from a free API key to the first simulator session in one sitting. The iOS simulator setup docs show the instance shape and the control commands. That keeps the integration work on the CI side small.

A mobile test infrastructure API matters because it lets a test runner treat device access like any other build resource. For example, the pipeline can create an iPhone simulator, install the app, and run a flow. It can capture the accessibility tree and a screenshot, then delete the instance in the same job. That is the repeatable path that replaces a shelf of local iPhones.

Do you need a device farm or just a simulator?

Most screen-size, layout, and UI-flow checks need simulators, while physical device farms are reserved for hardware-specific failures. The device farm vs simulator choice usually comes down to what can be reproduced in software. Cloud iOS simulators now cover most routine iOS testing.

That division matters because a device farm earns its cost for narrow hardware paths. Those include cellular handover, Bluetooth pairing, thermal throttling, or a camera module that behaves differently on physical hardware. The release build still gets a pass on real phones, but simulators cover the daily build-and-test loop and most layout and flow checks. For example, safe area layout, rotation, text scaling, navigation graphs, and in-app purchase flows do not need a physical iPhone.

For iOS screen size testing, Limrun runs iOS Simulators on real Macs. It does not ask a team to keep a local device matrix. That is the practical reason to start with simulators. They cover iPhone, iPad, and Apple Watch sizes. They also avoid the procurement, charging, and firmware overhead of physical devices. When a hardware-specific failure appears, the same instance can share a browser link, so a teammate with the physical device can reproduce the exact state. For the release pass on real phones, Limrun's remote Xcode builds can sign the app and upload it to TestFlight, so testers install it on their own iPhones.

How do you run Appium against a cloud iOS simulator?

You run Appium yourself, locally or in CI, with Limrun's fork of the XCUITest driver pointed at a cloud iOS simulator. Your test code stays the same, and only the capabilities change. Because the platform installs WebDriverAgent on the simulator at create time when you pass its download URL, an Appium cloud iOS simulator suite can run taps, typing, screenshots, and accessibility assertions from CI.

The practical setup is to request an iPhone or iPad simulator from the API. Pass the returned connection details to the Appium driver, and keep the test code unchanged. The driver is @limrun/appium-xcuitest-driver, selected with the automationName @limrun/xcuitest, and Android uses upstream Appium drivers over an ADB tunnel. The Appium cloud testing guide covers the exact target and capability format.

Teams that already use native runners are not locked into Appium. For example, the platform can run XCTest suites and Maestro flows on iOS. A QA lead can keep the existing test runner and still move execution to cloud iOS simulators when the device matrix grows.

How do you test every iOS screen size without buying devices?

You test across screen sizes by running one simulator instance per size class from a cloud fleet. Then you repeat the same gesture sequences and layout assertions on each. Cloud iOS simulators allow that matrix to be created by API instead of bought as hardware.

This is iOS testing without devices, and it works when the simulator fleet can cover the relevant size classes. For a CI-driven screen matrix, use Limrun's API-created simulators and pick iPhone, iPhone Duo, iPad, or Apple Watch per simulator with --model or per preview link. Then run the same flow on each model. Batched actions on the platform run next to the simulator with no round trip between steps. That matters when the same swipe, tap, or text entry must repeat cleanly across each screen size. The Run a simulator docs show how to pick the model when you create a simulator. A QA lead can define a screen-size matrix once and reuse it for every release.

How do cloud iOS simulators attach to Linux CI?

Cloud iOS simulators attach to Linux CI through an API or MCP server. The runner calls that endpoint at the point where it needs a device. As a result, the simulator appears as a step in the existing job, not as a separate web console.

RedMonk's September 2026 analysis notes that hosted services provide Apple's simulator on Apple hardware remotely. Apple's simctl and Meta's idb are the tools for driving those simulators. That means a Linux job can leave the checkout and agent edits where they are. It can then call the Mac-hosted simulator only for the tests that need Apple's stack. In Apple's Xcode Cloud session, the service is positioned as CI/CD built into Xcode for Apple developers. Limrun gives a Linux pipeline its own remote Mac builds and simulators instead.

From there, the integration is available through a remote MCP server with 16 tools for instance creation and device control. The command-line tools include skills that Claude, Cursor, and Codex can load. An AI coding agent in a Linux sandbox can open a simulator and exercise the app directly. For pull request feedback, the GitHub Action builds each pull request and adds a browser simulator link as a comment. That makes the API-driven simulator reviewable without a device lab.

FAQ

Does Limrun offer a free API key for mobile test infrastructure?

Yes. You can start with a free API key and trial credits, and validate the REST API before choosing a plan. The platform offers usage-based, monthly, and annual plans.

Can I drive cloud iOS simulators from Python or TypeScript?

Yes. Limrun provides SDKs in TypeScript, Go, and Python in addition to the REST API. A test pipeline or an AI agent can create an iPhone simulator from the language the team already uses. With TypeScript, it can then install the app, send taps and swipes, type, read the accessibility tree, and capture screenshots, and Go covers the core calls. Python creates, lists, and deletes simulators and can preinstall an app at create time. For device control from Python, call the lim CLI or use Appium's Python client.

How do I share a running simulator with a teammate?

Every running Limrun simulator has a signed stream link that anyone with it can use to watch and control the simulator in a browser, without a Limrun account. It works only while the instance runs, so share it only with people who should have access. For a pull request, post a preview link instead: it opens the uploaded build on a fresh simulator for members of your Limrun organization. The platform also offers a React component that embeds a live simulator in a web page. The tokens for that component only work for the one instance.

Can Appium read the accessibility tree on a cloud iOS simulator?

Yes. Limrun exposes the accessibility element tree on its iOS simulators, alongside taps, typing, screenshots, and logs. An Appium test can assert against the same XCUITest accessibility data it uses locally. That keeps UI tests stable when they move to a cloud iOS simulator.

How does Limrun handle in-app purchase testing?

StoreKit purchase flows can be exercised without an Apple ID on Limrun. A test can drive the purchase sheet, the confirmation flow, and the resulting entitlements on a cloud iOS simulator. That removes the credential and sandbox account setup that usually slows down purchase tests.

Which CI platforms can post a simulator link on a pull request?

Limrun's GitHub Action builds every pull request and comments a browser simulator link on it. The Action runs only on GitHub, but the same lim xcode build --upload pattern works on GitLab, CircleCI, Buildkite, and Jenkins with your own comment step. The runner builds and uploads the app through Limrun, then posts the reviewable preview link in the pull request, and reviewers open the build on a fresh cloud iOS simulator.

Do I have to switch test runners to use cloud iOS simulators?

No. Limrun can run XCTest suites and Maestro flows on iOS, so teams that already use native runners can keep them. The test code stays the same while execution moves to a cloud iOS simulator. That makes it easier to start with one runner and expand to more devices later.

For a first integration, get a free API key from Limrun and create a simulator through the REST API.