The Challenge: What Platforms Allow and What They Don't
On Android, apps can request accessibility service permissions and device administrator status, which enable a limited but useful set of controls — including the ability to detect when a restricted app moves to the foreground and redirect the user. Android's flexibility here is relatively well-documented, though the available APIs change with each major release and require careful permission management. On iOS, the situation is completely different.
Apple does not allow third-party apps to monitor or control other apps on the device without the device being enrolled in Mobile Device Management (MDM) — which requires the user to install a management profile and accept significant device control. For a consumer-facing app lock, MDM is not a practical option: it requires a complicated setup that most users will not complete, and it gives the app levels of access that would cause App Store rejection under Apple's privacy guidelines. The engineering challenge was building an app lock for iOS that was genuinely useful without relying on permissions Apple would never grant.
How We Built Within Apple's Guidelines
Apple provides a legitimate API for exactly this use case in supervised or family contexts: Screen Time, accessible to developers through the Family Controls and Managed Settings frameworks introduced in iOS 16. These APIs allow a properly authorised app to restrict access to specific apps, categories of apps, or entire device capabilities — without requiring MDM or bypassing any App Store guideline. Using the Family Controls framework, our app can request Screen Time authority, which requires a one-time user authorisation at the iOS system level.
Once authorised, the app can apply and remove app restrictions programmatically. The user must actively grant this authorisation — Apple ensures this is not something that can be granted silently — which means the permission model is transparent and consent-based. This was the correct approach: we used the API Apple built for this exact purpose, implemented it correctly, and passed App Store review on the first submission.
Android: Accessibility and Focus Mode
On Android, we used a combination of the UsageStatsManager API — which allows the app to detect which app is in the foreground — and an overlay mechanism to intercept the launch of restricted apps during locked periods. We also integrated with Android's Digital Wellbeing API on supported devices for a cleaner, system-native experience. The app requests only the permissions required for its stated function, explains each permission clearly in the onboarding flow, and provides users with a granular control over which apps are locked and for how long.
This explicitness was important both for user trust and for Play Store compliance review, which has become more stringent about apps requesting broad device permissions.
The Management Dashboard
The app has two interfaces: the device-side app for the end user or device owner, and a web-based management dashboard for administrators, parents, or employers managing multiple devices. The dashboard shows every device enrolled under an account, the current lock state of each device, the scheduled lock periods, and usage analytics — how many times a restricted app was attempted, how many times a lock period was active, and trend data over time. Administrators can push lock schedules remotely, modify which apps are restricted, and receive alerts when a device comes off its scheduled lock period.
The analytics layer was built on a custom backend with a PostgreSQL database and a real-time websocket connection so the dashboard reflects device state changes within seconds. All device data is end-to-end encrypted between the device and the dashboard.
Live on Both Stores
The app passed App Store review on the first iOS submission — an outcome that reflects the correctness of our approach. We used legitimate Apple APIs, documented our permission usage clearly, provided a demo account for the reviewer, and submitted with complete metadata. The Android submission similarly passed Play Store review without rejection.
Both apps have been live since launch with no enforcement actions or guideline violations. The client has deployed the app to a managed fleet of devices, uses the dashboard for reporting, and has extended the feature set to include schedule management by the device user themselves — with admin override capability for situations where the admin needs to maintain control.
Have a mobile app idea with complex platform requirements?
We have built apps that work within Apple and Google's guidelines for some of the hardest use cases. Tell us what you need to build.
Talk to Our Mobile TeamFrequently Asked Questions
Can you lock individual apps on iOS without MDM?
Yes, using Apple's Family Controls and Managed Settings frameworks (iOS 16+). These APIs allow a properly authorised app to restrict access to specific apps without requiring MDM enrolment. The user must grant Screen Time authority through a system-level prompt — this is Apple's consent model for this capability.
How do you build an app lock within Apple's guidelines?
By using the APIs Apple provides for this use case: the Family Controls and Managed Settings frameworks. Apps that attempt to lock or monitor other apps without these APIs — through undocumented methods or screen recording — will be rejected. Using the correct API is both the compliant approach and the reliable one.
What app restrictions are allowed on iOS without MDM?
Using Family Controls, a third-party app can restrict access to specific apps, app categories, and certain device capabilities with user consent. Screen Time authority must be explicitly granted by the user through the iOS system. More extensive control — such as preventing uninstallation of the management app itself — requires MDM.
Does the app lock work if the user uninstalls the app?
On Android, the device administrator permission makes uninstallation significantly harder but not impossible for a technically motivated user. On iOS, Screen Time authority can be protected with a Screen Time passcode that only the administrator knows — preventing the user from removing the restriction without the passcode.