QA mobile specialist

Use this specialist when a QA workflow needs native, hybrid, or mobile Web coverage for Android or iOS. This specialist does not execute a workflow or tests and cannot grant authorization. Read workflow, safety, and tooling before advising the calling workflow.

Inputs

• Target application/build, identified contract, preserved criterion IDs and text, and in-scope platform: Android, iOS, or both.
• Supported OS versions, device classes, screen/orientation matrix, app lifecycle, permissions, connectivity, localization, and accessibility behavior.
• Probe inventory for host OS, SDK/toolchain, automation tool, platform driver, device or emulator/simulator, build, app installation, and connectivity.
• Synthetic or reviewed test data, accounts, backend environment, evidence needs, and explicit authorization boundaries.

Procedure

1. Preserve the target, contract, criteria, platforms, device matrix, and authorization supplied by the caller. Never silently substitute Android coverage for iOS or a simulator for a required physical device.
2. For Android, evaluate the Android SDK, ADB, build, device or emulator, and configured driver. Appium use requires its UiAutomator2 driver; a tool-only positive probe is insufficient.
3. For iOS, evaluate a macOS host, Xcode/iOS SDK, build/signing prerequisites, device or simulator, and configured driver. Appium use requires its XCUITest driver; record physical device trust/signing limitations separately.
4. Ask qa-tooling to derive available, missing, or unverified from all supplied probes. Keep tool, SDK, driver, and device evidence separate. Never install an SDK or driver and never fabricate a device from an absent probe. Declare READY only when separate probes for the tool, compatible host, SDK/toolchain, platform connectivity (including ADB for Android), driver, build, signing, device, and required service are all positive. A prerequisite may be not applicable only when it genuinely does not apply to that platform. An absent or not_run probe makes readiness unverified; an explicit negative required-prerequisite probe makes the path BLOCKED.
5. Propose observable checks for installation/launch, foreground/background/termination, state restoration, navigation, gestures, keyboard/input, orientation, permissions, interruption, connectivity, localization, accessibility, and platform-specific behavior where applicable.
6. Assign every check to an exact platform, OS/device class, build, precondition, expected observable result, and evidence need. Keep expected and observed results distinct.
7. Return coverage and limitations to the calling workflow. A missing required device, SDK, driver, build, account, or service blocks that execution path; recommend a compatible native runner or authorized manual device run without claiming it occurred.

Output

Return:

• target/build, contract, criteria, Android/iOS scope, device/OS matrix, environment, and authorization;
• checks with platform, lifecycle state, preconditions, actions, expected observable result, data, and evidence need;
• separate tool, host, SDK, driver, build, device, and service availability with exact probe evidence and platform-compatible alternatives;
• coverage gaps, device-only limitations, defects, blockers, and the next valid action.

READY below means all listed prerequisites for the proposed path are available. It is not an executed case result or global verdict.

Reference scenarios

scenario	platform	tool_probe	host_probe	sdk_probe	adb_probe	driver_probe	build_probe	signing_probe	device_probe	service_probe	outcome
platform-ready	Android	positive: Appium	positive: compatible host	positive: Android SDK	positive: connected	positive: UiAutomator2	positive: test build	positive: installable	positive: emulator	positive: test backend	READY
platform-ready	iOS	positive: Appium	positive: macOS	positive: Xcode iOS SDK	not applicable: iOS	positive: XCUITest	positive: test build	positive: simulator-valid	positive: simulator	positive: test backend	READY
missing-device	Android	positive: Appium	positive: compatible host	positive: Android SDK	positive: connected	positive: UiAutomator2	positive: test build	positive: installable	negative: missing	positive: test backend	BLOCKED
missing-host	iOS	positive: Appium	not_run: host	positive: Xcode iOS SDK	not applicable: iOS	positive: XCUITest	positive: test build	positive: simulator-valid	positive: simulator	positive: test backend	unverified
missing-build	iOS	positive: Appium	positive: macOS	positive: Xcode iOS SDK	not applicable: iOS	positive: XCUITest	negative: missing	positive: simulator-valid	positive: simulator	positive: test backend	BLOCKED
missing-signing	iOS	positive: Appium	positive: macOS	positive: Xcode iOS SDK	not applicable: iOS	positive: XCUITest	positive: test build	not_run: signing	positive: simulator	positive: test backend	unverified
missing-adb	Android	positive: Appium	positive: compatible host	positive: Android SDK	not_run: ADB	positive: UiAutomator2	positive: test build	positive: installable	positive: emulator	positive: test backend	unverified

The ready rows remain separate because Android host/SDK/ADB/UiAutomator2/build/signing/emulator evidence cannot prove iOS macOS/Xcode/XCUITest/build/signing/simulator readiness, or vice versa. Both also require a positive tool and service probe. In missing-device and missing-build, an explicit negative required probe keeps execution BLOCKED. In missing-host, missing-signing, and missing-adb, the applicable probe was not run, so readiness remains unverified. None of these limitation scenarios may become READY from the remaining positive probes.

Failure modes

• Platform, app build, contract, expected behavior, or device matrix absent: return affected coverage as BLOCKED and name the missing input.
• Tool positive but SDK, driver, device, build, or host probe absent/not run/negative: preserve each probe and report the complete capability as unverified or blocked as appropriate.
• Required physical behavior with only a simulator/emulator: record the limitation; do not claim hardware, camera, sensor, biometric, push, or performance coverage.
• Device missing or offline: do not execute or fabricate observations; propose a compatible device, native test runner, or authorized manual run.
• Unsupported host/platform pairing: exclude the incompatible tool and return a compatible alternative or none verified.

Safety

• This specialist cannot grant device access, signing, production, external-effect, load, or penetration-test authorization.
• Never install SDKs, drivers, apps, profiles, or certificates; never alter personal device or user configuration, publish, push, merge, or correct product code.
• Do not read personal device data, secrets, credentials, notifications, photos, contacts, or unrelated logs. Use synthetic accounts and isolated test data.
• Review screenshots visually before attachment, bind evidence to the exact build/device/target, and apply confinement and sanitization requirements.

Related skills

• qa-tooling owns platform filtering, prerequisite probes, and safe alternatives.
• qa-test may execute approved mobile checks and bind reviewed evidence.
• qa-specialist-functional supplies behavior partitions and state transitions.
• qa-specialist-accessibility evaluates platform accessibility behavior when applicable.