BlockMyself
Allowlist mode

Stop listing what is bad.

Category filters try to name everything you should not reach, and there is always something they have not named yet. An allowlist inverts the problem: nothing is reachable unless it is on the list. It is the strongest block built into iPhone and iPad, and it is the only built-in setting that reliably reaches web pages opened inside other apps.

Fails closed Covers in-app browsers High daily friction

Why an allowlist is different in kind

Every other layer on this site is a blocklist. It works by recognising something as belonging to a category you have blocked. That is a losing race in one specific way: a site whose only purpose is to relay you somewhere else is not itself in the category, so it is not blocked, and reaching it takes one search.

An allowlist does not play that game. There is no category to evade, because the question is never "is this bad?" It is "is this on the list?" Anything not on the list fails, including things nobody has ever categorised, things created this morning, and things whose whole purpose is to be uncategorised. That is what "fails closed" means, and it is why allowlist mode is qualitatively stronger rather than incrementally stronger.

The cost is exactly proportional to the benefit. A setup that blocks everything you did not anticipate will also block a great deal you did not anticipate needing. Read the honesty section below before you turn this on.

The reason this matters most: in-app browsers

Web pages opened inside other apps are the weakest point in most iPhone setups, and allowlist mode is the built-in answer to them.

When you tap a link inside an app, the page usually opens inside that app rather than handing you to Safari. Two things follow from that, and both matter.

It is largely invisible to history review

Pages opened inside another app are not written to Safari's history in the way ordinary browsing is. If your accountability arrangement is built on someone reviewing Safari history, that review does not see this activity. The record is partial in a way that looks complete.

But it is still filtered

The good news, and the reason this page exists: Apple's web content filter does not live inside Safari. It runs underneath, in the shared system component that loads web pages for every app. So the filter applies to in-app browser views too, and that includes allowlist mode.

Put those two facts together and you get the practical rule. On iPhone and iPad, you cannot rely on seeing what happened inside another app's browser, but you can rely on restricting it. That asymmetry is the argument for allowlist mode over a history-based arrangement: it does not depend on anyone noticing after the fact, because the thing simply does not load. If you want visibility as well, that has to come from outside the device, which is covered in Accountability.
What allowlist mode still does not cover.

It closes the large majority of in-app browsing, not all of it. Apps that build their own browser from scratch, rather than using the system component, are outside this filter entirely. The filter also checks the page being loaded rather than every individual element inside an already-allowed page, and it applies to normal web traffic rather than to every kind of connection an app might make. And in the EU, apps using an alternative browser engine are responsible for enforcing the filter themselves, which shifts the guarantee from Apple to that vendor.

So the honest summary is: allowlist mode makes casual in-app access fail, and it is the strongest built-in tool for that. It is not a sealed box, and the apps most likely to fall outside it are the ones worth asking whether you want on the device at all.

Turn it on: iPhone and iPad

Set the passcode first

Do this before anything else. Every restriction below is undone in seconds by anyone who can open Screen Time, and Apple treats the passcode as an optional extra step rather than part of setup.

  1. Open Settings -> Screen Time.
  2. Tap Lock Screen Time Settings.
  3. Have the trusted person enter a passcode you do not know.
  4. At the Screen Time Passcode Recovery prompt, skip it or use the trusted person's Apple Account. Never your own. See Lockout for why this single prompt decides whether the whole arrangement holds.
Switch to Only Approved Websites
  1. Open Settings -> Screen Time -> Content & Privacy Restrictions.
  2. Turn Content & Privacy Restrictions on.
  3. Tap App Store, Media, Web, & Games, then Web Content.
  4. Choose Only Approved Websites.
  5. Review the default list Apple provides and remove anything you do not need.
  6. Tap Add Website for each site you genuinely need, entering the title and URL.
  7. Have the trusted person enter the passcode to confirm, then hand the phone back.

Build the list from what you actually used in the last week rather than from imagination. Check your own recent history, bank, transit, work tools, and the handful of sites you open daily. Expect to have missed several, and expect that to be revealing.

Close the obvious edges
  1. Set Installing Apps and App Marketplaces to Don't Allow, so a browser or app with its own browser cannot be added.
  2. Set Account Changes, Passcode Changes, and Cellular Data Changes to Don't Allow.
  3. Remove browsers and apps you do not need rather than relying on the filter to police them.
  4. Add a filtering DNS profile as a second, independent layer that also works on cellular.
