Every app blocker can be bypassed.
An honest one tells you so

On Monday you install a blocker. On Tuesday it works. By Wednesday you have added an exception. By Thursday you know the sequence for turning it off by heart, and on Friday the app is still on your phone but it no longer blocks anything.

That is not a failure of willpower. The person who sets the lock and the person who removes it are the same person, and both phone platforms allow this on purpose: the phone belongs to its owner, and no app gets to lock the owner out permanently. This page is about what a lock can actually do, what it cannot, and what an honest one looks like.

The moment you install a blocker is a calm one, and you know what you want from it. The moment you want it gone is the opposite. All a lock really does is hold the distance between those two moments — and on its own it cannot hold that distance forever.

On top of that, no app can impose an absolute lock against the owner of the phone. That is not a gap in the products; it is deliberate platform design. If it were otherwise, a malicious app could hold your phone hostage.

So "can it be bypassed" is not the question. It can. The real question is: what happens when it is? A blocker that swallows that quietly is selling you a feeling of safety rather than any protection.

They do not differ by degree, they differ in kind — and choosing a blocker without knowing that is choosing it with the wrong expectations.

iPhone and iPad. Apple's Screen Time framework does the work. You pick the apps in Apple's own picker, and the operating system draws the blocking screen. Here is the part that matters: the app is never told which apps you chose — Apple hands back an unreadable token, not a name. That is Apple's deliberate choice, and it is the right one.

Android. An accessibility service does the work, the selection is made from package names, and the app itself draws the block: open a shielded app and FocusFlow bounces you back to itself. The names never leave the device.

This is why there is no "list of blocked apps" anywhere in FocusFlow. On iOS such a list cannot exist; building one shared model across both platforms would have meant promising something the iPhone side could never deliver.

You turn App Shield on in Settings. On iPhone the system authorization prompt appears, then Apple's app picker. The apps you choose go quiet for the duration of a focus session started on the Focus tab — and come back on their own when it ends.

Because the lock is "these 25 minutes" rather than "from today onwards", there is no surface to negotiate with. You do not argue with a restriction that has a known end time.

In case the app is closed, or even killed by the operating system, a background failsafe window is armed so the shield cannot be left standing. Apple's scheduler refuses any window shorter than fifteen minutes, so that failsafe is rounded up to at least sixteen: firing late is acceptable, because under normal conditions the app lowers its own shield. This window exists for one case only — the app no longer running.

App Shield is free and needs no account. A shield is a focus tool; it does not tell you what to do. As with joining a room, the real work is settled first: breaking the goal into steps.

The guardian generates a six-digit invite code in their own copy of the app and enters it on the child's phone. The code lives for fifteen minutes — because this is a setup that happens with both of you in the same room, not something mailed around. The server stores the code only as a hash, never in the clear.

After that the guardian can raise and lower the shield remotely, for a chosen duration or until they lift it. The system is not a command queue but a desired state: the guardian writes what they want, the child's device converges on it and reports which version it applied. If the device has not caught up, the guardian's screen says "not applied yet" instead of showing the lock as though it were live.

And the part that matters most: when a child does the thing that cannot be prevented — withdrawing Screen Time authorization on iOS, the accessibility permission on Android — the device reports it, and the guardian's screen shows the protection as broken. We cannot stop that. We can say it.

Family Mode requires an account — the only feature that does. On iPhone Apple adds its own condition: a parent in the Family Sharing group must approve Screen Time control on the child's device. While a shield is active only the guardian can remove the link, since otherwise unlinking would be the shortcut to unlocking.

If Family Mode is in use, this is the whole of what sits on the server: the link between the two accounts, the guardian's current wish (on/off, an optional end time, a version counter), and the child device's brief status report — platform, whether the shield is applied, how many apps are selected, whether the protection is intact, and a timestamp.

We never receive which apps were chosen. We collect no usage data, no screen-time reports, no location, and no message or browsing content, from any device. Family Mode data is deleted when the link is removed or the account is deleted.

This paragraph says the same thing as our privacy policy. A marketing page that sounds more optimistic than the policy is the worst thing to trust.