skip to content

Physical Hardware

3 roadmaps4 questions

Driving a device you can hold: what Android and what Apple each demand of real hardware before a session will start, and the tunnelling layer that only one of the two platforms needs.

on this pageshow

explore

questions

4

In Appium, what must be enabled on a real Android phone and on a real iPhone before a session starts?

level: juniorimportance: must knowfreq 70%

answer

  1. two checklists, never one
  2. developer options on one side
  3. Developer Mode on the other
  4. the readiness line must read device
  5. the Apple agent must be signed

basics

~20 s

Android needs developer options with USB debugging on and the host authorised, so the phone lists as online. Apple hardware needs Developer Mode enabled, the host trusted, and a signed WebDriverAgent the operating system will launch.

solid answer

~40 s

Two different checklists, and neither covers the other. On **Android**, unlock developer options, switch on **USB debugging**, and accept the host authorisation prompt; the phone must then appear in `adb devices -l` in state `device`, not `unauthorized` and not `offline`. Appium's UiAutomator2 driver installs its helper packages over that same connection. On **Apple** hardware, the device must be paired and trusted by the host, **Developer Mode** must be on, and **WebDriverAgent** must be signed by a real development team, provisioned for that device, and installed — hardware refuses to launch an agent it does not trust, where a simulator would. The XCUITest driver addresses a real device through `devicectl`, and on recent iOS releases over the tunnel from the optional `appium-ios-remotexpc` package. Android needs no such tunnel: adb already is one.

code

bash · 5 lines
bash
# Android: the phone must answer, and its state must read 'device'
adb devices -l

# Apple: the paired real device must be listed by the device tooling
xcrun devicectl list devices

go deeper

for a junior

Be ready to list the device-side switches from memory: developer options and USB debugging on Android, Developer Mode plus host trust on Apple hardware.

for a middle

Explain what each precondition unlocks. The authorised host key is what turns an unauthorized line into a usable device, and Developer Mode is what lets a signed agent launch at all.

for a senior

Show how you triage a bench of real phones: prove visibility and trust first, on each platform's own terms, and only then look at the driver, the agent or the suite.

for a principal

Own the operating policy for a physical bench: who re-arms trust and Developer Mode after a wipe or restore, and how that ceremony stays off the critical path of a release.

