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 asks iOS to do the blocking on its behalf, through three frameworks Apple shipped in 2021 and has extended in small steps since.

That detail decides what your blocker can do, what it will never do however much you pay, and exactly how you get out, which is the part nobody puts in the App Store screenshots.

What actually blocks an app on an iPhone?

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

In a real app the sequence 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 iOS wake your DeviceActivityMonitor extension at interval boundaries and usage thresholds so it can change the store.

Two practical limits keep the category smaller than it looks. 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” happens at moments Apple chooses.

Why the blocker never learns which apps you picked

Of all the design decisions in the API, this one has the biggest consequences.

The app-selection UI is FamilyActivityPicker, and it belongs to Apple, not the developer. It renders out of process, it lists your installed apps, and it returns 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, which it hands back to ManagedSettings to raise a shield. It never receives a bundle identifier or a display name, and there is no way to reverse the token. A token also means something only 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.

For privacy this means a screen-time app physically cannot log that you blocked Grindr, or Robinhood, or your ex’s favourite app. It hasn’t promised not to; it is unable to. That is privacy by construction, and the strongest such guarantee in any category I have shipped into.

For the product it is a real 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, so support requests (“it isn’t blocking anything”) turn into guided screenshot sessions.

Apple made that trade, not the developer, and I think it made the right one.

Which approach blocks what?

Five approaches get sold as “app blocking”, and they intercept at completely different layers. Price matters less here than where each one sits in the stack.

Two notes on that table. A DNS filter is the only row that touches apps you did not list, which makes it 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, with 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 fixes the wrong half of the loop, and a Focus mode is the better tool, or the two 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 uses a different mechanism there.

Is there an app blocker that cannot be bypassed?

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

There is always a way out. The useful question is how long it takes and whether the effort lands somewhere useful. Here is the ladder, cheapest first.

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

Read down that ladder and “unbypassable” stops meaning anything. What varies 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: a cost you set yourself, inside the software, is a cost your craving can renegotiate in the middle of the craving. The API facts above make the same argument at the level of the platform. Revocation is always about fifteen seconds away, so the wall is not the product. The price is.

And the price should be paid somewhere your future self benefits. Waiting 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.

The other designs are not wrong for that. Several are good for problems mine does not solve:

one sec interrupts before the app opens, with a breath, a pause or a question. If your thumb arrives before your intention does, that suits you better than a hard gate, because it targets the reflex. A gate you have already earned your way 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 instead of software you authorised. The cost is 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 being free is a real advantage that EarnLock’s $19.99 lifetime 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 and does nothing Apple does not publish. What it changes is the price: the apps you pick stay locked until you reach a daily activity goal read from Apple Health (steps on the free tier, active minutes or active calories with Premium). Halfway to the goal opens them for an hour, and the full goal opens them until midnight. Its shield replaces Apple’s generic restriction screen with the number that’s left. 2,026 steps until unlock tells you where you’re going; This app has been restricted just stops you. With Premium, the Apple Watch app reads its own Health data and shows how far you are from unlocking, while the iPhone does the locking. Which number to set is its own question, covered in what the step-count studies support. Locking one app is free; Premium is $1.99/month, $9.99/year, or $19.99 once.

EarnLock has the same constraints as everything else on this page. It cannot see which apps you blocked either. It does not stop notifications. It is an iPhone app, with an Apple Watch app in Premium, and has no iPad or Mac version. It has one math-gated emergency unlock per day, on purpose, because people delete a tool with no exit. And if you open Settings and revoke its authorisation, every shield drops and it can do nothing about that. The same is true of every Family Controls app named on this page, and worth knowing before you pay any of us. (The data rules behind that, and behind every other Lagerland app, are 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. The same rule stops it from pre-filling 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. What varies 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.