Why can one Appium log configuration not serve an Android and an iOS lane, and what do you standardise?

## The seam runs between the process and the session Every argument about "one logging config for the whole matrix" resolves once you see that Appium's log surface has two halves with different scopes and different owners. **Half one is process configuration.** The `appium` server's own stream is shaped by server flags — `--log-level` for verbosity, `--log` (short `-g`) for a file destination, `--log-timestamp` for per-line timestamps, alongside `--log-format`, `--log-filters`, `--log-no-colors`, `--debug-log-spacing`, `--long-stacktrace` and `--trace-dir` in the same schema. These are decided when the process starts. They apply to every session that process handles, so they cut across the platform divide, not along it. **Half two is session vocabulary.** A device log is fetched with `POST /session/:sessionId/se/log`, naming one type in the body, and discovered with `GET /session/:sessionId/se/log/types`. The route is shared; the names are not. The Android drivers publish `logcat` and `bugreport`; the XCUITest driver publishes `syslog`, `crashlog` and `safariConsole`. Nothing is common between the two lists. | | server's own log | device log | |---|---|---| | scope | the `appium` process | one session | | configured by | server flags at startup | a type name in the request body | | portable across platforms | yes, identically | no, no shared name | | where it belongs in your code | launch/infrastructure | a per-platform mapping | ## What you can standardise, and should These are the parts where one decision genuinely serves both lanes: - **Verbosity.** One `--log-level` choice for the fleet, so a failure on either platform yields comparable detail. - **Destination and layout.** `--log` per server process, with a naming scheme that says which process wrote which file. If you run a process per device, this gives you a per-lane file for free. - **Timestamps.** `--log-timestamp` everywhere, without exception. It is what makes a server line, a test report line and a device log entry line up at all; without it correlation degrades into reading by eye. - **The route.** `POST /session/:sessionId/se/log` and `GET /session/:sessionId/se/log/types` are the same on both lanes, under the Appium 3 `se/` spelling. Your transport code has no platform branch in it. - **The moment of capture.** Both routes are keyed by session id, so on both platforms the pull happens inside the session's own scope, never after it. ## What you must not standardise, and why pretending otherwise fails The temptation is to pick one bucket name and call it the suite's device log. It fails quietly and in a specific way: the URL resolves on both platforms, so nothing about the request shape warns you. The divergence lives entirely in the body, in a string. A helper written and proven on Android is structurally correct on an Apple session and semantically meaningless there. There is a second asymmetry worth naming honestly rather than papering over. The Android drivers declare `mobile: startLogsBroadcast` and `mobile: stopLogsBroadcast`, so an Android session can stream the log as it is produced; the measured XCUITest execute-method surface lists no counterpart. You can respond to that in one of two ways, and both are defensible: 1. **Take the asymmetry.** Stream on Android, pull on Apple platforms, and accept that your driver layer has two shapes. You get better evidence on the lane where the session may die with the app. 2. **Level down.** Pull on both, so one code path serves the whole matrix. Simpler to keep correct, weaker exactly when the crash also removes the session you needed to ask. The wrong answer is the third one: assume the broadcast exists on both because the name is a real Appium identifier. It is real and it belongs to a specific driver family. ## Where the platform branch should live One place. The suite expresses an intent — "give me the device log for this caving trip-log session" — and exactly one component turns that into a type name. That component either reads `platformName` for the session, or calls `GET /session/:sessionId/se/log/types` and picks from what the driver actually published. The second is stronger: it is a fact from the session rather than an assumption about it, and it degrades gracefully when a driver's list is not the one you expected. The payoff is that every other layer stays platform-blind. Test code never mentions `logcat`. Reporting never mentions `crashlog`. When a third driver enters the matrix, one mapping changes. ## The tradeoffs you actually own - **Verbosity against volume.** A high `--log-level` across a whole fleet produces a great deal of output whose value concentrates in the runs that failed. - **One server process or many.** Many gives you clean per-lane files and independent flags at the cost of orchestration; one gives you a single interleaved file that you separate by session id. - **Streaming against uniformity**, as above — better Android evidence versus one code path. - **Discovery against a hardcoded map.** A `se/log/types` call per session costs a round trip and buys correctness that a table in your repo cannot guarantee. None of these has one right answer, and that is the point: the portable half is a decision you make once, and the divergent half is a mapping you own deliberately rather than discover by outage.