Turning Safari off under Allowed Apps is not a substitute for any of this. It hides the icon; in-app browser views keep working exactly as before. The Web Content setting is the one that reaches them.

Turn it on: Mac

The same feature exists on macOS under a different name, and with one limitation serious enough that you should not assume Mac parity with iPhone.

  1. Open System Settings -> Screen Time -> Content & Privacy.
  2. Open App Store, Media, Web, & Games and find the Safari section.
  3. Choose Allowed Websites Only. Note the different wording from iPhone.
  4. Click Add below the list and enter both a title and a URL for each allowed site. macOS requires both.
  5. Turn on Lock Screen Time Settings with a passcode the trusted person holds.
On a Mac this only covers Safari.

Unlike iPhone, the macOS filter is something each browser has to opt into, and only Safari does. Chrome, Firefox, Edge, and Brave ignore it completely, as do web views inside other Mac apps. A standard account cannot stop you installing one of those browsers either, because a Mac lets you run an app straight from your home folder without an admin password.

So on macOS, allowlist mode is only meaningful if Safari is genuinely the only browser on the machine and you are not working around it. If a Mac is where the real problem lives, the layers that actually hold are DNS filtering, router enforcement, and browser policy applied to every browser you keep. See Mac Guardrails.

How the accountability works in this mode

Allowlist mode changes what the trusted person reviews. Instead of reading a history of where you went, they review the list of where you are permitted to go, and they hold the passcode that changes it.

  1. Additions require them, in person or on a call. This is the mechanism. A site you want badly at eleven at night is a site you have to ask for, out loud, to someone who knows why the arrangement exists.
  2. Review the list itself on a schedule, monthly is reasonable. The list only grows, and a list that has quietly doubled is worth a conversation on its own.
  3. Watch for broad entries. One overly general entry can undo the whole design far more effectively than a dozen specific ones. If an entry would let almost anything through, treat it the way you would treat turning the setting off.
  4. Do not treat the absence of history as evidence of anything. In this mode the useful signal is the shape of the allowed list and whether the restriction is still on, not the browser history.
  5. Pair it with an outside record if you want visibility as well as restriction. Restriction and visibility are different jobs; see Accountability.

Be honest about the cost

Most people who turn this on turn it off again within a fortnight, and it is worth knowing why before you start rather than discovering it as a failure.

What breaks

  • Links people send you, constantly.
  • Sign-in flows that redirect through a domain you never see.
  • Maps, receipts, tickets, delivery tracking, and password resets.
  • Anything embedded in a page you allowed but served from somewhere you did not.
  • Work tasks you had not thought of, usually at the worst moment.

What makes it survivable

  • Spending a real half hour building the initial list.
  • A trusted person who is genuinely reachable, not a token one.
  • Agreeing a fast path for legitimate work needs.
  • Treating the first fortnight as tuning rather than as a verdict.
  • Keeping a second unrestricted device for work, if that is honest and not a loophole.
Do not use this on a device you need in an emergency without a documented way through.

Medical, banking, travel, and safety access must have a path that does not depend on reaching one person at three in the morning. Add those sites at setup, before you need them. A block that endangers you is not a strong setup, it is a badly designed one.

If allowlist mode is too much for daily life, that is a normal outcome and not a failure. The alternative is not "give up": it is category filtering plus a hardened DNS layer plus a record someone else holds. That combination is less absolute and much easier to keep running for a year, and a setup you keep beats a stricter one you abandon.

Where to go next

Accountability

Make the record complete when restriction alone is not the whole answer.

Harden the DNS layer

Block proxies, VPNs, and newly registered domains at the network level.

Test your setup

Confirm in-app browsers, cellular, and other browsers behave as you expect.

Use these when you need a checklist, a specific bypass closed, or a clearer handoff plan.

Guardrails

Built-in controls and exact menus for each device.

Friction

DNS filters, browser policy, hosts files, and router rules.

Lockout

Trusted-person handoff, admin separation, and recovery control.

Trusted person

Who holds what, and the rules you agree in advance.

Apps and platforms

Search, YouTube, social apps, app stores, TVs, and in-app browsers.

Mobile data

Close cellular, Private DNS, VPN, and hotspot gaps.

Urge plan

What to do before trying to bypass.

Trusted handoff worksheet

Printable inventory for passcodes, recovery paths, and refusal rules.

Glossary

Plain-language definitions for DNS, DoH, VPNs, MDM, recovery keys, and more.