Autify Mobile Testing: iOS and Android Test Automation Without Code
Mobile app testing has always been harder than web testing. You are dealing with two major platforms (iOS and Android), dozens of OS versions, hundreds of device models, and a recorder workflow that must work with native UI components rather than HTML elements. Autify Mobile was built to bring the same no-code recording experience from Autify Web into the native mobile layer.
This post covers how Autify Mobile works end-to-end: the recording setup, how element detection differs from web, how tests execute on the cloud device farm, and what you need to get a first test running.
How Autify Mobile Differs from Web
Before diving into setup, it helps to understand the structural differences between Autify Web and Autify Mobile.
Autify Web uses a Chrome extension that intercepts browser events. The browser gives you a consistent API: the DOM, CSS, and JavaScript. Element positions are deterministic given a viewport size.
Autify Mobile has none of these luxuries. iOS and Android expose different accessibility APIs, native components have different hierarchies across OS versions, and there is no universal "DOM" equivalent. Autify Mobile uses a desktop companion application connected to a physical device via USB to capture the native accessibility tree during recording.
The AI element detection model works similarly — capturing visual appearance, accessibility labels, and element hierarchy — but the signals it uses are platform-specific:
| Signal | iOS | Android |
|---|---|---|
| Visual screenshot | Yes | Yes |
| Accessibility label | accessibilityLabel |
contentDescription |
| Element hierarchy | UIKit view tree | Android View hierarchy |
| Resource ID | N/A | android:id |
| Class name | UIKit class | Android widget class |
This multi-signal model is why Autify Mobile can handle UI changes that would break a pure accessibility-ID-based tool like a raw Appium script.
Setup Requirements
Desktop Machine Requirements
Autify Mobile's recorder runs as a desktop application. Current supported host systems:
- macOS 12 (Monterey) or later — required for iOS recording
- Windows 10 or later — for Android recording only
For iOS recording you must use a Mac. This is an Apple platform constraint, not an Autify limitation — iOS device provisioning and communication requires macOS toolchain components.
Device Requirements
iOS:
- iPhone or iPad running iOS 14.0 or later
- Developer mode enabled on the device (Settings → Privacy & Security → Developer Mode)
- Device trusted on the Mac (accept the "Trust This Computer" prompt)
- Xcode command-line tools installed (
xcode-select --install)
Android:
- Physical Android device running Android 9.0 or later
- USB debugging enabled (Settings → Developer Options → USB debugging)
- ADB installed and device recognized (
adb devicesshows the device)
Emulators and simulators are not supported for recording. You must use real physical devices. Cloud execution uses Autify's device farm, but the recording step requires a physical device connected to your machine.
Installing the Desktop Recorder
Download the Autify Mobile recorder app from your Autify dashboard under the Mobile section. The installer is a standard .dmg (macOS) or .exe (Windows). After installation, launch the app and log in with your Autify credentials.
Recording a Mobile Test
Connecting the Device
- Connect your iOS or Android device via USB
- Open the Autify Mobile recorder application
- The recorder detects connected devices — select your target device
- For iOS: the recorder may prompt to install a helper app on the device; approve this
- A live mirror of the device screen appears in the recorder window
You interact with your physical device during recording, not with the mirror on screen. The mirror is a real-time view, not a control surface. Every tap, swipe, and text input you perform on the actual device is captured.
Recording Interactions
Click Start Recording in the recorder application, then interact with your app on the physical device:
| Interaction | What Gets Captured |
|---|---|
| Tap | Element identifier + coordinates |
| Long press | Element + press duration |
| Swipe | Direction, start element, distance |
| Text input | Field identifier + input text |
| Scroll | Direction + scroll distance |
| Device back button | System back navigation |
| Keyboard dismissal | Tap outside keyboard area |
Click Stop Recording when done. The recorder uploads the session to Autify's cloud and processes the accessibility tree captures into a step list.
What the Step List Looks Like
After processing, you see the same plain-English step view as in Autify Web:
Step 1: Launch app
Step 2: Tap "Email" text field
Step 3: Type "user@example.com"
Step 4: Tap "Password" text field
Step 5: Type "secretpassword"
Step 6: Tap "Sign In" button
Step 7: [WAIT] Page load
Step 8: [ASSERTION] Text contains — "Dashboard" — element: NavigationTitleEach step links to a screenshot captured at that moment on the device.
Adding Assertions
Assertions for mobile tests work similarly to web assertions, but the element types and assertion options reflect native UI:
| Assertion Type | Mobile Use Case |
|---|---|
| Element exists | Verify a button or label appeared after navigation |
| Element not exists | Confirm a loading spinner dismissed |
| Element is visible | Ensure an element is on-screen (not scrolled off) |
| Text equals | Verify a label or text view shows exact content |
| Text contains | Confirm a message includes expected text |
| Text matches regex | Validate dynamically generated content |
| Element is enabled | Confirm a button is interactive (not grayed out) |
| Element is disabled | Verify a button is correctly locked |
To insert an assertion, click Insert Step → Assertion, then select the element from the screenshot captured at that step and configure the assertion type.
Executing Tests on the Cloud Device Farm
Recording uses your physical device. Execution uses Autify's cloud device farm — a pool of real physical devices hosted in Autify's infrastructure.
Available Devices
Autify does not publish its full device inventory publicly, but the farm covers:
- Current and two prior iOS major versions (e.g., iOS 17, 16, 15)
- Current and two prior Android major versions (e.g., Android 14, 13, 12)
- A range of device models including iPhone (multiple screen sizes) and popular Android devices from Samsung, Google, and others
You select the target device and OS version when creating a Test Plan, not when recording. This means a single recording can be run against multiple device configurations to check for device-specific regressions.
Running a Test Plan
- Create a Test Plan in the Autify dashboard under Mobile
- Add your recorded scenarios to the plan
- Select target devices (one or more)
- Run the plan — Autify queues execution on the selected devices
- Results appear in the dashboard as each device completes
Parallel execution runs across multiple device configurations simultaneously. A plan with 20 scenarios on 3 device configurations can run all 60 scenario-device combinations in parallel.
Uploading Your App Build
Autify executes tests against your app build installed on the cloud device. You need to upload your build before running:
iOS: Upload an .ipa file (signed for distribution or ad-hoc distribution, not development-only signing)
Android: Upload an .apk or .aab file
Via the Autify CLI:
# Upload an iOS build
autify mobile build upload \
--workspace-id <WORKSPACE_ID> \
./build/MyApp.ipa
# Upload an Android build
autify mobile build upload \
--workspace-id <WORKSPACE_ID> \
./build/app-release.apkThe CLI returns a build ID. Reference this build ID in your Test Plan to ensure tests run against the correct version of your app.
CI/CD Integration for Mobile
The same Autify CLI used for web supports mobile test plans:
# Run a mobile test plan and wait for results
autify mobile test run <PLAN_ID> \
--build-id <BUILD_ID> \
--wait \
--timeout 1800GitHub Actions for Mobile
A typical workflow that builds the app, uploads to Autify, and runs tests:
name: Autify Mobile Regression
on:
push:
branches: [main]
jobs:
mobile-tests:
runs-on: macos-latest # Required for iOS builds
steps:
- uses: actions/checkout@v4
- name: Build iOS app
run: |
xcodebuild -scheme MyApp \
-configuration Release \
-archivePath ./build/MyApp.xcarchive \
archive
xcodebuild -exportArchive \
-archivePath ./build/MyApp.xcarchive \
-exportPath ./build \
-exportOptionsPlist ExportOptions.plist
- name: Install Autify CLI
run: npm install -g @autifyhq/autify-cli
- name: Upload build to Autify
id: upload
run: |
BUILD_ID=$(autify mobile build upload \
--workspace-id ${{ vars.AUTIFY_WORKSPACE_ID }} \
./build/MyApp.ipa \
--output-id)
echo "build_id=$BUILD_ID" >> $GITHUB_OUTPUT
env:
AUTIFY_MOBILE_ACCESS_TOKEN: ${{ secrets.AUTIFY_MOBILE_ACCESS_TOKEN }}
- name: Run mobile regression
run: |
autify mobile test run ${{ vars.AUTIFY_MOBILE_PLAN_ID }} \
--build-id ${{ steps.upload.outputs.build_id }} \
--wait \
--timeout 1800
env:
AUTIFY_MOBILE_ACCESS_TOKEN: ${{ secrets.AUTIFY_MOBILE_ACCESS_TOKEN }}Limitations and Practical Constraints
Physical device required for recording: There is no simulator/emulator support. If your team is distributed, each location that needs to record tests needs a physical device.
App must be installable on cloud devices: iOS builds must be signed appropriately for Autify's device farm. Development-signed builds will not install on Autify's devices. You need an ad-hoc or enterprise distribution certificate.
Deep link and push notification testing: Testing flows that require push notifications or deep links from external sources requires additional setup. These are possible but not out of the box.
Biometric authentication: Touch ID and Face ID cannot be reliably automated on cloud devices. You need to design your app to accept a fallback credential in test mode (a feature flag or test environment configuration).
WebViews inside native apps: Elements inside a WKWebView (iOS) or WebView (Android) may not be accessible to Autify's native accessibility tree inspector. Hybrid apps with significant WebView portions may have limited coverage.
When Autify Mobile Makes Sense
Autify Mobile is a strong fit for teams where:
- The mobile app has standard native UI (UIKit / SwiftUI components on iOS, standard Android Views or Compose widgets)
- The QA team owns test creation but has limited Appium or XCUITest expertise
- You are already using Autify Web and want a unified dashboard for both platforms
- The team can maintain a pool of real devices for recording purposes
If your app is heavily WebView-based, requires complex biometric or hardware interactions, or needs custom assertion logic beyond what the no-code builder provides, code-based frameworks (Appium, Detox, XCUITest) will give you more flexibility at the cost of requiring automation engineering skills.
Summary
Autify Mobile extends the no-code testing philosophy from web browsers to native iOS and Android applications. Recording uses a real device and desktop companion app; execution runs on Autify's cloud device farm. The setup has more prerequisites than web testing — device provisioning, signing certificates, ADB configuration — but once the pipeline is in place, QA teams can create and run mobile regression tests without writing Appium scripts or managing device infrastructure themselves.