Autify Mobile Testing: iOS and Android Test Automation Without Code

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 devices shows 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

  1. Connect your iOS or Android device via USB
  2. Open the Autify Mobile recorder application
  3. The recorder detects connected devices — select your target device
  4. For iOS: the recorder may prompt to install a helper app on the device; approve this
  5. 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: NavigationTitle

Each 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 StepAssertion, 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

  1. Create a Test Plan in the Autify dashboard under Mobile
  2. Add your recorded scenarios to the plan
  3. Select target devices (one or more)
  4. Run the plan — Autify queues execution on the selected devices
  5. 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.apk

The 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 1800

GitHub 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.

Read more

Start now free