I’m building ScriptTap, a no-root Android automation app for user-controlled phone workflows.
The app lets people create scripts with taps, swipes, routines, screen-aware checks, OCR/text detection, image/pixel checks, variables, logic, and AI-assisted script creation.
The technical side is hard, but the trust side may be harder.
ScriptTap needs Android Accessibility permission because user-authored input automation requires it. That is a powerful permission. I do not want to minimize it, hide it behind vague onboarding copy, or expect people to click through without understanding what they are enabling.
That creates a product-design problem.
If the copy is too soft, it feels dishonest.
If the copy is too warning-heavy, a legitimate automation tool can feel suspicious before the user even understands what it does.
The explanation I am trying to make clear is:
- ScriptTap is no-root.
- Scripts are created and controlled by the user.
- Screen capture is user-controlled.
- It does not bypass Android permissions, lock screens, app security, or consent flows.
- Accessibility is required for overlay/input automation, so users should understand why it is being requested.
The short version I keep coming back to is:
ScriptTap uses Accessibility so your scripts can interact with the screen the way you tell them to. This is a powerful permission. You should only enable it if you understand and trust what the app is doing.
For developers who have built apps with sensitive permissions:
How did you explain the permission without either hiding the risk or scaring users away from a legitimate feature?
Top comments (2)
Different domain, same tension. I build Money Me, a personal finance app, and the scary permission in that world is bank linking through Plaid. People hesitate to give an app read access to every transaction, and reassuring copy only goes so far.
What worked for us was deciding the feature wasn't worth the trust cost and cutting it. Money Me doesn't connect to banks at all, you enter income and bills yourself. More effort for the user, and we lose the automatic wow moment, but there's no scary permission screen to explain, so the trust conversation mostly goes away.
That doesn't directly help you since Accessibility is the whole point of ScriptTap. But it made me think the first question is sometimes "is this capability worth what it costs in trust" before "how do I word the prompt". For a permission you actually need, your short version is solid. Naming it as powerful and handing the decision to the user beats soft-pedaling it. I'd surface it in context, right when the first script needs it, with one concrete example of what it will and won't touch.
App I mentioned, if useful: https://play.google.com/store/apps/details?id=com.moneyme.twa&referrer=utm_source%3Ddevto%26utm_medium%3Dreferral
Thanks, this is a really useful distinction.
“Is this capability worth the trust cost?” is probably the question I need to keep in front of me before polishing the wording.
For ScriptTap, Accessibility is hard to cut or defer because it is part of the product shape, not a side feature. The app is intentionally not just a normal full-screen app. Its main control surface is a floating control layer over the app the user is automating, so the user can keep the target app visible and still start, stop, and control the workflow.
That floating control plane, plus user-authored taps/swipes/actions, depends on Accessibility.
So I cannot honestly wait until the first script runs to explain it. It has to be explained up front, but I think your concrete-example point still applies:
That feels like the right direction: not softer copy, but more specific copy.
