Mobile App Development for Parental Control

Developing a Mobile App for Parental Control

Parental control is not just "block TikTok". Behind this formulation lie three technically incompatible tasks: traffic interception, system function restrictions, and activity monitoring—all on platforms that deliberately make such things difficult. Apple and Google regularly close APIs that previous versions of such apps relied upon. System design must account for the possibility that half the mechanisms may change within a year.

iOS: Screen Time API as the Only Legal Path

Before iOS 16, developers used VPN profiles for DNS interception and MDM configurations for restrictions. These still work, but such apps won't pass App Store review—Apple 4.2 (minimum functionality) or outright rejection for using private APIs.

The only legal and stable path on iOS today is Family Controls from ManagedSettings and FamilyActivityPicker (iOS 16+, Swift). The parent authorizes the child via AuthorizationCenter.shared.requestAuthorization(for: .individual), and the app gains access to:

• ManagedSettingsStore — block specific apps, restrict websites via WebContentFilter, disable App Store, limit screen time.
• DeviceActivityMonitor — background extensions receiving intervalDidStart/End and eventDidReachThreshold events without a constantly running main app.
• ShieldConfiguration — custom placeholder screen when attempting to open a blocked app.

Family Controls limitation: works only for a "child" Apple ID in family sharing. If the child uses a separate adult Apple ID, the API is unavailable. This is an organizational issue, not technical, but the customer must be warned upfront.

A typical gotcha during development: DeviceActivityMonitor is an App Extension running in a separate process with limited resources. Attempting to access CoreData in the main container from the extension causes a crash with NSPersistentStoreCoordinator: Multiple NSEntityDescriptions. Solution — App Group with a shared SQLite file via NSPersistentContainer with explicit appGroupContainerIdentifier.

Android: More Complex but More Flexible

Android provides more tools, but their combination requires precision. The working stack:

UsageStatsManager — application usage statistics with per-package granularity. Requires PACKAGE_USAGE_STATS—the user must explicitly grant permission in settings (can't be requested via requestPermissions). Classic case: app requests permission, user taps "Back", statistics don't work. Onboarding with a direct Intent to Settings.ACTION_USAGE_ACCESS_SETTINGS is needed.

DevicePolicyManager + Device Owner / Profile Owner. Device Owner provides full control: app blocking, camera blocking, network settings blocking. Setting Device Owner requires an ADB command during initial setup (adb shell dpm set-device-owner), impractical for mass products. Profile Owner works within Work Profile—slightly less powerful but easier deployment.

AccessibilityService — historically popular for monitoring active app (TYPE_WINDOW_STATE_CHANGED). Google consistently tightens Play Store rules: apps with AccessibilityService without obvious accessibility reason are removed. Use only as a last resort with strong justification for review.

VPN API (VpnService) — local VPN for DNS filtering. Traffic doesn't leave the device; everything is filtered via loopback through a DNS resolver. Works without root. Apply with blocked domain databases (StevenBlack, Pi-hole lists). The problem: some apps use DoH (DNS-over-HTTPS) and bypass DNS filtering. Solution — deep packet inspection by SNI through TLS proxy, but this is more complex and requires installing a root certificate.

Location Monitoring

CLLocationManager on iOS and FusedLocationProviderClient on Android are the standard for background geolocation. But background geolocation has nuances: iOS from iOS 13 shows the user a notification "App X is using your location"—the child sees it. On Android from version 10, ACCESS_BACKGROUND_LOCATION + explanation in Google Play Console is required.

For battery conservation, use geofences (CLCircularRegion / GeofencingClient) instead of continuous tracking. Entering/exiting zone event generates a push notification to the parent. Continuous tracking—only by explicit request.

Synchronization and Parental Dashboard

Child device data → encrypted channel → backend → parent app. End-to-end encryption is not necessary—TLS with mutual auth is sufficient. But storing app activity statistics, browser history, and geolocation—these are sensitive data requiring GDPR/COPPA compliance (if users are under 13).

COPPA in mobile app context means: parental consent before collecting any child data, minimization of collected data, deletion on request capability. Apple and Google require explicit declaration in App Store Connect / Play Console about collecting minor data.

Project Stages

Choose platform and API strategy → architecture design (child client, parent client, backend) → develop restriction mechanisms → activity monitoring → geolocation → parent dashboard → test on different OS versions → App Store / Google Play review → support.

Timeline: MVP with basic app restrictions and monitoring—from 8 weeks on one platform. Full product with two platforms, geolocation, DNS filtering, and dashboard—4–6 months. Cost is calculated individually.