How do app blockers work?

An app blocker works by sitting between you and the app you're trying to open, and using whatever access the operating system grants it to either stop that app from launching or make it cost something before it does. On iOS, that access comes almost entirely through Apple's own Screen Time framework — third-party apps don't get to silently kill other processes, so anything calling itself a blocker on an iPhone is really just a front end for the same App Limits and Communication Limits Apple already ships. On Android, the OS is more permissive: an app can request Accessibility Service or Usage Access permissions and use those to detect when a blocked app comes to the foreground and immediately cover it with its own screen. The mechanism is different on each platform, but the goal is identical — intercept the open, and decide what happens next.

The two mechanisms, and why they behave differently

On iOS, a third-party blocker typically works by requesting Family Controls / Screen Time authorization, which lets it register a list of apps as "restricted" through Apple's ManagedSettings framework. When you tap a restricted app, iOS itself — not the third-party app — intercepts the launch and shows a Screen Time block screen, because the third-party developer never actually has access to your other apps' data or processes; it can only ask the OS to flag them. This is also why iOS blockers are relatively consistent with each other in how they behave: they're all wrappers around the same underlying system. On Android, a blocker generally uses the Accessibility Service API (designed for screen readers) or Usage Stats API to watch which app is in the foreground, and when it detects a blocked package name, it draws an overlay on top of it before you can interact with the app underneath. This gives Android blockers more flexibility — richer overlays, custom unlock flows like a quiz — but also more fragility, since accessibility permissions can be revoked in Settings by the same person the blocker is meant to be stopping. This split also explains a common complaint about iOS blockers specifically — that many of them look and feel similar to one another despite being made by different companies — since they're all constrained by the same limited set of hooks Apple exposes, rather than each building a genuinely independent blocking mechanism from scratch.

What actually determines whether a block holds

The strength of any app blocker comes down to one question: who controls the off switch? A blocker that lives entirely within the same account as the person it's blocking — no separate passcode, no second device, no other person holding the key — is, mechanically, always reversible by that same person, because the OS has to let an app's own settings be changed by whoever's using the phone. Apple's Screen Time is the clearest illustration of this: set without a separate Screen Time passcode, App Limits can be turned off in Settings in under thirty seconds by the same person they're meant to restrict. Add a passcode a different person holds — the parent/child Family Sharing setup Screen Time is built around — and the mechanics don't change, but the party who can reverse the block does, and that's the entire difference between a restriction and a suggestion. This is also the reason "how strong is this blocker" is a slightly misleading question; the framework underneath most blockers on a given platform is largely the same. What varies is what stands between the block and the tap that would lift it — nothing, a countdown, a typed code, or something that requires actual effort. It's worth being clear that this isn't a flaw specific to any one app; it's a structural property of any tool built to run on a device the same person both owns and is trying to restrict, which is true of essentially every consumer app blocker on the market, not just the weaker ones.

Where friction fits into the mechanism

Because the underlying block-or-don't-block mechanism is largely fixed by the OS, the meaningful design choice most blockers make is what happens at the moment of unlock. A timer-based unlock (wait five minutes) adds delay but no effort. A typed-code unlock (retrieve a code from another device) adds a small logistical hurdle. A cognitive-effort unlock — answering a real question, doing a set of push-ups verified by the phone's motion sensor — adds something closer to the discomfort of the task you're avoiding in the first place, which is a meaningfully different kind of friction than simply waiting. None of these change whether the underlying OS permission can technically be revoked; they change how much the person doing the revoking has to want it in that specific moment, which behavioral researchers studying compulsive phone use (sometimes termed "problematic smartphone use" in the academic literature, since no formal DSM-5 diagnosis for phone addiction exists) generally treat as the more relevant lever than raw restriction strength, since willpower fluctuates but a consistent cost doesn't. It's also worth noting that friction and hard technical restriction aren't competing approaches so much as they sit on a spectrum — a scheduled Downtime with no passcode is weak on both axes, a passcode-protected limit is strong on the technical axis but offers no friction if the passcode is known, and a quiz-based unlock is comparatively weak on the technical axis (nothing stops uninstalling the app entirely) but strong on requiring active, effortful engagement in the specific moment that matters.

Where Mr. Grummel fits

Mr. Grummel uses the effort-based version of this mechanism: instead of a timer or a typed code, getting past a block means answering a real quiz question correctly. It doesn't attempt to be a harder technical lock than the OS permits — no app fully is, without a second person holding a passcode — it's designed around raising the cognitive cost of the moment you'd otherwise tap straight through. That design choice reflects a specific bet: that for most people, most of the time, the problem isn't a technically unbreakable lock being needed, it's a costless override being too easy to reach for.