Taqwa Lock: Building an App Blocker That Never Reads What You Type

The short version

Choose the apps that pull you away. When you open one, the app interrupts with a short reflection. Complete it and you get a limited access window for that app, then the pause returns.

No account is required. The protection loop stays available offline. The core loop, the bundled reminders, the privacy controls and the local statistics are never behind a paywall.

The privacy problem at the centre of every blocker

To interrupt someone before a distracting app, you must know which app is in the foreground. On Android the usual route is an accessibility service, and an accessibility service is one of the most powerful permissions the platform offers. It can read view content, observe gestures, capture keystrokes, see URLs, read messages and read form data.

Most blockers take that permission and then promise, in a privacy policy, not to misuse it. That is a promise made in a document about a capability that exists in the binary.

The narrower option

The service here is package-only. It observes which application is in front and nothing else. View content retrieval, gestures, keystrokes, URLs, messages and form data are not accessed at all.

On iOS the equivalent work uses the platform screen-time frameworks: family controls, managed settings, a custom shield extension and a device activity monitor. App selections are handled as opaque tokens, so the app never learns which specific applications the user chose, only that a selection exists to enforce.

The iOS design is a useful illustration of a general point. The platform gave a way to enforce a rule without revealing the data behind it, and taking that route costs some flexibility and removes an entire class of risk.

Content that a model is not allowed to write

The reflection shown during a pause is religious content. The rule is that it is never generated by AI.

Every production entry requires a cleared translation licence, a source locator identifying exactly where it came from, and two independent reviewers. There is a review-gated content schema in the codebase with validation and selection logic, so an unreviewed entry cannot reach a user by accident.

Why build machinery for this

Because a policy that lives only in someone's head is one busy week away from being broken. Encoding review state in the schema means the constraint is enforced by the type system and the validator rather than by everyone remembering.

This generalises well beyond religious text. Any product with medical, legal or financial content has the same shape of problem, and the same answer applies: make the unreviewed state unrepresentable in production.

What stays free, and why that is an engineering decision

The protection loop, the bundled reviewed reminders, the privacy controls and the local statistics are never paywalled. Managed backend, analytics, diagnostics and billing are all optional services, and missing network configuration never disables the offline core.

That is a commercial commitment with an architectural consequence. It means the core cannot depend on a server, which forces local-first storage and a genuine offline path rather than a cached approximation of one.

• Native Android work handles the service and reboot-safe per-app sessions, because a blocker that forgets its state after a restart is trivially defeated.
• iOS extensions cover the shield configuration, the shield action and device activity monitoring.
• Edge functions handle content manifests, review assistance, data deletion and billing webhooks.
• A release preflight verifier fails closed before a production build is produced.

What we would tell you if you were building this

1. Take the narrowest permission that does the job, even when the broader one is easier. You are going to have to explain the permission during store review and to every privacy-conscious user, and narrow is much easier to explain.
2. Encode editorial rules in the schema. If unreviewed content cannot be represented in a production build, nobody has to remember the rule at 11pm before a release.
3. Decide what is never paywalled before you build. It constrains the architecture in useful ways and it stops the free tier from decaying feature by feature.
4. Test the reboot path. Any always-on protection that does not survive a restart provides the appearance of protection only.