The Short Version
Why "Just Block the App" Isn't One Problem
App blockers and screen-time limits sound like a single well-understood feature, the kind every phone should support the same way. In practice it splits into two different problems depending on the platform. iOS has had a framework built specifically for this since iOS 16: Screen Time's underlying APIs (FamilyControls, DeviceActivity, ManagedSettings) exist so a third-party app can gate other apps without needing to know what those apps actually are. Android has no equivalent. There's no "block this app system-wide" permission to request. Building the same feature there means repurposing three subsystems designed for something else entirely: usage reporting, accessibility tooling, and floating windows.
How It Works on iPhone: The OS Does the Blocking
Setting up Screen Guard on iOS starts with Apple's own picker. You choose apps, and the picker hands back both a human-readable list (for Health Partner's own settings screen) and a set of opaque, per-app tokens with no readable identity attached. Enforcement only ever uses the tokens: they're handed to Apple's ManagedSettingsStore, and it, not any code Health Partner wrote, decides when to actually shield an app.
The threshold that trips the shield is scheduled ahead of time with DeviceActivity: register a schedule plus a series of usage thresholds in minutes, and the OS calls back once real usage against the chosen apps crosses each one. Health Partner converts earned walking minutes into a threshold and registers it. When usage crosses the top threshold, a separate process, a DeviceActivityMonitor extension, wakes up on its own and applies the shield, whether or not the main app is even running.
That's the clean version. Three behaviors Apple's documentation doesn't spell out only showed up from running this on real devices:
- Re-registering a schedule doesn't add to existing progress, it resets it. Earning one more minute mid-day, including from ordinary background step-counting rather than deliberate walking, would otherwise hand back a full fresh quota instead of the small amount actually earned. The fix: always schedule against the remaining quota, and track used minutes separately so a reschedule never erases them.
- Starting a schedule that's already running silently stops it first, and that stop is treated as the schedule ending for the day, the same signal that's supposed to mean "reset usage, it's midnight." Since a reschedule happens every time the earned-minutes target changes, not once a day, that reset code would otherwise fire repeatedly and wipe out real usage each time. The fix checks whether the calendar day has actually changed before trusting it.
- A schedule has no day field, only a time of day. Setting the end time to midnight makes the start and end times identical, which the OS treats as an invalid empty schedule and rejects outright. Apple's own sample code uses 23:59 for exactly this reason, but it isn't documented as a requirement.
How It Works on Android: No API, So the App Builds One
Android's version of the same feature has no framework to lean on. It's assembled from three permissions doing jobs they weren't designed for:
- Usage Access unlocks UsageStatsManager, which gives real per-app foreground time computed the same way Android's own Digital Wellbeing screen does, from the raw event log, not a timer the app maintains itself (a self-maintained timer would drift or reset if the background process were ever killed mid-session).
- Accessibility lets a background service see which app just came to the foreground, which is the trigger that decides whether to check anything at all.
- The block screen itself is just a window, since Android has no OS-level shield API. The app builds and displays it by hand.
Two real deployment problems came directly from repurposing permissions built for something else:
- A plain accessibility service is exactly the kind of background process OEM battery managers are built to kill. The fix was running it as a foreground service with a permanent, low-priority notification, the same workaround a well-known open-source app blocker independently arrived at for the same reason.
- On a OnePlus device running ColorOS, the standard overlay window type was getting torn down within 40-60 milliseconds of appearing, confirmed via logcat, first by the phone's own floating-window detector and then again by the blocked app immediately reclaiming focus. The fix was switching to the window type Android reserves specifically for an active accessibility service, rather than the general-purpose "draw over other apps" type most overlays use and that OEM overlay managers are specifically built to police.
Even with the block screen solved, a single-Activity app (most modern apps, including this one) doesn't refire a foreground-change event just because someone scrolls or navigates inside it. So the moment a restricted app opens, Health Partner starts a quiet check every five seconds for as long as it stays in front, since otherwise crossing the quota mid-session would only get caught the next time someone switched apps entirely.
The Honest Limits
This is a self-motivation tool, not a tamper-proof restriction. In soft mode, "Continue Anyway" is always one tap away, deliberately. Even in hard mode, someone determined enough to turn off Accessibility or Usage Access in Settings can disable the whole mechanism outright. Nothing about this design is built to survive an adversarial user, because that was never the goal: it's built to make the honest, in-the-moment choice slightly harder, not impossible.
Reliability on Android also depends on cooperation the app can't fully control. Exempting Health Partner from Android's own battery optimization helps, and Screen Guard prompts for it, but it doesn't reach a manufacturer's separate battery-management layer, the "Auto-launch" or "Protected Apps" lists on ColorOS, MIUI, and similar OEM skins, which has to be found and enabled manually, per device, per manufacturer, and isn't something any app can flip on by itself.
What This Means for You, Practically
- Grant both permissions up front. On Android, Usage Access and Accessibility both need to be on before Screen Guard has anything to earn against or block on.
- Say yes to the battery-optimization exemption on Android. It's the single biggest lever against the background service getting silently killed.
- Start in soft mode. Hard mode with an uncalibrated ratio just means locking yourself out with no way back in until you've walked more.
- Expect a short delay, not instant enforcement, the first time you open a restricted app after crossing your limit.
Frequently Asked Questions
Does Screen Guard work the same way on iPhone and Android?
No, not under the hood. On iPhone, Apple's Screen Time framework enforces the block at the OS level, outside the app entirely. Android has no equivalent framework, so the same behavior is built from usage tracking, an accessibility service, and a block screen the app draws itself.
Can I get around the block by turning off a permission?
Yes, and that's by design. Screen Guard is meant to make the moment of picking up a restricted app slightly harder, not to survive someone determined to disable it. It's a self-motivation tool, not a tamper-proof restriction.
Why does the block sometimes take a few seconds to appear?
Real usage numbers come from a separate OS subsystem (UsageStatsManager on Android, DeviceActivity on iOS) that can lag a couple of seconds behind the moment an app actually opens. Health Partner double-checks shortly after entry rather than trusting only the very first read.
Do I lose unused earned screen time at midnight?
Earned minutes are a daily budget, not something that carries over. Each new day starts a fresh quota based on that day's steps and goals, not whatever was left unused the day before.
Why does Android need more setup than iPhone for the same feature?
Because iPhone's version is built on a framework Apple designed specifically for this. Android has no equivalent public API, so the same feature is stitched together from three permissions meant for other purposes, and each one needs its own explicit grant.
Where This Leaves You
Screen Guard looks identical from the outside on both platforms: a ratio, a mode, a list of apps. Underneath, iPhone gets an OS built for exactly this, and Android gets three borrowed permissions and a hand-drawn block screen standing in for one. Neither version is fake, and both actually work, but they're not remotely the same amount of platform doing the work for you. Download Health Partner to try it on your own phone.
References
- Apple Inc. Family Controls framework documentation. developer.apple.com. developer.apple.com/documentation/familycontrols
- Apple Inc. DeviceActivity framework documentation. developer.apple.com. developer.apple.com/documentation/deviceactivity
- Apple Inc. ManagedSettings framework documentation. developer.apple.com. developer.apple.com/documentation/managedsettings
- Android Open Source Project. UsageStatsManager. developer.android.com. developer.android.com/reference/android/app/usage/UsageStatsManager
- Android Open Source Project. AccessibilityService. developer.android.com. developer.android.com/reference/android/accessibilityservice/AccessibilityService
Also on the blog
"Your data is encrypted" often means less than it sounds. Here's how to check if it actually protects you, using real end-to-end encrypted journaling as the worked example.
What a Full 24-Hour Fast Actually Does to Your BodyA full day without food does more than burn fat: growth hormone rises, the gut resets, and metabolism doesn't slow the way people assume. Here's the research.