## Why real hardware needs preparation at all An Appium session on any target has to do three things before your first find command runs: reach the device over some transport, get permission to install and start code on it, and put a driver agent in place that can see the user interface. A virtual target hands all three over by construction — it is a process on the machine that just launched it. **A physical phone hands over none of them until somebody deliberately opens each door**, and the two platforms open different doors with different keys. That divergence is the whole of this subject: there is no single checklist that covers both, and an answer that gives one is wrong for half the fleet. ## What a real Android phone demands - **Developer options** unlocked on the device. - **USB debugging** switched on inside developer options. - The host machine **authorised**: the first connection raises a trust prompt for the host key, and until it is accepted the serial is reported as `unauthorized`. - A readiness line proving the phone actually answers — `adb devices -l` must list the serial in state `device`, not `unauthorized`, and not `offline` (seen, but not talking). - Some vendors gate installing an app over USB behind a second developer toggle of their own, which has to be on as well. - The device awake and unlocked, because Appium's UiAutomator2 driver then installs and starts its helper packages, `io.appium.uiautomator2.server` and `io.appium.settings`, over that same connection. Once that is true, the session names the phone by its serial and starts. Nothing has to be signed by you for the device to accept the agent, and nothing about the phone's identity is baked into it. ## What a real Apple device demands - The device **paired and trusted** by the host — the same trust relationship Apple's own development tooling uses. - **Developer Mode** enabled on the device itself. On recent iOS and tvOS releases the toggle appears once a development tool has talked to the device, and turning it on restarts the device. - **WebDriverAgent**, the XCUITest driver's on-device agent, **signed with a real Apple development team and provisioned for that device**, installed, and launchable. Hardware enforces that; a simulator does not. - Host tooling that can address hardware: the XCUITest driver drives a real device through `devicectl`, where a simulator is driven through `simctl`. - On recent iOS and tvOS releases, the tunnelled transport supplied by `appium-ios-remotexpc`, which the XCUITest driver declares as an **optional** dependency. Older real devices do not support that mechanism, and simulators never need it. ## The two checklists side by side | What has to be true | Real Android device | Real Apple device | | --- | --- | --- | | Opened for development | developer options plus USB debugging | Developer Mode enabled on the device | | Host trusted by the device | adb authorisation prompt accepted | pairing and trust prompt accepted | | Readiness check before you debug anything | `adb devices -l` shows state `device` | the device is listed by `devicectl` | | Driver agent | helper packages installed over the existing connection | WebDriverAgent signed for that device and installed | | Extra transport layer | none — adb is the transport | remote XPC tunnel on recent releases | ## A worked case A recycling-collection reminder app has a suite that is green on virtual targets and dead on the two phones on the desk. On the Android phone the run fails before a single command is sent: `adb devices -l` shows the serial as `unauthorized`, because the phone was wiped last week and the trust prompt was never accepted again — tap it, and the same suite starts. On the iPhone the run fails later, while the agent is being put in place: the same restore cleared Developer Mode, and the development profile that provisioned WebDriverAgent no longer lists that device. One suite, two failures, two entirely unrelated repairs. ## What is not part of this - **Driving adb by hand** and Android device-debugging workflows belong to the Android SDK tooling subject, not here. - **Which capability names** select or configure a target is a separate question from what the hardware itself demands. - **Agent start-up failures after the device is ready** — a build that times out, an agent socket that hangs up — are triage, not preconditions. - **Hardware you rent rather than hold**, and how many devices a matrix should carry, are decisions owned elsewhere. The habit worth forming is simple: **before blaming the suite, prove the device is visible and trusted on its own terms** — one command on Android, one settings screen plus a signed agent on Apple hardware.

  • What does an unauthorized line in adb devices -l tell you about an Android phone?
    That the phone is visible over the cable but has not accepted this host's key. USB debugging is on, yet the trust prompt was dismissed, never shown because the screen was locked, or invalidated by a wipe. Re-plug the cable, unlock the screen and accept the prompt, and the serial flips to `device`. No Appium capability can bypass that consent.
  • Why can a real Apple device refuse a session it accepted yesterday?
    Because a device-side precondition decayed rather than a capability changing. A restore or an update can clear Developer Mode and the host pairing, and the development profile that provisioned WebDriverAgent for that device can expire or stop listing it. The suite is identical; what lapsed is the device's trust in the host and in the agent.

saying these in an interview costs you the question

  • Thinks enabling USB debugging is the whole story on both platforms
  • Says a real iPhone needs no signing because the simulator ran fine
  • Treats an offline or unauthorized adb line as a usable device
  • Believes Appium can drive Apple hardware without pairing or Developer Mode
  • Assumes the tunnelling package is needed for simulators as well
  • Thinks Developer Mode is a host setting rather than a device toggle
open as a page

In Appium, how does agent signing differ between a real Apple device and a real Android device?

level: middleimportance: should knowfreq 48%

basics

~20 s

Both platforms sign something, for different reasons. Apple hardware launches WebDriverAgent only if it is signed by a real development team and provisioned for that device. Android signs the packages it installs with a default certificate and no per-device provisioning.

open as a page

Can Appium drive a real iPhone from a Linux or Windows host, and what does that give up?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Yes, within limits: a Windows or Linux host can drive real Apple devices on recent releases, but not simulators, with no automatic device selection and no agent build step, so WebDriverAgent must already be installed. Android hardware is host-indifferent.

open as a page

In Appium, why might newer iPhones fail to start a session when older ones still work?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Newer real Apple devices are reached over a tunnelled transport that older ones do not use. The XCUITest driver gets it from the optional package appium-ios-remotexpc, so a host without that package fails only on the newer hardware. Android needs no equivalent.

open as a page