Migrate from Appium to TesterArmyYour Appium suite,
minus the mobile-specific overhead
TesterArmy runs your app on cloud simulators and emulators and tests it with an AI agent that sees the screen. Paste one prompt into Claude Code, Cursor, or Codex and it reads your Appium suite, converts it, and verifies every test.
Takes less than 2 minutes. No credit card required.
Most of your suite exists to point
a script at the right element
Appium suites carry the same weight as Selenium, plus mobile-specific overhead. Most of that machinery exists for one job: pointing a script at the right element on the screen.
Capabilities and drivers before a single test runs
Desired capabilities, an Appium server, and driver setup for iOS and Android all have to be configured and kept working before any test tells you anything. None of it describes your app - it only connects a script to a device.
Three locator strategies to keep in sync
Accessibility IDs, XPath, and UiSelector each break in their own way when a screen changes. The locators live in your screen object classes, so every UI change ripples into test code that has nothing to do with what the test checks.
Waits patched onto every screen transition
WebDriverWait and implicit waits accumulate around every navigation and animation. The timeouts are arbitrary, and a slow simulator boot or a loading spinner can still turn a healthy build red.
A device farm to manage on top of it all
Emulator management and device farm access are their own operational workstream, separate from writing tests. You maintain the fleet so the suite has somewhere to run, and CI inherits all of that complexity.
What your suite reads like
after the conversion
The user intent in your test methods - often already spelled out in screen object method names like signInWithValidUser() - becomes act and assert steps, and the capabilities, driver setup, and locators are dropped.
@Test
public void updateNotificationSettings() throws MalformedURLException {
UiAutomator2Options options = new UiAutomator2Options()
.setApp("/builds/app-release.apk")
.setPlatformName("Android");
driver = new AndroidDriver(new URL("http://127.0.0.1:4723"), options);
loginScreen.signInWithValidUser();
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));
wait.until(ExpectedConditions.visibilityOfElementLocated(
AppiumBy.accessibilityId("profile-tab")));
driver.findElement(AppiumBy.accessibilityId("profile-tab")).click();
driver.findElement(AppiumBy.androidUIAutomator(
"new UiSelector().text(\"Settings\")")).click();
driver.findElement(AppiumBy.accessibilityId("notifications-toggle")).click();
assertTrue(driver.findElement(
AppiumBy.accessibilityId("notifications-toggle")).isSelected());
}The capabilities, the driver setup, the WebDriverWait, and every accessibility ID and UiSelector are dropped in conversion. The agent sees the screen and finds elements visually, so a reworked settings screen does not break anything.
The whole migration
is one prompt
Paste this into your coding agent in the repository that contains your Appium tests. It works for Java, Python, C#, Ruby, and JavaScript bindings: the agent creates a mobile project, uploads your app build, converts each test method, and verifies every test on cloud devices.
Migrate this repository's Appium mobile test suite to TesterArmy using the
TesterArmy CLI (`ta`). Verify auth first with `ta status --json`, and use
`ta --help` plus subcommand help to discover commands. Prefer --json output.
1. Discover: find all Appium test classes/modules, page object/screen
classes, and the desired capabilities (platformName, app path, etc.).
Note whether the suite targets iOS, Android, or both.
2. Create a TesterArmy mobile project (skip if one exists in
`ta projects list`):
echo '{"name":"<app name>","url":"","projectType":"mobile"}' | ta projects create --json
3. Build and upload the app artifact. For iOS use an iOS Simulator `.app`
build; for Android use a release `.apk` or `.apks`. Do not use .ipa,
.aab, or .xapk. Upload it:
ta upload-app --app-path <path-to-build> --project <projectId> --json
Report the uploaded app ID.
4. Save durable context as project memories (category site_structure,
importance high): key screens, the login flow, and domain knowledge
encoded in screen objects (e.g. "Settings is reachable from the profile
tab after signing in").
echo '{"category":"site_structure","title":"...","content":"...","importance":"high"}' | ta memories create --project <projectId> --json
5. Convert each Appium test method into a TesterArmy mobile test:
- Express the USER INTENT in plain English. Use screen object method
names as a guide. Drop all locators (accessibility id, XPath,
UiSelector), capabilities, waits, and retry logic - the TesterArmy
agent finds elements visually and waits on its own.
- tap/click/sendKeys/swipe -> steps with type "act"
- assertions on element/screen state -> steps with type "assert"
- login helpers and auth setup -> one step with type "login"
- Keep tests focused: 3-10 steps. Split long scenario methods into
separate tests.
- Skip pure API tests and unit tests of utilities.
Create each test with platform "mobile":
echo '{"title":"<test name>","description":"Migrated from <class/file>","platform":"mobile","steps":[{"title":"Tap the profile icon","type":"act"},{"title":"The settings screen is visible","type":"assert"}]}' | ta tests create --project <projectId> --json
Step types: act, assert, login, screenshot.
6. Never hardcode passwords in test steps. If the suite reads credentials
from config files or env vars, tell me which credentials to add and I
will run:
echo '{"kind":"login","label":"...","username":"...","password":"..."}' | ta projects credentials-create <projectId> --json
7. Tell me each created test ID, then run each one to verify with
`ta tests run <testId> --wait --json`. Runs target the most recent
uploaded app automatically.
8. Report a summary table: Appium test method -> TesterArmy test ID, the
uploaded app ID, plus anything you intentionally skipped and why.Everything you built
has a place to land
Nothing in your suite gets orphaned. Every Appium concept maps to a TesterArmy equivalent - and the capabilities, locators, and waits map to nothing at all, because none of them are needed.
Appium and TesterArmy,
row by row
Appium is the Selenium of mobile - free, open source, and able to drive real physical devices through drivers like UiAutomator2 and XCUITest. This table is about what owning the suite and its infrastructure costs, and where each side wins.
- Who maintains the testsTesterArmyThe agent finds elements visually and waits on its own, so nobody owns locators, capabilities, or a screen object layer.AdvantageAppiumYour team owns the test methods, the locator strategies, the capabilities, the Appium server, and the device infrastructure they all depend on.
- What breaks on a UI changeTesterArmyUsually nothing - a reworked settings screen or a renamed accessibility ID is invisible to a vision agent.AdvantageAppiumEvery accessibility ID, XPath, and UiSelector that touched the changed screen, and each strategy breaks in its own way.
- Writing a new testTesterArmy3-10 plain-English steps that anyone on the team can write and review, with no capabilities or screen object class behind them.AppiumA test method plus locators, waits, and usually a screen object class, written by someone who knows the framework and the driver setup.
- Flaky failuresTesterArmyThe agent waits like a human through simulator boots and screen transitions, and every failure comes with a recording and a step trace.AppiumHandled with WebDriverWait, implicit waits, and retries patched around slow simulator boots and screen transitions.
- Run verdictsTesterArmyThree verdicts - passed, failed, or blocked. Environment and setup stops land in blocked with the reason attached, so the failure count only holds real product failures.AdvantageAppiumTwo verdicts. A simulator that never booted, a bad capability, and a product bug all fail the same way in the runner.
- License and infrastructureTesterArmyA paid service - the agent, the cloud simulators and emulators, and the run infrastructure are included.AppiumFree and open source, with clients in Java, Python, C#, Ruby, and JavaScript; you run the server, drivers, and device infrastructure yourself.Advantage
- Real physical devicesTesterArmyTests run on managed cloud simulators and emulators; real physical devices are not part of the service today.AppiumFirst class - UiAutomator2 and XCUITest drive real iPhones and Android hardware through your own device farm or a third-party device cloud.Advantage
- Pull request workflowTesterArmyRuns wire into CI through GitHub Actions or ta ci, with no Appium server or device farm behind the job.AppiumYou wire the suite, the server, and device access into CI yourself and keep that pipeline healthy.
- Web coverageTesterArmyThe same plain-English tests also run against your web app, in one service and one test format.AdvantageAppiumAppium is built for mobile automation - web suites typically live in a separate Selenium or WebDriver stack.
- Entry priceTesterArmyFree trial without a credit card; Hobby is $99 per month with 250 test runs included.Appium$0 forever - the cost is the server, the drivers, the device access, and the engineering time in the rows above.
Facts checked August 2026. Spotted something out of date? Tell us and we will fix it.
From test methods to green runs in four steps
Install the CLI, hand the prompt to your coding agent, and review what comes back. Your Appium suite and device farm keep running until every migrated test is green on cloud devices.
Create a mobile project and upload your build
Install the TesterArmy CLI and authenticate, then paste the migration prompt into Claude Code, Cursor, or Codex. The agent reads your test classes and capabilities, creates a mobile project, and uploads your iOS Simulator .app or Android .apk/.apks build.
The agent converts every test method
Each test becomes 3-10 plain-English steps: taps, sendKeys, and swipes turn into act steps, assertions into assert steps, and login helpers into a single login step backed by encrypted credentials. Screen object method names guide the step text.
Every migrated test runs on cloud devices
The agent verifies each test with ta tests run --wait on TesterArmy's managed cloud simulators and emulators - runs target your most recent uploaded build automatically - and reports results plus anything it intentionally skipped and why.
Wire the suite into CI
Replace your Appium job and device farm with GitHub Actions or Expo EAS. Decommission the Appium server, drivers, and screen object layer once the TesterArmy runs are green.
What comes with you,
what stays behind
The page object pattern helps here: method names like loginScreen.signInWithValidUser() already describe user intent, which is exactly what a TesterArmy step is. The guide is just as explicit about what stays behind.
When Appium is still the right call
- Your tests depend on real physical hardware - camera capture, Face ID or Touch ID, or device-specific behavior that simulators and emulators cannot reproduce.
- Your suite must run against devices inside your own network or an air-gapped CI environment - TesterArmy runs execute on managed cloud devices.
- Your builds only exist as device artifacts (.ipa, .aab, .xapk) and you cannot produce an iOS Simulator .app or an Android .apk/.apks.
- You have a working device farm, a team that genuinely likes owning the Appium server, drivers, and screen object layer, and an app UI that rarely changes.
Nothing forces the choice on day one. Migrated tests run on cloud devices alongside your Appium suite and device farm, and the guide's own advice is to decommission the Appium server, drivers, and screen object layer only once the TesterArmy runs are green.
Frequently Asked Questions
Pointing a script at an element
should not be its own workstream
Your Appium suite encodes real knowledge about how your app is supposed to work, much of it already written down in screen object method names. The migration keeps that knowledge and retires the machinery around it - the capabilities, the drivers, the server, the locator strategies, and the device farm they all exist to serve.