BrowserStack for Mobile Testing

BrowserStack gives you two ways to test mobile apps on real devices: App Live for interactive manual testing and App Automate for scripted testing with frameworks such as Appium, Espresso and XCUITest. Upload a build, choose device and OS combinations, run the session, then inspect logs, screenshots, network details and video.

It is useful when you need coverage across iOS and Android versions, OEMs, resolutions and orientations without maintaining every device yourself. BrowserStack also supports testing apps that depend on localhost, staging systems or internal services through Local Testing.

App Live vs App Automate

Question	App Live	App Automate
Primary use	Manual, interactive exploration	Automated real-device suites
Typical users	QA, developers, product teams	QA automation and CI teams
Interaction	Tap, swipe and inspect a live device	Run Appium, Espresso or XCUITest scripts
Build sources	Direct upload, Firebase, TestFlight, Play Store and App Store	Upload an APK, AAB or IPA and submit a test run
Useful artifacts	DevTools, screenshots, device logs and network information	Device and text logs, screenshots, video and network information

Use App Live to reproduce a bug or check a flow by hand. Use App Automate when the same checks must run on every pull request or release candidate. Many teams use both: explore manually first, then encode stable scenarios for automation.

What devices and operating systems can you test?

BrowserStack advertises more than 200 device and OS combinations for App Automate and more than 30,000 real iOS and Android device units in its product materials. Treat those as headline figures. Before committing, inspect the live device list and confirm the exact OS versions, OEM models, geography, parallel capacity and plan entitlement you need.

iOS coverage: verify the iPhone and iPad models and iOS versions required by your support policy.
Android coverage: include the OEMs, Android API levels, screen densities and orientations that match your analytics.
Form factors: test phones, tablets, foldables or other layouts only when they are present in your selected plan.
Real hardware: real devices expose OS, OEM, resolution, orientation, permission and performance differences that emulators can miss.

Step-by-step: manual testing with App Live

Build a signed or debug package in the format your target platform accepts: APK, AAB or IPA.
Open App Live and upload the package, or connect a supported source such as Firebase, TestFlight, Play Store or App Store.
Select a device and operating-system version. Start with the models that represent most of your users, then add edge devices.
Exercise the critical path: installation, sign-in, permissions, deep links, rotation, background and foreground transitions, push notifications and offline recovery.
Use the session’s DevTools and device information while reproducing the issue.
Save screenshots, video, logs and network details with the defect report. Record the device model, OS version, build identifier and exact steps.

Testing localhost, staging and private APIs

Enable Local Testing when the app calls a service that is not publicly reachable. BrowserStack documents support for internal environments behind a proxy, firewall or VPN. Validate that the local connector is running, that DNS names resolve from the test session, and that firewall rules permit the required traffic.

Automated testing with App Automate

App Automate runs your test framework on BrowserStack’s real-device cloud. The general flow is:

Upload the app package and receive the app identifier used by the test request.
Define one or more device and OS targets.
Submit the Appium, Espresso or XCUITest suite.
Set concurrency appropriate for your plan and CI budget.
Collect session status, device logs, screenshots, video and network information.

Minimal Appium example (Python)

import os
from appium import webdriver
from appium.options.android import UiAutomator2Options

options = UiAutomator2Options()
options.platform_name = "Android"
options.device_name = "Google Pixel 8"
options.platform_version = "14.0"
options.app = os.environ["BROWSERSTACK_APP_ID"]
options.set_capability("bstack:options", {
    "userName": os.environ["BROWSERSTACK_USERNAME"],
    "accessKey": os.environ["BROWSERSTACK_ACCESS_KEY"],
    "projectName": "mobile-regression",
    "buildName": "commit-123",
    "sessionName": "login smoke test"
})

driver = webdriver.Remote("https://hub-cloud.browserstack.com/wd/hub", options=options)
try:
    driver.find_element("accessibility id", "Login").click()
finally:
    driver.quit()

Set the credentials and app identifier as secret environment variables in CI. Keep the device name, OS version and framework capabilities in version control so a failed run can be reproduced.

Choosing targets and concurrency

Situation	Selection strategy
Pull request smoke tests	One high-use iOS target and one high-use Android target; keep the suite short.
Nightly regression	Expand across supported OS versions, OEMs, orientations and tablets.
Release certification	Use the exact minimum OS versions and flagship or high-volume devices in your support matrix.
Large suite	Increase parallel workers only after measuring queue time, plan limits and test isolation.

Test cases that commonly fail on real devices

