Real Device Access API Comes to Public Devices: Break the Framework Constraints

What is the Real Device Access API?

Real Device Access API is a framework-agnostic way to reserve a real iOS or Android device and control it directly over HTTP and WebSocket. The API now runs on Sauce Labs public devices, the shared pool every Real Device Cloud customer already has access to, with live video, device logs, HAR network capture, test artifacts, and a hosted Appium server included. Public sessions last up to one hour, and a few low-level controls remain private-device only. 

The wall every mobile team eventually hits

AI now writes code and entire test suites faster than most pipelines can execute them. In Stack Overflow's 2025 developer survey, 84% of respondents said they already use or plan to use AI tools as standard practice, yet 46% don't fully trust what ships. The bottleneck evolved beyond how fast you can build because verification now sets the pace of a release. 

Autonomous agents make the verification gap concrete. Picture an AI agent running a shopping-app test: It taps Buy, and a native "Rate this app" dialog slides over the button. A standard Appium script can stall right there because that dialog was never part of the app's own object tree. The framework has no view past the app's own screen, so nothing in the script can dismiss the dialog. Rerun it and the result can swing on the exact timing of the dialog, which is how flaky tests start.

The Real Device Access API targets exactly this situation. It is a programmable mobile cloud that hands AI-driven workflows deep, device-level control instead of routing them through a framework that only understands your app's code. Direct device access lets an agent dismiss the dialog and keep testing. Teams running agents this way see completion rates improve by roughly 30%-50%, compared to scripts that simply stop the moment something unscripted happens.

The API also shipped on an MCP-ready architecture from day one, so agents can reach the device directly instead of squinting at it through an automation layer.

How a programmable mobile cloud solves this challenge 

Earlier this year, we introduced the Real Device Access API, a framework-agnostic way to reserve a real device and drive it directly, instead of routing every interaction through Appium, XCTest, or Espresso. Teams got persistent sessions and direct device commands, along with live log and video streaming. Getting that kind of control used to mean building an internal device lab.

The strategic advantage this brought to teams:

• Zero framework lock-in: Decouple device control from rigid automation frameworks for infrastructure flexibility.
• Unmatched control at scale: Get local-device precision at cloud-scale security. 
• Maximized efficiency: Reclaim your innovation time by eliminating the session overhead and maintenance burden of traditional testing.
• Deep observability: Stream real-time logs and screen capture alongside diagnostic data to understand exactly why a failure occurred.
• Future-proof AI-ready foundation: Scale AI-driven testing and integrate emerging tools with an architecture that allows autonomous agents to interact with devices as native tools.

What's new: the Access API now runs on public devices

Until now, the Real Device Access API was limited to private devices. It is now available on Sauce Labs' public devices. The programmable session model is the same, extended to the shared pool of iOS and Android devices every Real Device Cloud customer already has access to. Real Device Cloud sits in the “test” stage of the Sauce Labs AURA platform and gives mobile testing teams on-demand access to 10,000+ real iOS and Android devices, with the device breadth and reliability that matter at enterprise scale. 

Public sessions include: 

• App installation, launch, and uninstall
• File push and pull
• Live video streaming and device logs
• HAR network capture and test artifacts
• Sauce Labs-hosted Appium

All of it is reachable through the identical /sessions endpoint and the same AlternativeIO and Companion sockets that private-device sessions already use. 

Same API, two device pools: what differs

The Access API's architecture doesn't change based on device type: create and manage sessions over HTTP, stream live video and logs over WebSocket, and call device-operation endpoints to install apps, run shell commands, or start a hosted Appium server, all from the same session, on public or private devices alike.

What changes is how much of the device you're handed, since a public device is shared tenancy and a private device is dedicated to you:

The observability layer (live video, live logs, HAR capture, and test artifacts) is identical on both pools. 

Where public devices win

• No new vendor or device fleet to procure. If you already license Sauce Labs public devices, the Access API turns on as an entitlement on top of what you have. 
• Access to an extensive device/OS catalogue to choose from 
• The full observability stack, day one. Live video, live device logs, HAR network capture, test artifacts, and hosted Appium are all included on public devices.
• Built for bursty, elastic workloads. A shared pool fits a five-minute IDE debug loop, an AI agent that needs a device on demand, or a platform partner embedding elastic device access into their own product.

Where private devices win

• 24-hour sessions instead of one hour. A 24-hour window supports a real soak test or overnight shift simulation, while one hour suits a quick check.
• Any adb shell command on Android. Public sessions run a published set of tenant-safe commands covering app, file, settings and diagnostics; private sessions run anything.
• Device reboot and custom WebDriverAgent. Both are private-only, which matters for recovery workflows and for teams running a modified iOS driver.
• Low-level device access and unthrottled file transfer. Public file push and pull is throttled to protect the shared pool, but private isn't, which matters for larger app binaries or bulk log pulls.
• Dedicated hardware, no shared-tenancy limits. No allowlisting, no throttling, no 1-hour clock. For custom-framework testing, destructive security testing, or any workload that needs the device to itself, private devices are the pool built for the job.

Most engineering orgs end up using both: public for the fast, elastic, everyday work and private for the deep, long-running work. Both pools share one integration, so nobody has to pick a side up front.

Why programmable control on shared devices stands apart

Programmable, framework-agnostic control on shared real-device infrastructure isn't something the major clouds offer today. The common pattern elsewhere is a clean-slate teardown after every single test, with no path to a persistent session at any price. Public device support closes that gap directly.

Public device support also opens the programmable model to workloads that never suited a dedicated device fleet in the first place:

• Developers who want to pull a real device into an IDE for a five-minute install-and-debug loop, not reserve a slot for the day.
• AI and autonomous-agent workloads that need low-latency video and coordinate-based touch on a bursty, on-demand basis. A shared pool suits that pattern better than a dedicated one.
• Platform partners building their own product on top of Sauce Labs infrastructure that value elastic device access over exclusivity.

Connect it to your IDE and AI agents

Because the Access API is MCP-ready, AI agents can discover devices and manage test sessions in natural language through Sauce Labs' hosted MCP server. IDE plugins for VS Code and Cursor bring the same device access into the editor. 

Frequently asked questions

Does the Real Device Access API work on public devices?

Yes, the Real Device Access API now runs on the shared pool of iOS and Android devices to which every Real Device Cloud customer already has access. 

Do I need Appium to use the Real Device Access API?

No. The API is framework-agnostic and drives devices over HTTP and WebSocket. Sauce Labs-hosted Appium is available inside the same session for teams that want it.

How long can a public device session last?

Up to one hour. Private device sessions can last up to 24 hours.

What can't I do on public devices?

Device reboot, custom WebDriverAgent (iOS), and low-level device access are private-device only. On public devices, adb shell commands are limited to an allowlist.

Should I use public or private devices?

Public devices suit fast, elastic work such as IDE debug loops and on-demand agent runs. Private devices suit long-running real device testing sessions and destructive security testing. Most teams use both through the same integration.

Getting started

Start with the Real Device Access API guide for the full session lifecycle, or go straight to the integration guide for authentication, device filtering, and session management end to end. New to Sauce Labs? Request a demo to see the Access API running on real devices, or start a free trial to run real device testing on your own app.