How Apple's Screen Time API (FamilyControls) Works: The Ultimate Privacy-First Guide

For years, building an app blocker on iOS was a developer's nightmare. Because iOS strictly sandboxes third-party applications from interacting with each other, early blockers had to rely on cumbersome local VPN configurations, Enterprise MDM (Mobile Device Management) profiles, or fake DNS servers. All of these approaches raised serious privacy, battery, and stability concerns.

That changed dramatically with the introduction and maturation of Apple's official Screen Time API suite: FamilyControls, ManagedSettings, and DeviceActivity. Here is a technical and architectural breakdown of how modern iOS app blocking works and why it offers mathematical privacy guarantees.

The 3 Pillars of Apple's Screen Time Architecture

Modern iOS app blocking is split cleanly into three specialized system frameworks:

Pillar 1: FamilyControls and Opaque Tokens

When you open Bullseye and tap Choose Apps, you are not viewing a custom list rendered by Yaysoft. You are interacting with an out-of-process system sheet rendered directly by iOS (FamilyActivityPicker).

When you select Instagram, TikTok, or YouTube, iOS does not hand the bundle identifier (e.g. com.burbn.instagram) to the developer. Instead, Apple provides an opaque, cryptographically sealed data structure called an ApplicationToken.

To Bullseye's Swift codebase, this token is merely a string of random bytes. The developer cannot decrypt it, cannot reverse-engineer what app it represents, and cannot upload your app list to an analytics server. Only Apple's operating system kernel holds the private decryption key.

Pillar 2: ManagedSettings and Kernel-Level Shields

When you start a session in Bullseye, the app passes your opaque tokens to a ManagedSettingsStore:

let store = ManagedSettingsStore()
store.shield.applications = selectedAppTokens
store.shield.webDomains = selectedWebDomainTokens

The moment this property is set, iOS's internal ManagedSettings daemon takes over. When you attempt to open an app associated with that token, the operating system intervenes before the app process launches, presenting a secure shield view controller.

Because the shield is handled by the operating system, it works completely offline, survives device restarts, and requires zero background battery power.

Pillar 3: DeviceActivity (Automated Schedules)

To run schedules that turn on automatically at 9:00 AM or 10:00 PM without requiring the app to run in the background, Bullseye registers a DeviceActivitySchedule with iOS. When the clock hits your scheduled start time, iOS wakes up Bullseye's lightweight DeviceActivityMonitor extension for a fraction of a second to apply the shield store, and puts the extension right back to sleep.

The Privacy Guarantee

Because Bullseye adheres strictly to this architecture:

• We never know which apps or websites you pause.
• We never know how much total screen time you log.
• We never route your network packets through an external server.
• All preferences stay in your device's private sandbox container.