Your Appium ferry-timetable deep link lands on the wrong screen — how do you diagnose it on Android and iOS?

## Separate two questions before touching anything A deep-link step that ends on the wrong screen has failed at one of two points, and they have nothing to do with each other: 1. **Delivery** — did the URL reach the operating system at all, and did the command return before anything rendered? 2. **Destination** — which application did the operating system hand the URL to? Most wasted triage time comes from conflating them. The command succeeding tells you delivery worked. It says nothing about destination, and destination is where the wrong-screen symptom almost always lives. ## Delivery: the call returns early, on both platforms On Android and on Apple platforms alike, the deep-link call returns once the device has been given the URL — not once your screen has finished building. That produces a specific and recognisable failure shape: - The call succeeds, the next find runs immediately, and it matches whatever is still on screen. - The test then reports a locator failure, pointing you at the locator rather than at the entry. - The same case passes on a fast device and fails on a slow one, which reads as flake. The fix is not a longer sleep. Follow the entry with an ordinary wait on an element that exists only on the destination screen, so the assertion is about arrival rather than about the command. On Android, `waitForLaunch` is sometimes reached for here and it is the wrong lever: it governs whether the driver waits for the started component to hand control back, not whether your content is ready. ## Destination on Android: who won the intent The Android driver asks the system, through `adb`, to start an `android.intent.action.VIEW` intent carrying the URL. If the call did not name `package`, the system resolves that intent against everything installed on the device. - For a custom scheme only your app claims, resolution usually lands correctly. - For an `https` URL the field is crowded and a browser is a very likely winner. - A device carrying a second build of the same app can send the URL to the wrong one. The cheap observation is what is in front right now: `mobile: getCurrentPackage` and `mobile: getCurrentActivity` tell you which application and component the system actually brought forward. If that is a browser, the diagnosis is finished and the fix is to pass `package` on the deep-link call. ## Destination on Apple platforms: which path opened the URL On Apple platforms the driver hands the URL to the operating system and the registered handler opens it, but the route to the OS depends on the target: - On a **Simulator** the driver goes through `simctl`. - On a **real device** it goes through WebDriverAgent. So one suite has two delivery paths, and a case that works locally on a Simulator can behave differently on hardware in a lane. Confirm that `bundleId` was supplied, so the URL is opened by the app under test rather than by whatever the system would otherwise pick, and establish which of the two targets the failing run used before comparing it with a passing one. ## A triage order that works | step | Android | Apple platforms | |---|---|---| | 1. was the target named | was `package` in the parameter map | was `bundleId` in the parameter map | | 2. what is in front now | `mobile: getCurrentPackage`, `mobile: getCurrentActivity` | which application the session is driving | | 3. which delivery path | `adb` on the host | `simctl` on a Simulator, WebDriverAgent on hardware | | 4. did the test wait | wait on a destination element | wait on a destination element | Work it top to bottom and stop at the first step that explains the symptom. Steps 1 and 2 close the large majority of these, because "the URL went somewhere else" is far more common than "the app routed it wrongly". ## What not to conclude - Do not conclude the URL is malformed because nothing visible happened; a scheme no installed app claims tends to fail quietly. - Do not conclude the driver is broken because the call succeeded and the screen did not change; that is the command's normal return behaviour. - Do not switch to tapping through the flow as a fix; that hides the resolution problem rather than answering it, and it resurfaces elsewhere. - Do not assume one platform's explanation transfers: an intent-resolution answer means nothing on Apple platforms, and a `simctl` answer means nothing on Android. ## Saying it well A senior answer is a sequence, not a fact: prove delivery, then prove destination, then and only then suspect the application's own routing — and give the Android and the Apple half of each step separately, because the mechanisms genuinely differ.