Why phones do not work this way
Say someone rewrote the program properly. It still would not work the way you expect.
Windows lets one program send mouse clicks and keystrokes to another program. That freedom is what makes a macro recorder possible. Phone systems removed it deliberately.
On a phone, applications are separated from each other. An app cannot normally see what another app is showing. It cannot tap on it either. That separation is a security decision, not an oversight. It is also why the app store is not full of macro recorders.
There is one door. Everything else on this page goes through it.
The accessibility door
Both mobile systems provide a way for software to control the device on the user's behalf. It exists for people who cannot tap or swipe reliably, and it is the only legitimate route to automation on a phone.
On Android this is an accessibility service. An app asks for permission and you grant it in settings. From then on it can see the screen and tap on your behalf. Every automation app and every auto clicker on Android works this way. There is no other mechanism.
On iPhone and iPad the equivalent is narrower. The system has accessibility features that perform repeated taps and replay recorded gestures. They are built in rather than supplied by third-party apps. Apple does not let one app drive another app's interface, so the Android automation category has no iOS equivalent.
The upshot on iPhone is that what you need is already on the device. Look in the accessibility settings, under touch and under switch control. Nothing needs installing.
What the accessibility permission actually grants
Read this before you install anything, because the warning is usually buried.
An accessibility service can read what is on your screen and tap anywhere on it. That is not a limited permission. It covers your messages, your banking app and your passwords as they appear.
This is not a reason to avoid these apps. It is why the permission screen is worded so severely. It is also why the choice of app matters more than any feature comparison.
Ask three things before you grant it. Who made this, and can you find anything out about them. Does it work offline, or is it sending something somewhere. Does your task really justify that level of access.
For many people the honest answer is no, and the job would be quicker done by hand.
Downloaded application packages
This is the part of the page that matters most, and it applies to any app, not just this one.
Search for a mobile version of a Windows program and you will be offered installable packages. The whole category deserves suspicion, for one specific reason.
Any automation tool must ask for the accessibility permission. So you would be granting screen reading and tapping rights to software from a source you cannot identify. It has passed through no review. And it carries the name of a program that has no mobile version at all.
If the name is wrong, nothing after it can be verified. That is the whole argument.
Install from the official store on your platform, where there is at least review and a removal process. On desktop, our own file is published with a checksum for the same reason, and the safety page shows how to check one.
What actually works on Android
Two categories, both through the accessibility door.
Repeated tapping. Small apps that tap one point over and over, at an interval you set. Simple. It covers most of what people actually want.
Full automation. Larger apps that build sequences with triggers and conditions. Something happens when you arrive somewhere, connect to a network, or at a set time. These go well beyond record and replay, and they are the more useful category once you learn one.
Many Android devices include something similar in their own accessibility settings, with no app at all. Manufacturers vary in what they include and where they put it. Look there before installing anything.
What actually works on iPhone
Less choice, and nothing to install.
The accessibility settings include features that can perform repeated taps and replay recorded gestures. They are set up rather than programmed, and once configured they run on the device.
There is also the Shortcuts app. It is genuinely powerful for anything the system exposes: files, messages, settings, timers and much else. It does not tap on other apps' interfaces, because iOS does not permit that. If you want an app driven from the outside, that is not available on iPhone.
If you need this specific program
Use a Windows computer. That is the only place it runs.
It is small and needs no installation. The download page publishes a checksum so you can confirm you have the genuine file.
The same answer applies on every other platform people ask about, including Mac and Chromebook. The wider tool landscape is on the alternatives page.
Frequently asked questions
No. No Android version has ever been released. Any package using the name was created by somebody else.
No, and there will not be. iOS does not let one app control another app's interface. This kind of tool cannot exist there in the form it takes on Windows.
We cannot tell you it is, and the name alone is a problem. No mobile version exists. Whoever built that package chose the name themselves. It will also want a permission that grants screen reading and tapping rights.
On Android, from the official store, and it will ask for an accessibility permission because that is the only mechanism available. On iPhone, look in the accessibility settings, where the feature is already built in.
Because it is the only way an app is allowed to see the screen and tap on it. Phone systems keep apps separated from each other, and this is the single sanctioned exception.
Not in the same way. On Android, some apps replay recorded gestures within the limits of the accessibility service. On iPhone, the built-in features cover repeated taps and stored gestures. Neither offers the free-form recording a desktop gives you.
No. There is no emulator route worth pursuing, and even if the program launched it could not reach anything else on the device.