A script that has been running fine reports an error one morning. You spend a while in the code and find nothing wrong. Then it turns out the app shipped an update and moved a button.
In any team that scripts, this happens sooner or later. The reason is simple: the app belongs to somebody else, and their release schedule is not yours to control.
What an update actually breaks
Get the problem precise first. An update does not break your business logic. It breaks the way your script locates its targets.
Scripts find elements by two means: position and identity.
Position means which row and column, measured off a screenshot and written into the script. Move the interface and every coordinate is wrong.
Identity means a control ID or a control path. In principle more stable, except that app updates often regenerate these wholesale, particularly when the front-end framework is upgraded.
So the failure arrives suddenly. Fine yesterday, broken today, with nobody having edited the script in between. The environment changed underneath it.
The quieter problem: silent updates
Harder than an update you know about is one you do not.
Many apps update quietly overnight while the phone sits on WiFi. The next morning the script runs as usual, errors, and you spend time investigating a change you never knew happened.
That has a practical consequence for triage: you cannot rely on “was there a recent update” to locate the cause. You have to work back from the error.
Reading the screen absorbs the change
iEasyRun locates differently: it does not record coordinates, it reads what is on the screen.
Before each step it takes in the current page, meaning which elements are present and what they say, decides which one is the target, and taps it.
That difference shows up very plainly when an app updates:
| Change | Coordinate script | Screen reading |
|---|---|---|
| Button moved | Breaks, needs rework | Fine |
| Menu gained a level | Breaks, needs rework | Fine |
| Control IDs regenerated | Breaks, needs rework | Fine |
| An extra dialog appears | Usually hangs | Usually dismisses it |
| Button label changed | Unaffected | Needs one added line |
| Flow gained a step | Breaks | Needs the flow edited |
The first four rows are what updates actually look like most of the time, and they are exactly its strength. The last two are the ones that genuinely need you, and they are far less common.
What still needs you
Two cases, honestly.
- The label changed：Export becomes Download, or My becomes Profile. It cannot infer that, because it is genuinely matching text. The fix is simple: add the new wording to the description, as in “tap Export, called Download in some versions”.
- The flow changed：Export used to download directly; now a format picker appears first. That is not a recognition problem, it is a change to the business process, and you add the step to the description.
Both are explicit, one-time edits. Once made, they are done, unlike coordinates, which need redoing every time the interface shifts.
One further note: run a verification after upgrading. It will probably need nothing, but the run confirms it. This matters most for low-frequency work, which might run once every two months and surface the problem at the least convenient moment.
So should the scripts go?
No.
Judge on how often things change:
- Runs daily, unchanged for two years, sensitive to speed: keep the script, it is more efficient
- Interface iterates quickly, or you would rather not maintain it: drive it from a description
- Somewhere in between: leave it and decide the next time it breaks
In practice, plenty of teams run both. Core high-frequency flows stay on scripts, while the peripheral, changeable, low-frequency work runs from descriptions. The two coexist on one phone without conflict.
Cutting down on rework
Two habits cover most of it.
- Describe entry points as what they do, not where they are：“Open my orders” is far more durable than “tap the icon in the bottom right”. The first states intent, the second states position, and position is what changes.
- Make the volatile parts parameters：Phrasing, keywords, target stores: these differ between runs. Make them fillable at call time rather than written into the flow, so an update only touches the one place that actually changed.
When something does go wrong
Look at the screenshot of the failing step in the execution history.
This beats reading the error text. The message usually says only that an element was not found, whereas the screenshot tells you which page it was actually sitting on. Update-related failures look the same roughly eight times in ten: it is parked on a screen you have never seen before.
Seeing that page tells you which line to add, typically something like “if the promo screen appears, tap skip first”.
The software is completely free and runs on your own computer. Scripts breaking will not stop happening, but it can move from re-tuning after every release to adding a sentence now and then. The savings compound quietly: three or four fewer emergency fixes a year is a couple of days back, plus the afternoon nobody loses to a batch that failed overnight. For more scenarios, read mobile UI automation testing or phone automation without code.
Frequently asked questions
- What is the most common cause of a failing script?
- Interface updates, by a wide margin. A button moves, a menu gains a level, an extra dialog appears, or control IDs get regenerated. None of it touches your business logic, but all of it breaks scripts that rely on fixed coordinates and control paths.
- Why does reading the screen avoid this?
- Because it identifies targets by meaning rather than position. A script knows the pixel at row 320, column 65. It knows the button labelled Export. Move the button and the meaning is unchanged, so it still finds it.
- When does it fail too?
- Two cases. The label changes, so Export becomes Download. Or the flow itself changes, such as an extra confirmation step. The first needs one added line, the second needs the flow edited.
- Should I re-verify after an app update?
- Worth doing. It will probably need no changes, but a confirmation run is cheaper than discovering the problem when business is affected. This matters most for low-frequency work that only runs every couple of months.
- Should the old scripts be deleted?
- No. High-frequency work with a completely stable flow and a need for speed is still more efficient as a script. Both approaches coexist on the same phone.
- The error just says element not found. How do I diagnose it?
- Look at the screenshot of that step in the execution history first. Where it actually stopped tells you more than the error text. Update-related failures usually look the same: it is sitting on a page you have never seen.
- Do silent app updates matter?
- Yes, and they are the harder case. Many apps update quietly in the background, so you may not know anything changed. That is precisely where position-based targeting suffers, because the change happened while you were not looking.
- How do I cut down on update-related rework?
- Two habits. Describe entry points as what they do rather than where they are. And make the volatile parts fillable parameters. Do both and a typical update costs one or two lines.
Script broken again?
Switch to a method that ignores coordinates
Software is completely free and runs on your own computer.