Permissions: reset app data between runs and assert the first-run permission path.
Rotation: test both orientations and verify state preservation.
Keyboard and safe areas: check devices with notches, gesture navigation and different keyboard heights.
Network transitions: cover slow, unavailable and restored connections.
Background execution: lock the device, switch apps and resume after notifications or deep links.
Locale, timezone and date: run at least one non-default locale if formatting is user-visible.
Biometrics and hardware: confirm whether the required sensor or camera behavior is available on the selected device.

Debugging artifacts and failure triage

Start with the session status and device/OS metadata. Then correlate the test log with the video timeline and screenshots. Network information can distinguish an app defect from an unavailable backend. Re-run the same test on the same model before broadening the device matrix.

Symptom	Likely cause	Fix
App will not install	Unsupported package, signing problem or incompatible OS	Confirm APK/AAB/IPA validity, signing and minimum OS; retry on a compatible target.
Local API calls fail	Local Testing connector, proxy or firewall issue	Start the connector, verify routes and DNS, and allow the required outbound traffic.
Element is not found	Animation, delayed rendering or an unstable selector	Wait for a stable accessibility identifier, avoid coordinate taps and capture page/device logs.
Test passes manually but fails in CI	Different build, secrets, capability set or timing	Print non-secret configuration, pin the app build, add explicit waits and compare capabilities.
Runs queue for a long time	More requested parallelism than the plan or device pool allows	Check entitlement, reduce simultaneous jobs or schedule large suites in batches.
Video shows a blank screen	App crash, blocked backend or startup race	Inspect crash and network logs, wait for a deterministic readiness signal and retry.

Security and private data

BrowserStack’s security whitepaper states that its iOS and Android inventory consists of real devices hosted in BrowserStack data centers and says BrowserStack has no access to customers’ test data in test sessions. Treat that as a vendor statement. Before uploading production-like data, confirm current retention, isolation, compliance, data residency and private-device terms in the documentation and contract.

Pricing and planning

Pricing changes, so check the current pricing page immediately before purchase. The research snapshot lists annual-billing examples of $12.50 per month for App Live Freelancer, $39 per month for an individual mobile plan and $199 per month for Device Cloud, with team and enterprise options. Your real cost depends on product, billing cycle, parallel capacity, add-ons and required device access.

Estimate sessions per day, average duration and peak parallel runs.
Separate pull-request smoke tests from nightly and release suites.
Confirm whether the exact devices and OS versions are included in the selected plan.
Budget for artifact retention, private-device requirements and local-network testing if applicable.

Performance and reliability practices

Keep smoke tests independent so one failed session does not block the matrix.
Use deterministic waits for application state rather than fixed long sleeps.
Upload one build and reference it across jobs when the platform supports that workflow.
Retry infrastructure failures separately from assertion failures, and cap retries to avoid hiding regressions.
Store the build ID, device, OS, test revision and artifact links with every CI result.
Run a small representative matrix on every change and the full matrix on a schedule.

Or skip the browser setup

If your goal is to capture web pages for test evidence, visual regression or documentation rather than interact with a native app, ScreenshotNeo provides a single HTTP request. It accepts the cookie or consent banner like a visitor, removes more than 60 known consent platforms plus newsletter popups and chat widgets before capture, and lets you turn each step off. Bot checks, blank pages, timeouts, failed loads and cache hits cost nothing; response headers identify the page verdict and whether the shot was billed. Its MCP server lets Claude, Cursor and other MCP clients call take_screenshot, get_page_info and capture_pdf.

See the ScreenshotNeo API documentation for the complete option list.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes full-page and element capture, device presets, custom viewports, retina scale, PDF output, custom CSS and JavaScript, waits, request blocking, headers, cookies, geolocation, caching, signed links, async webhooks, bulk capture and a usage API. One thousand screenshots per month are free with no card; paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

FAQ

Can BrowserStack test an app that is not published?

Yes. Upload an APK, AAB or IPA directly, or use supported distribution sources such as Firebase, TestFlight, Play Store or App Store.

Should I start with App Live or App Automate?

Start with App Live for exploratory and reproduction work. Choose App Automate when repeatability and CI execution matter.

Does BrowserStack use emulators?

The mobile offering described here runs tests on real iOS and Android devices. Confirm the current device catalog for the exact model and OS you require.

How do I prove a failure is device-specific?

Repeat the same build and test on the same device, then compare with another model and OS while reviewing logs, video and network information.

Are the advertised device counts guaranteed?

No. They are headline figures. Check the live catalog, geography, availability, plan entitlement and concurrency before buying.