How would you shape Appium capability profiles when one lane runs Android emulators and another Apple simulators?

## Start by admitting how little is shared The instinct on a cross-platform suite is to build one capability profile with a couple of platform overrides. On the virtual-target seam that instinct produces a profile that is mostly overrides, because the Android emulator path and the Apple simulator path share almost nothing at session start: different capability names, different host tooling, different agents, different host requirements. What is genuinely common is thin, and mostly not about the device at all: - The server URL the client is built on. - Session-hygiene settings such as the idle timeout. - Naming and tagging conventions for the run itself. - The *shape* of the profile — that there is an artifact key, a target key, a driver key — even though every value differs. Everything below that is platform-exclusive, and pretending otherwise is how suites acquire keys that quietly do nothing on one side. ## The two exclusive blocks The Android emulator block carries `platformName: Android`, an Android `appium:automationName`, `appium:avd` naming an AVD that exists on that host, and the launch shaping (`appium:avdArgs`, `appium:isHeadless`) that applies when the driver performs the launch. The Apple simulator block carries `platformName: iOS`, `appium:automationName: XCUITest`, the Apple-side selection keys, and `appium:simulatorStartupTimeout` as the boot budget for `simctl`. The artifact differs on both sides, so it belongs in the platform block rather than the shared one. The test for whether a key belongs in the shared block is simple: **would the other driver do something meaningful with it?** `appium:avd` fails that test on the Apple side, and it earns nothing by travelling there. ## The more dangerous case: a name that exists on both A key only one driver knows is a small problem — it is dead weight. The expensive case is a key that both drivers declare and implement *differently*. Appium has such names, and this is where a unified profile does real damage: a reviewer reads one key, assumes one behaviour, and the two lanes diverge in production while the configuration looks symmetric. So my rule is ordered: 1. A key both drivers treat identically may live in the shared block. 2. A key only one driver knows lives in that driver's block. 3. A key both drivers know but implement differently lives in **both** platform blocks, written out twice on purpose, with a comment saying why. Rule three feels like duplication and that is the point. Duplication that is visible costs a reviewer seconds; a shared key with two meanings costs an on-call engineer an afternoon. ## The constraint no configuration can hide An Apple simulator can only be run on macOS, because the driver boots it with `simctl` and builds WebDriverAgent with `xcodebuild`, both Xcode tooling. An Android emulator lane has no such tie. That asymmetry is not a configuration problem and cannot be papered over by a profile layer: the two lanes need different kinds of machine. Any design that promises "one suite, one config, any host" is telling a story the tooling will not honour. I would rather make that visible in the profile's own structure — an Apple lane that is explicitly macOS-bound — than have someone discover it while trying to move the suite. ## What each choice costs - **Two honest blocks**: more lines, obvious divergence, easy review, no surprises. The cost is that nobody gets to call the suite platform-agnostic. - **One unified block with overrides**: looks tidy, hides which half is live on any given run, and rewards only the reader who already knows the answer. The cost lands later, on whoever debugs it. - **A home-grown abstraction over both**: worst of the three here, because the abstraction must encode the divergence anyway and then hides it behind names the drivers do not use. ## The judgment I would defend On a divergent seam, configuration should *show* the divergence rather than smooth it. The suite's own code can share everything above the capability layer — page objects, flows, assertions about the fitting journey — and that is where cross-platform economy genuinely lives. The capability profile is the one place a reader must be able to see, in a single screen, which target class this lane runs on, which host it requires, and which keys are real for it. Buy the sharing where it is free, and pay for the honesty where it is not.