SelfControl: a macOS blocker you cannot switch off until the timer ends

The commitment device problem SelfControl targets

Most site blockers fail at the same moment: the moment you want the site back. A browser extension can be toggled off in two clicks, a hosts file can be edited, and a parental-control tool usually has an admin password that the person who set it also knows. SelfControl takes the opposite position. The README states that until the timer expires you will be unable to access the blocked sites, even if you restart your computer or delete the application. That sentence is the product.

The audience is therefore narrow and specific. It is a single macOS user blocking their own access to distracting websites and mail servers for a predetermined period. It is not a parental-control product for managing someone else's behaviour, and it is not an enterprise web filter. The README frames the target as your own access, and the blocklist is whatever you type into it, so mail servers and any other host on the Internet are in scope alongside social sites.

The design assumes you are the adversary. That is an unusual threat model for a desktop utility, and it explains why the repository contains components that a normal blocker would not need.

How the block survives a restart and an uninstall

The repository layout shows an app split across several pieces rather than one monolithic binary. AppController.m and the window controllers handle the interface, Block Management/ holds the blocklist logic, and two directories stand out: Daemon/ and SelfControl Killer/. There is also SCKillerHelper/ and a LaunchctlHelper class, which points at launchd as the mechanism that keeps the block alive independently of the foreground app.

The README does not document the internal sequence, so the exact ordering of daemon installation, hosts-file or firewall changes, and cleanup on expiry cannot be confirmed from it. What can be confirmed is the user-visible contract: the timer is authoritative, and restarting the machine does not clear the block. A helper that runs under launchd is the conventional way to get that behaviour on macOS, and the presence of LaunchctlHelper.h alongside the Daemon directory is consistent with it.

SelfControl Killer/ is the more interesting name. A block that cannot be removed by the app itself still has to end somehow, and a separate component responsible for ending it fits the architecture. The README is silent on how that component is protected, which is the first thing a technically curious user should look at before trusting the timer.

Installing SelfControl on macOS

The README is explicit that ordinary users should always download the latest version from the project website rather than build from source. The build instructions exist for contributors, and they state that building can only be done on a Mac running a modern version of macOS.

The contributor path starts by cloning the repository and installing CocoaPods, the dependency manager the project uses. This command installs it system-wide:

sudo gem install cocoapods

From the root of the cloned repository, the dependencies are resolved with CocoaPods. The README gives the command without arguments:

pod install

The step that trips people up is which file to open afterwards. The README says to open the workspace, not the project file, and calls this out in capitals. Opening the wrong one produces build errors that look unrelated to the mistake:

open selfcontrol.xcworkspace

After that, build and run from Xcode. The README warns that you may need to update or remove code signing settings to make it build properly, which is a normal obstacle for an Objective-C project that ships a daemon and helper tools. For a first real use, the workflow described in the README is short: set a period of time to block for, add sites to your blocklist, and click Start Block. The screenshot in the repository shows the blocklist window, and DomainListWindowController.m is the code behind that list.

Where SelfControl is the wrong tool

The same property that makes SelfControl work makes it unsuitable for a lot of situations. If you need to lift a block because a legitimate work task depends on a domain you added in a hurry, the README offers no escape hatch: the timer runs out or you wait. There is no documented override, and the README does not describe an administrative bypass.

It is macOS only. The README describes a Mac app built with Xcode and CocoaPods, and nothing in the repository suggests a supported path to Windows or Linux. Anyone searching for a Windows or Android equivalent is looking for a different project, not a port of this one.

It is also a poor fit for shared machines. The block is aimed at your own access, so a household or lab computer where several people need different blocklists is the wrong shape. And because the blocklist is a flat list of domains and hosts, it does not express categories, schedules, or per-app rules. If your requirement is policy rather than commitment, a content filter is the correct category of tool.

A practical limitation worth naming: the README does not document rollback, so if a build or a block behaves unexpectedly, the documentation is silent on the recovery procedure. That absence is itself information.

SelfControl compared with hosts-file and filter approaches

The closest alternative in spirit is editing /etc/hosts yourself, or using a small script that rewrites it on a schedule. The difference is enforcement. A hosts entry is trivially reversible by anyone with sudo, and the person who wrote the entry is usually the person with sudo. SelfControl's value is that it removes that option for the duration, which is why it ships a daemon and a separate killer component instead of a single preference pane.

The other comparison is a managed content filter, the kind deployed by schools and employers. Those tools are built for a different problem: an administrator sets policy for many users, and the user is not expected to be able to override it. They bring logging, reporting, and central configuration. SelfControl has none of that, and the README does not claim otherwise. Choosing between them is really choosing whether you are the administrator or the subject.

There is also the browser-extension category, which is the lightest option and the easiest to defeat. Extensions can be disabled per profile, and the disable action is one click. SelfControl's README makes the contrast explicit by promising the block holds through a restart and an uninstall, which no extension can promise.

Licence, maintenance and what a fork costs you

SelfControl is released under the GPL, with the full text in the COPYING file at the repository root. The practical consequence for anyone modifying and redistributing it is that the GPL's source-availability terms travel with the binary. This is not legal advice, and the specific obligations depend on how you distribute, but a team that plans to ship a rebranded build should read COPYING before writing code.

The repository is not archived, and the last push was on 2026-06-26. That is recent enough that the project is not abandoned, but the README does not describe a release cadence, and no recent releases were retrieved, so there is no published version history to plan upgrades against. Users are told to download the latest version from the project website, which means upgrades arrive through that channel rather than through a package manager or an app store.

For a contributor, the upgrade cost is mostly toolchain drift. The build depends on Xcode, the Xcode command-line tools, and CocoaPods, and the README notes that code signing settings may need adjustment. A project that ships a launchd daemon and a helper tool also has to keep those components signed and compatible with each new macOS release, which is ongoing work rather than a one-time setup. SelfControl is available in 12 languages according to the README, with translators credited on the project wiki, so a fork that changes user-facing strings inherits that translation surface too.

Editorial conclusion

SelfControl is for macOS users who want a commitment device rather than a filter they administer: you set a timer, add domains, and the README states you cannot undo it by restarting or deleting the app. It is the wrong tool if you need per-user policies across a fleet, a Windows or Android blocker, or a schedule you can edit mid-block. Before adopting it, verify your macOS and Xcode versions against the build steps, confirm the GPL-3.0 terms fit how you intend to redistribute any modified build, and read the daemon and killer components under Daemon/ and SelfControl Killer/ to understand what the app installs alongside the main bundle.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. SelfControlApp/selfcontrol on GitHub