In Appium 3, what replaced the touch/perform endpoints, and is TouchAction gone?

## Two facts that get conflated Ask this in an interview and you usually get one of two wrong answers: *"TouchAction was removed"* or *"TouchAction still works"*. Each is half the truth, and the half it drops is the half that explains the symptom teams actually hit. **Fact one, on the wire.** The Appium 3 server no longer routes the old touch endpoints. `POST /session/:sessionId/touch/perform` and `POST /session/:sessionId/touch/multi/perform` were the transport for the old touch DSL, and they are gone from the current server's route table. Their replacement is the W3C Actions API at `POST /session/:sessionId/actions` — the one gesture vocabulary Android's UiAutomator2 driver and Apple's XCUITest driver both accept, which is why the replacement is a simplification rather than a swap. **Fact two, in the clients.** The helper classes did not go anywhere. `java-client` still ships `io.appium.java_client.TouchAction`, and it carries `@Deprecated`; the client's changelog records deprecating the obsolete touch helpers, not removing them. `MultiTouchAction` sits in the same position. ## Why that combination is the confusing one | | the old touch DSL | the W3C Actions API | |---|---|---| | endpoint | `POST /session/:sessionId/touch/perform` and its multi variant | `POST /session/:sessionId/actions` | | status on a current server | not routed | the supported path | | status in the clients | class present, marked `@Deprecated` | the current API | | what a mistake looks like | a clean build, then a run-time failure | — | Deprecation is a compiler warning; a missing route is a run-time failure. A suite full of old gesture code therefore builds green, passes review, and fails on its first gesture against a current server. Nothing in the build can tell you, because the client is not the component that removed the endpoint. ## The residue, and why grepping misleads Searching a checkout for the old names finds hits that are not reachable API. Android's Espresso driver still lists the old touch path in its proxy-avoid regexes, and its on-device server still registers touch-action handlers of its own, under a comment wondering aloud whether they can be deleted for lack of callers. Present in a repository is not the same as reachable through a current server, and this is the general trap in Appium's migration story: some things were removed, some were moved into per-driver execute methods, and some were simply left behind as dead weight. Read the route tables, not the search results. ## Migrating a chain 1. **Find the call sites by name, not by build output.** Deprecation only warns, so grep for the helper classes rather than trusting the compiler to fail. 2. **Rewrite each site as one pointer source** posted to the actions endpoint: `pointerMove` where the old code moved, `pointerDown` where it pressed, `pause` where it held, `pointerUp` where it released, with a `pointerType` of `touch` in the source's `parameters`. 3. **Replace hard-coded coordinates with element origins** where the old chain carried pixels, so the rewrite also buys you portability across devices. 4. **Where a chain was really expressing one named gesture,** consider each driver's own gesture command instead — accepting that those are per-driver, so you maintain an Android branch and an Apple branch rather than one chain. 5. **Verify against one device of each platform** before migrating the rest. Run the scaffolding-inspection app's tag-drag and long-press flows on an Android device and on an Apple one; those two cover most of what the old DSL was used for. ## What to say when asked - Name both facts. "The route is gone; the class still ships, deprecated" is the complete answer, and either half alone is marked wrong. - Explain the symptom that follows from them: compiles clean, fails at run time, with nothing in CI's build step to catch it. - Say what replaced it and why it is better: one endpoint, one pointer vocabulary, both platforms. - Avoid asserting a release number. The honest framing is the architectural line — Appium 2 made drivers installable extensions, and Appium 3 pulled legacy routes out of the server in favour of the W3C Actions API and per-driver execute methods. ## The wider habit worth taking away Deprecated and removed are different states, they live in different components, and a mobile stack has at least three components in play: the client library you compile against, the server that routes the request, and the driver plus its on-device agent that executes it. A statement like "X does not exist any more" is only meaningful once you say **where**. That habit is what keeps a migration honest, and it is exactly what this question is testing.