iOS Screen Time & Family Controls Developer

What the Screen Time API actually is

Apple exposes app blocking through three frameworks that only work together. FamilyControls gets permission and hands you opaque tokens instead of bundle IDs. ManagedSettings applies the shield. DeviceActivity runs the schedules and thresholds that decide when.

The tokens are the part people trip over. You never learn which app the user picked. You cannot read the name, you cannot read the icon, you cannot log it to your backend. That is deliberate, and it means the usual analytics and debugging habits do not apply. Anything you want to know about a blocked app has to be derived on the device.

The parts that are genuinely hard

Getting the entitlement. Family Controls is a restricted entitlement. You submit a request explaining the use case and Apple reviews it by hand. Vague answers get refused. I have been through this approval six times, and the request that gets approved reads like a product spec, not a form.

The extension sandbox. DeviceActivityMonitor and ShieldConfiguration run in separate extensions with tight memory limits and no debugger worth the name. They wake, do a small amount of work, and die. Shared state goes through an App Group, and anything expensive gets you terminated mid-callback.

Shields that fire late, or not at all. Most bug reports here trace back to threshold events being coalesced, a monitor never restarting after reboot, or a schedule crossing midnight in the wrong time zone. Understanding the difference is the whole job.

Review. Screen Time apps get scrutinised harder than average, particularly around 5.1.1 and anything that reads as surveillance. Writing the submission so the reviewer understands the intent up front saves weeks.

Beyond the standard block screen

ShieldConfiguration lets you replace Apple's grey shield with your own, and that is where most of the product lives. I have built a shield that shows a snail whose health improves the less you scroll, a lockdown armed by physically tapping an NFC tag, and a shield tied to daylight exposure so a screen limit lifts once you have actually been outside.

The mechanics are the easy half. The hard half is making a limit feel like something the user chose rather than a punishment, because the ones that feel punitive get uninstalled in a week.

Shipped, not theoretical

• Shelly

  Gamified screen time. Apple approved the Family Controls entitlement by hand; shields are drawn with ShieldConfiguration and usage thresholds fire through DeviceActivityMonitor.

• Block

  Tap the phone on a physical NFC tag and the distracting apps disappear. Tap again to bring them back. Core NFC starts the session, Family Controls enforces it.

• Bright Start

  A circadian reset where the screen limit lifts only after the camera and light sensor confirm real daylight exposure.

• Chapter

  Habit replacement. Rather than only blocking, it substitutes the blocked moment with something else and tracks the streak.

Questions people actually ask

Can you get the Family Controls entitlement approved for my app?

I can write and submit the request, and I have had it approved six times. Approval is Apple's decision, not mine, so nobody can promise it. What I can say is that refusals almost always come from a vague use case, and the fix is describing exactly what the app does, who it is for, and what data never leaves the device.

Can the app see which apps a user blocked?

No. FamilyControls returns opaque tokens, not bundle identifiers. You cannot read the name or icon of a selected app, and you cannot send that selection to a server. Any product idea that depends on knowing which specific apps a user picked needs rethinking before development starts.

Does this work on Android too?

Not with these frameworks. Screen Time is Apple-only. Android has its own APIs with different rules and a different permission model. If you need both, they are two builds, and pretending otherwise is how timelines slip.

Why does my shield sometimes appear late?

Usually the DeviceActivityMonitor extension was terminated or the threshold event was coalesced by the system. Occasionally it is a schedule crossing midnight in a time zone you did not test. It is nearly always diagnosable, but it needs on-device testing rather than the simulator.

Can you fix an existing Screen Time app rather than build a new one?

Yes, and that is most of the work people bring me. Shields not firing, monitors dying after reboot, an entitlement request that keeps getting refused, or a rejection at review. A fixed-scope diagnosis first is usually cheaper for you than an open-ended engagement.