App blocking
An app blocker that will not pretend it is blocking
Most app blockers are defeated in about four seconds. The interesting design questions are all about what happens after that.
How does Crescendo block apps?
Crescendo's app blocker restricts a list of apps you choose during scheduled windows, releasing them only for a fixed period when an unlock is earned — 15 minutes by default, up to 3 times per day. You may select up to 100 apps. The policy is enforced server-side today, but the native client that would restrict apps on a phone has not shipped, so nothing is being blocked yet.
The privacy constraint the feature is built around
There is no endpoint anywhere that accepts a list of the apps installed on your device. That is structural, not a promise: a client that enumerated your launcher and tried to upload the result would have nowhere to send it.
This matters more than it first appears. Which apps a person has is the most sensitive thing a blocker is in a position to learn — it reveals health apps, dating apps, apps that identify someone's religion or politics — and the feature does not need it. Restricting an app requires knowing the one app, not the other two hundred. The only write path is a selection you composed yourself, capped at 100 entries.
On iOS the point becomes moot in the user's favour: the system hands back an opaque token rather than an app identifier, so even the selected app is unnamed to us.
What is actually built
The policy engine, with modes, schedule windows, timezone and clock-change handling. The unlock system, with a duration per unlock, a daily limit counted against your local day, and grants that expire by comparison rather than by a job that could fail to run. The append-only history, which keeps failed and abandoned attempts as well as successful ones. And the permission catalogue a native client reads rather than hard-coding a list that will drift the first time an OS release moves something.
There is also a strict mode, which is a promise the client makes rather than one the server can enforce: when it cannot verify the current state — no network, permission revoked — it keeps blocking rather than failing open. The server does not pretend it can guarantee this, and says so.
What is not built, and why
The enforcer. Restricting an app requires platform APIs with no browser-reachable equivalent, and this repository contains a web app and a server — no Android project, no iOS project. A service worker intercepts requests the browser itself makes and nothing else; it cannot see which app is in the foreground on a phone.
The platforms are not equal, and the plan does not pretend otherwise. On Android, usage-based detection is the workable approach. The event-driven alternative is technically better and is restricted by Google Play to genuine accessibility use, which app-blocking is not — shipping it as a default is a policy violation with removal as the outcome, so it exists as a fully described adapter that is switched off. On iOS the system-drawn shield is the best implementation of this idea anywhere, and it requires an entitlement Apple grants at its discretion, per app, with no guarantee.
The unlock challenge
An unlock is currently recorded with a reference supplied by the caller — the server takes the client's word that a challenge was completed. That is honest about where it stands and is explicitly not the finished design: verifying completion server-side is a known, documented, breaking change to the contract rather than something to be quietly retrofitted.
Until it is verified server-side, treat the challenge as a speed bump rather than a lock. A speed bump is not nothing — most impulsive opens do not survive one — but it is not what the finished feature will be.
At a glance
- Maximum apps per policy
- 100
- App inventory collected
- None — structurally impossible
- Default unlock duration
- 15 minutes
- Default daily unlock limit
- 3 per local day
- History
- Append-only, includes failed attempts
- Android enforcement
- Designed, not shipped
- iOS enforcement
- Requires an Apple entitlement
- Browser enforcement
- Not possible
Common questions
- Can Crescendo block Instagram or TikTok right now?
- No. You can select the apps, define the schedule and configure the unlock rules today, and the server will correctly report that you are restricted — but no native client exists yet to act on that, so the apps still open. This page says so rather than implying otherwise.
- Does the app see which apps are installed on my phone?
- No, and it cannot. There is no endpoint that accepts an inventory of installed apps, so a client that collected one would have nowhere to send it. Only apps you explicitly select are stored, up to 100, and on iOS even those are opaque tokens rather than names.
- What stops me from just uninstalling the blocker?
- Nothing, and any product claiming otherwise on a phone you control is overstating its case. The realistic goal is to make an impulsive open cost more than the impulse is worth, and to keep an honest record when you go around it — which is why failed and abandoned unlock attempts are kept rather than discarded.
- Why is iOS support uncertain?
- Because iOS does this better than anything else and gates it accordingly. The system draws the shield itself and it cannot be swiped past, but using those APIs requires a distribution entitlement Apple grants case by case, at its discretion, with no guarantee. The data model is built so it never assumes the two platforms are equivalent.
- What happens if I lose network access?
- In strict mode the client is expected to keep blocking rather than failing open. That is a promise made by the client, not something the server can enforce, and it is described that way rather than as a guarantee.
- When will blocking actually work?
- It needs a native client, which is a separate piece of work from everything described here. There is no date on this page because a date that slips is worse than no date. The waitlist is the honest version of an answer.