Should I vibe code
iPhone and Mac screen-time rules with hardened app blocking
Apple hands you the blocking API, then refuses to let your own app read the usage behind it.
?
Their verdict, the Pro (month-to-month) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The surprise with the iOS half is how much of it Apple will simply hand you. FamilyControls, ManagedSettings and DeviceActivity are public frameworks, the development entitlement is available without asking anyone's permission, and a personal build that shields six apps on a schedule is a genuinely reachable weekend. What you cannot reach is the other half of the product. Apple runs the reporting extension in a sandbox with no network and no way to pass raw usage back into your own app — the design goal was explicitly to stop the host application from learning what you opened — so the Opal Score, the history, the weekly trend and anything you would sync are not features you have not built yet, they are features the platform declines to make possible. That leaves a blocker with no scoreboard, which matters more than it sounds, because the scoreboard is the product. Opal's twenty dollars buys streaks, a difficulty setting that makes quitting annoying, and a distribution entitlement granted per bundle ID that you have to apply for and justify. You are not competing with their engineering. You are competing with their behavioural design, and your version gets deleted in week three.
What actually breaks
not "if". the specific failures.
- The dashboard, permanently. DeviceActivityReport renders inside a sandbox that cannot make a network call or hand data back to your app, so there is no supported route from 'you spent 4h12 in that app' to a chart your own code drew
- Distribution, if you ever want this on someone else's phone — the Family Controls entitlement is requested per bundle ID and again for each Screen Time extension, and an app that fails to sign at submission is not a bug you can debug your way out of
- The scheduler, on the boring inputs: a device restart mid-session, a timezone change on a flight, DST, and a focus window that crosses midnight. Each of those is either no blocking or a phone that will not open its own apps
- The seven-day provisioning expiry, if you build this on a free Apple ID. Your blocker stops blocking every Sunday and you find out by noticing you have been on Instagram
- Sideways blocking, the moment you try to cover Safari and in-app browsers as well as apps. That is where every honest version of this drifts towards a filter or a VPN profile, which is a different and much worse project
- The Mac half, which shares a brand and nothing else — no Screen Time API, no shields, and a rebuild from scratch against whatever macOS is doing to system extensions this year
- The motivation layer, which is not code: the streak, the score, the difficulty setting and the social pressure are the reason Opal works, and none of them survive being written by the person they are supposed to constrain
- Every September, forever. Screen Time entitlements, extension signing and shield behaviour are exactly the parts of iOS that move between releases
Is that you?
the verdict is a default, not a law
- It shields a handful of apps on a fixed schedule, on one phone, and you are content that the report screen is Apple's rather than yours
- You have a paid developer account, so the build does not expire under you every seven days
- Nothing is synced anywhere and there is no account
- You genuinely wanted friction rather than enforcement, and are honest that you can delete the app in four seconds
- The plan depends on reading usage data out of the reporting extension — that is not a hard feature, it is a closed door, and any workaround you find is a privacy bypass you should not ship
- You are reaching for a VPN profile, a DNS override or a content filter because the Screen Time API would not cover a browser tab
- Screen-time or blocklist data leaves the device for a dashboard, a leaderboard or a backup
- It goes on a partner's or a child's phone without them setting it up in front of you — that is monitoring software with a different name and a different set of consequences
- You are shipping it to other people and have not been granted the distribution entitlement
If you build it anyway
the checklist, then the prompt that enforces it
- Use FamilyControls, ManagedSettings and DeviceActivity and nothing else. Any design that reaches for a network filter or a VPN profile to block apps has left the supported path and taken on a security cost the feature does not justify.
- Check the entitlement story before the feature list. Development works locally with no approval; distribution is requested per bundle ID and separately for every Screen Time extension you ship.
- Write the unshield path first — lift a shield, clear every ManagedSettingsStore, uninstall cleanly — and test it before the first blocking rule exists.
- Keep a permanent unshieldable set: Phone, Messages, Settings, your authenticator, your employer's VPN client. A blocker that can lock you out of two-factor is worse than no blocker.
- Fail open. If the monitor extension crashes or a schedule cannot load, drop the shields and say so, rather than leaving restrictions applied indefinitely.
- Do not route around the report extension sandbox. If a plan involves an app group, a pasteboard or a screenshot to get usage data out, the plan is a privacy bypass and the answer is to render the chart inside the extension.
- Keep rules and schedules in a plain file you can read outside the app, so leaving costs you the file and nothing else.
- Get the time handling right before anything else: restarts, DST, timezone changes and sessions that cross midnight are where blockers actually fail.
I am building a screen-time blocker for my own iPhone. Apple already owns the
dangerous parts of this; your job is to stop me rebuilding them badly, and to
push back when I ask for something on this list.
1. Use FamilyControls, ManagedSettings and DeviceActivity only. If I ask for a
VPN profile, DNS override or content filter to block apps, refuse and say
why the supported API is the whole point.
2. Before designing anything, tell me which entitlement each feature needs.
Development is available locally; distribution is requested per bundle ID
and again per Screen Time extension. Do not design around one I lack.
3. Build the unshield path first: lift a shield, clear every
ManagedSettingsStore, uninstall cleanly. Test it before any blocking rule.
4. Keep an unshieldable set — Phone, Messages, Settings, my authenticator, my
employer's VPN client — and refuse a block-everything mode that ignores it.
5. Fail open. If the monitor extension crashes or a schedule fails to load,
remove the shields and tell me loudly instead of leaving them applied.
6. Usage data does not leave the DeviceActivityReport extension. If I ask for a
dashboard, a synced streak or a leaderboard, tell me the sandbox has no
network by design, and refuse to work around it with app groups or
screenshots.
7. Get time handling right before UI: restarts, DST, timezone changes and
sessions crossing midnight. Show me the test cases.
8. Keep rules and schedules in a plain readable file outside the app database.
9. If I ask to put this on someone else's phone without them configuring it,
stop and tell me what that software is actually called.
10. Out of scope, and say so: Android, browser blocking, anything that syncs,
and the score-and-streak layer. Then tell me Opal is $19.99 month-to-month,
and that the streak mechanics are the part I am actually paying for.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
When you notice you have been ignoring your own blocker. The engineering gap here is narrow and the behavioural gap is enormous: streaks, an escalating difficulty setting, the deliberate friction of a fifteen-second delay, and a report screen that guilts you into looking at it. None of that is code you could not write; all of it is design you would soften the moment it inconvenienced you, because you are both the author and the target. Twenty a month, or ninety-nine a year, buys an adversary who is not you — plus the entitlement, and someone whose job is to fix it after each iOS release.
$19.99/mo is cheaper than your weekend.
Uninstalling is genuinely the exit, which is the compensation for everything the sandbox will not let you build: deleting the app clears its ManagedSettingsStores and revokes the Family Controls authorisation, and there is no daemon, no profile and no certificate left behind. The two things worth doing before that are keeping your rules in a readable file rather than in Core Data, and never having a server in the picture — if you did add one, the export you want is not the schedules, it is the deletion of whatever usage history you uploaded, because nobody else's screen-time record was ever supposed to exist off the device.
Local-first automatic time tracking with an extensible event model, and no server anywhere in the design.
Free macOS blocker that solved the part nobody enjoys — a timer you genuinely cannot cancel, surviving restart and app deletion.
Questions
If Apple gives me the API, why is this only DEMO ONLY?
Because the API gives you the half that is not the product. Shields on a schedule is a weekend and it works. The Opal Score, the history, the trends and anything cross-device are blocked by the DeviceActivityReport sandbox, which has no network access and no supported way to hand raw usage back to your app — Apple built it that way on purpose. You will reach a convincing demo, discover the reporting wall, and then discover the second wall, which is that the demo does not change your behaviour.
So can I actually build and run this on my own phone, or not?
You can. The Family Controls development entitlement works locally without Apple approving anything, so a personal build on your own device is legitimate and reachable. The distribution entitlement is the one you have to request, per bundle ID and again for each Screen Time extension, with a written justification. That is the line: personal use is open, shipping it to anyone else is a conversation with Apple, and a free Apple ID adds a seven-day provisioning expiry that will quietly stop your blocker every week.
Why does this score lower than Freedom when it is the same idea?
Because the platform absorbs the risk. Freedom's desktop story ends in a root daemon and, if you are careless, a certificate authority in your trust store — a permanent security cost on the machine you bank from. The iOS version ends in an entitlement and a sandbox. Apple has taken the dangerous work away from you and will not give it back, which makes this a smaller, duller and considerably safer thing to build. Fewer options is why the score is lower.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
The timer is four lines. The unbroken history across three devices is the product, and that's a sync engine.
Serene's website now redirects to the agency that built it. You can't buy this one, so you may as well build it.
A blocker only works if it is harder to remove than the urge to remove it. That is a description of malware.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice