How would you design one Appium lifecycle helper when only Android has mobile: startActivity and only Apple has mobile: launchApp?

## The shape of the problem A cross-platform Appium suite for a school bus tracking app runs the same cases against two drivers whose lifecycle surfaces overlap but do not match. Four commands are common to the Android drivers and the XCUITest driver: `mobile: activateApp`, `mobile: backgroundApp`, `mobile: terminateApp` and `mobile: queryAppState`. Around that core, Android alone offers `mobile: startActivity`, and Apple platforms alone offer `mobile: launchApp` and `mobile: killApp`. The design question is what to unify, what to expose separately, and what to refuse to unify at all. ## What is genuinely portable The four shared commands are the spine, and they unify cleanly because both platforms answer the same question with the same vocabulary: - **Bring forward** — `mobile: activateApp` on both, given the app identity. - **Send to background** — `mobile: backgroundApp` on both, given a number of seconds. - **Stop** — `mobile: terminateApp` on both, reporting whether there was anything to stop. - **What state** — `mobile: queryAppState` on both, answering with the same ordered ladder. Name the helper's operations after the **test's intent** rather than after the command: a case should read *send the app to the background for twenty seconds*, not *execute a driver-specific name*. That keeps cases readable and leaves the helper free to change how each platform satisfies the intent. ## What must not be faked The asymmetries are where suites go wrong, and there are three ways to handle them — two acceptable and one that quietly destroys the value of the suite. 1. **Expose them under platform-named operations.** An Apple-only *force kill* and an Android-only *start component* are honest. A case that calls one has visibly chosen a platform-specific path. 2. **Express one intent with two structurally different implementations** — but only when they genuinely satisfy the same intent. A cold start is a legitimate example: Apple platforms use `mobile: launchApp`, Android stops the app and re-activates it. The intent is identical even though the mechanism is not. 3. **Never make it a silent no-op.** A helper method that does nothing on the platform that cannot perform it is the failure mode to design against: the case runs, asserts, and passes, having skipped the interruption it exists to test. A green result that proved nothing is worse than a red one. The same rule bans the quiet alias. Mapping *force kill* onto `mobile: terminateApp` on Android looks tidy and hides a real behavioural difference behind one name; the day the difference matters, nothing in the code says it exists. ## The pieces worth centralising - **App identity.** The package name and the bundle identifier are two values for one concept. Resolve them once per platform, and let every lifecycle call read from that single place rather than passing literals around. - **State interpretation.** The rungs of the state ladder should be named in one module. Cases compare against a name, never against a bare number. - **Verification.** After every transition, poll the state ladder for the expected rung before doing anything else. This replaces sleeps that encode guesses about hardware you do not control, and it makes a failed transition fail at the transition instead of three steps later as an unfindable element. - **Component names, on Android.** If the suite starts named components at all, the names live in one file so a rename by the app team is one edit. ## Where to stop abstracting A lifecycle helper should own transitions and their verification. It should not own what a case asserts after a transition — that is test design, and the moment the helper starts making assertions, every case inherits the same opinion about what surviving a background trip means. Keep the helper mechanical: put the app somewhere, confirm it got there, hand control back. It is also worth resisting the urge to cover every platform-only command on day one. Add an operation when a case needs it. A helper full of thin wrappers nobody calls is a maintenance surface with no users, and each one is a chance to write a fake twin nobody noticed was fake. ## How to judge the result A good cross-platform lifecycle layer passes three tests. A reader of a case can tell what the app is being asked to do without knowing which driver runs it. A reader of the helper can see exactly where the two platforms diverge, because the divergence is written down rather than smoothed away. And no operation in it can succeed by doing nothing — if a platform cannot perform the transition, the suite says so loudly, at the point of the call.