DEV Community: Rexa

Blocking apps on iOS vs Android: I built the same feature twice and they have nothing in common

Rexa — Tue, 28 Jul 2026 20:04:53 +0000

I spent a year building a focus app with an app blocker in it, which meant writing the feature once for Android and once for iOS. I expected two implementations of the same idea. What I got was two ideas that happen to produce the same screenshot.

The short version: on Android you build a blocker. On iOS you ask for one.

Android: you detect, you enforce

You poll UsageStatsManager from a foreground service to find out which app is in front, compare it against your blocked list, and launch your own translucent activity over the top.

val events = usm.queryEvents(lastQueryTime, now)
val event = UsageEvents.Event()
while (events.hasNextEvent()) {
    events.getNextEvent(event)
    if (event.eventType == UsageEvents.Event.MOVE_TO_FOREGROUND) {
        currentForeground = event.packageName
    }
}

event.packageName is a plain string. com.instagram.android. You know exactly what the user opened, you know when, and you could count it, log it, or send it somewhere. The platform trusts you not to.

Everything downstream is yours: your own app picker built off getInstalledApplications, your own lock screen with whatever countdown ring and copy you want, your own rules about grace periods and escape hatches.

The bill comes as operational work. A foreground service with a specialUse type and a justification string for the reviewer. A persistent notification you can't remove. Roughly a second of latency from the poll interval. Debouncing, because an app fires several foreground events while opening and your lock will strobe without a guard. And OEM battery managers that kill your service anyway.

iOS: you never find out anything

Here's the entire enforcement path on iOS:

sharedStore.shield.applications = selection.applicationTokens

That's it. There is no service, no polling, no lock screen of yours, no detection of any kind. You hand ManagedSettingsStore a set of tokens and the OS does the shielding, at a level your process never sees.

The thing that took me longest to accept is what selection.applicationTokens actually contains. It's a set of ApplicationToken - opaque. Not a bundle ID. Not a name. Not an icon. You cannot decode it, log it, compare it to a list you hold, or find out which app the user picked. Your app blocks Instagram without ever learning that Instagram is installed.

Which means the picker can't be yours either:

FamilyActivityPicker(selection: Binding(
    get: { model.selection },
    set: { newSelection in
        model.selection = newSelection
        AppLockModule.sharedStore.shield.applications =
            newSelection.applicationTokens.isEmpty ? nil : newSelection.applicationTokens
    }
))

FamilyActivityPicker is Apple's SwiftUI view. You present it and get tokens back. You can't style the rows, can't search it your way, can't show the user their blocked apps afterwards in your own design - because you don't know what they are. The best you can honestly show is a count.

Getting authorization is one call, and it's all-or-nothing:

try await AuthorizationCenter.shared.requestAuthorization(for: .individual)

The gotcha nobody mentions: persisting the tokens

Tokens are opaque but they are Codable, and you must store them yourself - and store them somewhere your extensions can reach, which means an App Group, not UserDefaults.standard:

private static let suiteName = "group.com.yourapp"

private static func saveSelection(_ selection: FamilyActivitySelection) {
    let data = try JSONEncoder().encode(selection)
    groupDefaults?.set(data, forKey: selectionKey)
}

private static func restoreSavedSelection() {
    guard let data = groupDefaults?.data(forKey: selectionKey) else { return }
    let selection = try JSONDecoder().decode(FamilyActivitySelection.self, from: data)
    sharedStore.shield.applications = selection.applicationTokens
}

I shipped the standard-UserDefaults version first and had to write a migration when the extensions needed the same data. Start with the App Group.

Note the restore call has to run on init. Shields survive app termination, but your in-memory selection doesn't, and if you clear or re-apply without restoring first you silently unblock everything.

The trade, in one line each

	Android	iOS
Who enforces	you	the OS
What you learn	the package name of everything opened	nothing at all
The lock screen	yours	Apple's, unless you ship a shield extension
The picker	yours	Apple's, non-negotiable
Running cost	foreground service, notification, battery	none
Latency	~1s (poll interval)	instant
Minimum version	any, in practice	iOS 16

What I actually think about it

Apple's design is more privacy-preserving than mine and it isn't close. On Android I chose UsageStatsManager over an AccessibilityService specifically to avoid reading the user's screen, and I still end up knowing every app they open. On iOS I couldn't collect that data if I wanted to, because the API never gives it to me. The guarantee is structural rather than a promise in a privacy policy.

The cost is that the iOS version is less mine. I can't design the moment that matters - the screen someone sees when they reach for the app out of habit - without shipping a separate shield extension, and even then within Apple's frame. On Android that screen is the product.

If you're building this: expect two codebases, not one abstraction with two backends. I tried the abstraction first. The shared interface ended up being three methods (requestPermissions, showPicker, setShieldActive) and every one of them means something different on each side.

This is from building Takeover, a focus app where the blocker is the point - both store links are there if you want to see how the two feel side by side. I'm the developer, so weigh the opinions accordingly.

How to block apps on Android without an AccessibilityService

Rexa — Tue, 28 Jul 2026 19:42:30 +0000

Almost every app blocker on the Play Store is built on an AccessibilityService. It's the obvious choice: you get a callback every time a window changes, you read the package name, and if it's on the blocked list you throw something over it. Thirty lines and you're done.

The problem is what you had to ask for to get there. An AccessibilityService can read the content of every screen the user looks at, including their banking app. Google's policy position is that if the narrower API can do the job, you use the narrower API - and for app blocking it can. Reviewers do reject blockers over this, and users are increasingly suspicious of the permission screen regardless.

Here's the version without it. Everything below is running in production.

The short answer

Poll UsageStatsManager from a foreground service to learn which app is in the foreground, and launch a translucent activity over anything on the blocked list. Three permissions:

<uses-permission android:name="android.permission.PACKAGE_USAGE_STATS"
    tools:ignore="ProtectedPermissions"/>
<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE"/>
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE"/>

PACKAGE_USAGE_STATS isn't a runtime permission. You can't request it with a dialog - the user has to grant it in Settings, and you check it through AppOpsManager:

private fun hasUsageStatsPermission(): Boolean = try {
    val appOps = context.getSystemService(Context.APP_OPS_SERVICE) as AppOpsManager
    val mode = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
        appOps.unsafeCheckOpNoThrow(
            AppOpsManager.OPSTR_GET_USAGE_STATS, Process.myUid(), context.packageName
        )
    } else {
        @Suppress("DEPRECATION")        appOps.checkOpNoThrow(
            AppOpsManager.OPSTR_GET_USAGE_STATS, Process.myUid(), context.packageName
        )
    }
    mode == AppOpsManager.MODE_ALLOWED
} catch (e: Exception) { false }

Send them there with Settings.ACTION_USAGE_ACCESS_SETTINGS. Budget for the fact that this is a real drop-off point in onboarding - it's a scary-looking screen buried in special app access, and no amount of copy makes it feel routine.

Reading the foreground app

The core loop. A foreground service with a Handler posting itself every 900ms:

private val pollRunnable = object : Runnable {
    override fun run() {
        checkForeground()
        handler.postDelayed(this, 900L)
    }
}

private fun checkForeground() {
    val usm = usageStatsManager ?: return
    val now = System.currentTimeMillis()

    try {
        val events = usm.queryEvents(lastQueryTime, now)
        val event = UsageEvents.Event()
        while (events.hasNextEvent()) {
            events.getNextEvent(event)
            if (event.eventType == UsageEvents.Event.MOVE_TO_FOREGROUND) {
                currentForeground = event.packageName
            }
        }
    } catch (_: Exception) { return }

    lastQueryTime = now
    // ...check currentForeground against the blocked set
}

Two details in there matter more than they look.

queryEvents returns events, not state. If the user has been sitting in the same app for a minute, nothing changed, so the query legitimately returns nothing. This is the single most common bug in this approach - people query a fixed window, get an empty result, reset their state to "no foreground app", and the lock flickers or drops. Keep the last known package in a field and only overwrite it when an event actually arrives.

Use a rolling window, not a fixed one. [lastQueryTime, now], with lastQueryTime advanced only after a successful read. The event buffer isn't strictly realtime and things can land a few hundred milliseconds late; a fixed [now - 1000, now] window drops those. On startup, backdate it a couple of seconds, or you'll miss the transition that happened just before monitoring began.

Showing the lock

A normal Activity, declared translucent, single instance, and kept out of recents:

<activity android:name=".applock.LockOverlayActivity"
    android:theme="@android:style/Theme.Translucent.NoTitleBar.Fullscreen"    android:excludeFromRecents="true"
    android:launchMode="singleInstance"
    android:exported="false"/>

Launched with FLAG_ACTIVITY_NEW_TASK or FLAG_ACTIVITY_CLEAR_TOP or FLAG_ACTIVITY_SINGLE_TOP. singleInstance plus SINGLE_TOP is what stops you stacking six copies of the lock while an app is still opening.

The three guards you will end up writing

None of these are in the tutorials, and all three are the difference between "works on my emulator" and "works on someone's phone".

An app fires several foreground events while opening. Without a guard you launch the lock, the app's next window event arrives, you launch it again, and the user watches it strobe. Track whether the lock is already visible with a @Volatile flag on the activity's companion, and skip re-launching for the same package within a second.

if (LockOverlayActivity.isShowing) return
if (packageName == lastLockApp && (now - lastLockTime) < 1000) return

Returning to your own app is itself a transition. When the user taps "go back", the blocked app briefly surfaces again while the task switches. Write a short transition marker before you leave and ignore that package for ~3 seconds.

Give people a real way out. If someone deliberately unlocks an app, honour it - a grace period keyed to that package, five minutes or so. A blocker with no escape hatch gets uninstalled, not obeyed.

Foreground service type

On Android 14+ you must declare a type. App blocking doesn't fit any of the specific ones, so it's specialUse, and that requires a property explaining yourself to the reviewer:

<service android:name=".applock.AppLockMonitorService"
    android:exported="false"
    android:foregroundServiceType="specialUse">
    <property android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE"
        android:value="Enforces user-selected app blocking during a focus session by detecting the foreground app via usage access"/>
</service>

Start it with startForegroundService and call startForeground with FOREGROUND_SERVICE_TYPE_SPECIAL_USE on API 34+. Return START_STICKY so the OS brings monitoring back if it kills you mid-session.

What you give up

Being straight about the trade-offs, because they're real:

Latency. Polling at 900ms means up to about a second between opening a blocked app and the lock appearing. An AccessibilityService is effectively instant. In practice a second is fine for the use case - the user sees their feed for a moment and then doesn't.
A permission users have to find themselves. No dialog, no one-tap grant.
A persistent notification. Foreground service, no way around it.
OEM behaviour varies. Aggressive battery management on some skins will kill the service. START_STICKY helps; it isn't a cure.

What it buys you is that you never asked to read the user's screen. For a blocker, that's the right trade - both for review and for the person installing it.

What this doesn't solve

This is not parental-control-grade enforcement and shouldn't be sold as such. Anyone can go to Settings and revoke usage access, and the lock is gone. The design goal isn't to make bypassing impossible, it's to make it cost about thirty seconds of deliberate effort - which turns out to be longer than the urge to open Instagram usually lasts.

I build Takeover, where this runs - so take the framing with that in mind. The approach isn't specific to it, and I'd rather more blockers used it.