What is RobotActions Device Farm?

RobotActions Device Farm is a cloud testing platform that gives you dedicated real Android and iOS devices, and real browsers, reserved for your account. Reach them from your browser, drive them with Selenium, Appium, Playwright or WebdriverIO, or let an AI agent drive them over MCP.

How many devices can I test on simultaneously?

Your concurrency is simply the number of devices on your plan: buy 11 devices and you can run 11 sessions at once. Sessions and test minutes on those devices are unlimited. Because the devices are dedicated to your account rather than drawn from a shared pool, a run never queues behind another customer.

Do you provide real devices or emulators?

Real physical devices, always — no emulators and no simulators. They behave differently from the hardware your users actually hold, which is the whole reason to use a device farm.

What integrations do you support?

RobotActions works with Jenkins, GitHub Actions, GitLab CI/CD and other CI providers, and with Selenium, Appium, Playwright and WebdriverIO. Over MCP, an AI agent can also reach Jira, TestRail and Azure DevOps — reading stories and acceptance criteria, updating test cases and filing defects. Our API allows custom integrations with your existing workflow.

Can I record my test sessions?

Yes, all test sessions can be recorded with our video playback feature. This allows you to review test executions, analyze failures, and share recordings with your team for collaborative debugging.

Can I test geo-restricted applications?

Yes for location itself — you can emulate the device GPS position and mock API responses, so location-based features in your own app are fully testable on a real device. One limit worth stating plainly: we do not control the IP address your traffic leaves from, so a restriction a third party enforces by source IP is out of scope today.

Automating React Native on iOS When the Page Source Is Unreadable

Short answer: the nested wrappers you see in Appium Inspector are a tooling problem, not a React Native problem. The testID you set in JSX does reach the native layer on both platforms — it just gets buried in a hierarchy most inspectors render unusably deep. Fix what you inspect with, add testID consistently, and one locator will drive both iOS and Android.

Why the iOS tree looks like that

React Native composes its UI from host views. A single <Pressable> with a <Text> inside can land as several nested XCUIElementTypeOther nodes, none of which is obviously "the button". Dump that tree and you get forty levels of scaffolding, so people fall back to XPath expressions that describe position rather than identity:

java

// Brittle: describes where the element sits today
driver.findElement(AppiumBy.xpath(
    "//XCUIElementTypeOther[3]/XCUIElementTypeOther[2]/XCUIElementTypeButton[1]"));

That locator survives exactly until someone wraps the view in one more <View> for layout.

Android usually hurts less, because the view hierarchy is flatter and resource-id gives you something stable to grab. The asymmetry is why teams end up with two locator strategies for one codebase — and twice the maintenance.

The fix starts in the app, not the test

Set testID on every element a test needs to touch. React Native maps it to the accessibility identifier on iOS and the content description / resource-id path on Android, so the same string works on both:

jsx

<Pressable testID="checkout-button" onPress={checkout}>
  <Text>Check out</Text>
</Pressable>

java

// One locator, both platforms
driver.findElement(AppiumBy.accessibilityId("checkout-button")).click();

Two rules make this hold up over time:

Name the role, not the design. checkout-button, never green-cta-v2. A design-derived name is guaranteed to be wrong after the next redesign.
Put it on the pressable, not the label. testID on a <Text> inside a <Pressable> finds the text node, and taps on it may not register as taps on the button.

If you inherited an app with no testIDs, add them to the twenty elements your smoke suite touches before you do anything else. That is usually a single afternoon and it removes most of the XPath.

But the ids still have to be visible

Here is where teams get stuck. You add testID correctly, and the iOS inspector still shows a wall of XCUIElementTypeOther. The identifier is there; the tool is not surfacing it in a form you can act on. So people conclude React Native on iOS is simply hard to automate, and go back to XPath.

It is worth checking that assumption against a different inspector before rewriting your test strategy around it. In the RobotActions inspector a React Native app resolves the way any native app does — named, addressable elements rather than wrapper soup — which is the difference between accessibilityId("checkout-button") being available to you and not.

That is the whole claim, and it takes about ten minutes on the free tier to confirm or dismiss on your own build.

Verify on real hardware

Simulators hide the two things most likely to break a React Native screen:

Gesture timing. Synthesised swipes send two coordinates and skip everything in between. Drag handles, carousels, sliders and pull-to-refresh only behave correctly under a continuous stream of pointer events.
Permission and system dialogs. OEM Android skins and iOS permission prompts appear at different moments on real devices than in a simulator, and a test that never sees them passes for the wrong reason.

Both are cheap to check once the app is installed on a real phone you can drive from a browser.

A reasonable order of work

Add testID to the elements your smoke suite touches. Role-based names.
Inspect on a real iOS device and confirm the ids are actually addressable.
Replace XPath with accessibilityId wherever step 2 made it possible.
Run the same suite on Android — most of those locators should now work unchanged.
Keep XPath only for the handful of cases nothing else reaches, and comment why.

The goal is not zero XPath. It is that a redesign changes the layout without changing which elements your tests can find.