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

## The claim to avoid The tempting one-liner — *Apple makes you sign things and Android does not* — is wrong, and it is wrong in a way that costs debugging time. Both platforms sign. The real divergence is **what** is signed, **who** issues the signature, and **whether the device itself is named in the credential**. Getting that straight explains why an Apple failure looks like a per-device problem and an Android failure looks like a per-build problem. ## What Apple hardware checks The XCUITest driver drives a real device through **WebDriverAgent**, an on-device agent built on Apple's UI testing machinery. Hardware will not launch code it does not trust, so before a session can begin the agent must be: - **signed** with a real Apple development team identity, not an ad-hoc or absent signature; - **provisioned** by a profile that covers the specific device it is being installed on; - **installed** on that device and launchable. Because the profile names devices, an agent build is not universally portable: a phone that is not in the profile refuses the agent that works perfectly on the phone beside it. The credential also expires, so a bench that was fine last quarter can stop starting sessions with no change to the suite at all. Note the target of all this: it is the **test agent**, not the application under test. Signing the app for release is a different discipline with different tooling and different owners. ## What the Android side actually signs Android signs packages, but the signature is not a per-device credential: - `appium-adb` signs APKs with a **bundled default certificate**, so the driver can put its own helper packages onto the phone without you supplying anything. - Appium's **UiAutomator2 driver re-signs the app under test** when a certificate check fails, so a build signed with an unexpected identity is repaired rather than rejected. - Appium's **Espresso driver requires the app under test and its test package to share a signature**, because the instrumentation runs inside the application's process and Android will not let an unrelated signer attach to it. None of these mention a device. A phone with USB debugging on and the host authorised will accept a debug-signed package, whichever phone it is. That is the structural difference: **Android signing is about which code may attach to which code; Apple signing is about whether this device may run this agent at all.** ## Side by side | Question | Real Android device | Real Apple device | | --- | --- | --- | | What carries the signature | the packages installed on the phone | the on-device test agent, WebDriverAgent | | Who issues it | a bundled default certificate, or a keystore you supply | a real Apple development team identity | | Is a device named in it | no | yes, through the provisioning profile | | Typical failure shape | a signature mismatch between app and test package | the agent will not launch on one specific device | | Does the simulator or emulator behave the same | broadly yes | no — a simulator runs an agent hardware would refuse | ## Failure modes you will actually meet A recycling-collection reminder app is being driven on a small bench. On the Apple side, a new handset joins the bench and every run against it dies while the agent is being installed, while the two older handsets stay green — the profile that provisions the agent simply does not list the new device. On the Android side, the same suite fails on all phones at once with the instrumentation refusing to attach, because a rebuilt application package and its test package no longer share a signer. **The Apple failure tracks a device; the Android failure tracks a build.** That contrast is the fastest way to place a signing problem on the right platform's side of the fence. One more trap worth naming: a simulator will happily run an agent that hardware refuses, so a green virtual run proves nothing about the signing story. If the first hardware session of the week fails, treat the agent's credential as a suspect before touching any capability. ## Where this stops - **Which capabilities configure the signing identity** for a run is a separate, dedicated subject; the point here is what the hardware demands and why. - **Signing an application for distribution**, and the release-automation tooling around certificates, is somebody else's territory entirely — the signature at issue here is the test agent's. - **What to do when a signed, installed agent still will not start** — build timeouts, a hung agent — is start-up triage rather than a signing question.