What an iPhone app can actually block, and what it structurally cannot

Ask most people how an app blocker works on iPhone and you get some version of this: the blocker sits in the background, watches what you open, and slams a door when it spots Instagram.

None of that is possible. A third-party iOS app cannot see which apps you launch, cannot run continuously in the background to watch for one, and cannot draw a single pixel over another app. Every blocker on the App Store works by asking iOS to do the blocking on its behalf, through three frameworks Apple shipped in 2021 and has extended in small increments since.

That distinction is not pedantry. It decides what your blocker can do, what it will never do no matter how much you pay, and — the part nobody puts in the App Store screenshots — exactly how you get out.

What actually blocks an app on an iPhone?

Three frameworks, collectively the Screen Time API, introduced in the WWDC21 session Meet the Screen Time API. A fourth, ManagedSettingsUI, only controls how the blocking screen looks.

The sequence in a real app is short. Ask for authorisation through AuthorizationCenter.shared, in .individual mode for self-restriction or .child mode for a Family Sharing parent. Present the picker. Put whatever came back into a ManagedSettingsStore as store.shield.applications. Register a schedule with DeviceActivityCenter, and let your DeviceActivityMonitor extension get woken at interval boundaries and usage thresholds to change the store.

Two practical gates are worth knowing before you assume the category is bigger than it is. The Family Controls capability adds the com.apple.developer.family-controls entitlement, and distributing it on the App Store requires asking Apple for it. And the DeviceActivityMonitor extension is not a daemon: iOS wakes it, gives it a short slice of time, and suspends it. Anything a blocker claims to do “continuously” is really doing it at Apple’s chosen moments.

Why the blocker never learns which apps you picked

This is the single most consequential design decision in the whole API.

The app-selection UI is FamilyActivityPicker, and it is Apple’s, not the developer’s. It renders out of process, it lists your installed apps, and what it returns is a FamilyActivitySelection containing sets of tokens: ApplicationToken, ActivityCategoryToken, WebDomainToken. Apple’s documentation for Token describes it as a representation of an app or website “that doesn’t reveal its identity,” and the ApplicationToken page says the point is to restrict and filter apps without access to personal user data.

So a blocker holds an opaque blob. It hands that blob back to ManagedSettings to raise a shield. It never receives a bundle identifier or a display name. There is no way to reverse it. A token is also only meaningful to the app that received it, and it stops working the moment you revoke authorisation in Settings, because revocation invalidates the app’s tokens along with its permission.

The privacy consequence is real and worth saying plainly: a screen-time app physically cannot log that you blocked Grindr, or Robinhood, or your ex’s favourite app. Not “promises not to” — cannot. That is privacy by construction, and the strongest such guarantee in any category I have shipped into.

The product consequence is a genuine tax, and every developer in this category pays it:

• You cannot offer a one-tap “block the usual suspects” onboarding, because you cannot name the suspects.
• You cannot tell the user, in your own copy, which apps are currently shielded.
• You cannot verify from your own data that a user selected anything at all, which makes support (“it isn’t blocking anything”) an exercise in guided screenshots.

That trade is Apple’s to make, not the developer’s. I think it is the right one.

Which approach blocks what?

Five approaches get sold as “app blocking”, and they intercept at completely different layers. The column that matters is not price, it is where each one sits in the stack.

Two honest notes on that table. A DNS filter is the only row that touches apps you did not enumerate, which is why it is the right tool for adult-content blocking and the wrong tool for “keep me off X between 9 and 5.” And Apple’s own review rules constrain the VPN row: App Store Review Guideline 5.4 requires VPN apps to use NEVPNManager and to come from a developer enrolled as an organisation, and the content-filter entitlement is granted case by case, which is why so few of these exist.

Can an app block Instagram on iPhone?

Yes. Then three caveats that matter more than the yes.

The app, properly. Select Instagram in the picker, put the token in store.shield.applications, and tapping the icon shows a shield instead of launching the app. The app does not open in the background, does not refresh, does not get its five seconds.

The website, mostly. ShieldSettings.webDomains covers Safari. Selecting web content in the picker is what makes instagram.com in Safari behave the same way as the app. Coverage inside third-party browsers and in-app web views is less predictable, and I would not build a plan around it.

Not the notifications. A shield stops a launch. It does not stop delivery. If a badge and a banner are what pull you in, the shield is fixing the wrong half of the loop, and a Focus mode is the better tool — or both together.

Not your other screens. The store is local to the device. Your iPad, your Mac, and the work laptop are all untouched. Family Controls does not ship on macOS in a form that supports this mechanic, so any shield app that does cover the Mac is doing it with a different mechanism.

Is there an app blocker that cannot be bypassed?

No. Not on a device you own and control, and the reason is deliberate: if a third-party app could permanently restrict your phone, the first malicious app to ship would brick a lot of phones. Apple keeps the exit in your hands on purpose.

So the useful question is not whether there is a way out — there always is. It is how long the way out takes, and whether the effort lands somewhere useful. Here is the actual ladder, cheapest first.

Two rows deserve comment. ApplicationSettings.denyAppRemoval is real: a blocker can prevent app deletion device-wide, which closes the cheapest exit. And revocation is observable — an app can watch its own authorisation status and know the moment you walked out. Whether it should do anything with that, beyond quietly recording it for you, is a design question with an obvious wrong answer.

Read down that ladder and “unbypassable” collapses. The only real variable is how many seconds sit between the impulse and the app, and whether those seconds buy you anything.

What the API reality means for design

I wrote a while ago that the unlock cost has to live outside the app — that a cost you set yourself, inside the software, is a cost your craving can renegotiate from inside the moment of craving. The API reality above is the structural version of the same argument. Since revocation is always about fifteen seconds away, the wall is not the product. The price is.

And the price should be paid somewhere your future self benefits. Time-of-wait fails that test: you pay in attention, which is exactly what you were trying to protect, and you get nothing back. Body movement passes it, because the cost lands in the rest of your life.

That is not the same as saying the other designs are wrong. Several are good for problems mine does not solve:

one sec interrupts before the app opens — a breath, a pause, a question. If your problem is that your thumb arrives before your intention does, that is a better-shaped intervention than a hard gate, because the reflex is what it targets. A gate you have already earned past does nothing about a reflex. one sec also runs on Android, which nothing of ours does.

Brick puts a physical NFC tag in the loop, around $59 one time. Leaving the tag at home is a commitment you cannot undo from the couch, and it is the only design in the category where the friction is made of atoms rather than software you authorised. The cost is that you have an object to buy, carry, and lose. Unpluq works on the same physical principle, paired with a subscription.

ScreenZen is free, with escalating pauses, and free is a real advantage that a $19.99 tier does not erase. Opal and Jomo are more polished than we are, and Jomo covers iPhone, iPad, and Mac.

EarnLock uses exactly the same three frameworks as all of them. It is not doing anything Apple does not publish. What it changes is the price: your selected apps stay shielded until you hit a daily activity goal read from Apple Health — steps in the free tier, active minutes or active energy in Premium — and the shield is a ShieldConfiguration extension that paints a live progress ring with the number remaining instead of Apple’s generic restriction screen. 3,412 steps until unlock is a destination. This app has been restricted is a wall. The Apple Watch app reads HealthKit on the wrist, so the count keeps running on a walk without the phone. $1.99/month, $9.99/year, or $19.99 once, each price checked in August 2026.

The honest constraints are the same ones on this page. EarnLock cannot see which apps you blocked either. It does not stop notifications. It is iPhone and Apple Watch only, and there is no iPad or Mac version because the framework does not support the mechanic there. It ships one math-gated emergency unlock per day, on purpose, because a tool with no exit is a tool people delete. And if you open Settings and revoke its authorisation, every shield drops and there is nothing it can do about that — which is true of every Family Controls app named on this page, and worth knowing before you pay any of us. (The data discipline behind that, and every other Lagerland app, is on the transparency page.)

TL;DR

• No third-party iPhone app blocks anything itself. It asks iOS to, via FamilyControls (permission and the picker), ManagedSettings (the shield), and DeviceActivity (schedules and thresholds).
• The picker returns opaque tokens, not app names. Your blocker cannot log, sell, or leak which apps you chose, because iOS never gives it the names — and it also cannot pre-fill a recommended list for you.
• A shield blocks launching, not notifying. It covers the app and, via web domains, Safari. It does not cover your iPad, your Mac, or the banner that pulled you in.
• Nothing is unbypassable, by Apple’s design. Revoking Family Controls in Settings takes about fifteen seconds and voids every shield at once. denyAppRemoval closes the cheapest exit; nothing closes the last one.
• So compare the price, not the wall. The only real variable is what stands between the impulse and the app — a tap, a wait, a physical tag, or a step count — and whether paying it leaves you better off.