Articles

What an app with Screen Time access can see

By Michael Fuchs · Published 2026-09-29

In short An app with Screen Time access gets the apps you choose as sealed tokens, and learns how long you use them only through alarms it has set in advance. Real app names and minutes reach only two small parts of it, which Apple cuts off from the network. Everything else it learns, it could send anywhere: only Apple's contract forbids it, and some apps do send a daily total for their social features. In the EU, since iOS 26.4, one app per phone may ask for far more.

When an app asks for Screen Time access, iOS asks whether to let it “see your activity data, restrict content, and limit the usage of apps and websites” [1]. You confirm with Face ID, and that is all the explanation you get.

Wanting to know more is fair. Parental control apps, the older relatives of screen-time apps, have a poor record: of 46 studied on Android, 72% shared data with third parties such as advertising and analytics services without naming them in their privacy policy, the authors report [2].

I am building an app that needs this access, so I have spent weeks finding out what that one sentence means in practice. Here is what an app gets, what Apple keeps from it, and where the only protection is a promise. It holds for every app that limits screen time through Apple’s Screen Time API, mine included.

Your apps arrive as sealed tokens

You choose apps in a picker that Apple provides. Apple describes it as a view in which people choose apps “without revealing their choices to the app” [3]. What the app receives is a set of opaque tokens, one per app, category or website, with neither a name nor a bundle identifier in them [4; 5; 6].

The app can still show you what you picked: it hands a token to a system label, and the label draws the app’s icon and name, which Apple calls a “read-only, visual representation” [5]. The app itself cannot read what the label shows [5; 7]. I found out how strict that is by accident. VoiceOver reads nothing for such a label, because its text never appears in the app’s own accessibility tree, so the app cannot have the name read aloud either [7].

Tokens are meant to keep anyone outside your Family Sharing group from knowing which apps you use [4], and when Screen Time syncs between your own devices, Apple encrypts it end to end [8]. Tokens can still leave the phone. Brick says it stores the tokens of the apps you block on its servers, and that it cannot tell from them which apps they are [9].

Your usage arrives as alarms set in advance

Unless it has the EU access described below, an app cannot ask how long you spent in Instagram today. It can only tell the system beforehand: let me know when these apps, together, have been on screen for half an hour [10; 4]. iOS does the counting. When the line is crossed, it wakes a small part of the app, the monitor extension, and tells it only the name of the alarm [11].

The app chooses how much time each alarm waits for [10]. It still knows the apps only as tokens, never by name.

The shield, the screen iOS puts in front of a blocked app, adds one more thing. When you tap one of its buttons, another part of the app, the shield action extension, is told which token you reached for and which button you tapped [12].

Names and minutes exist, in two sealed rooms

There are two places where an app’s own code does get real names.

The first is the report extension, which an app can use to draw a usage chart. It is handed each app you used, with its minutes, the number of times you picked up the phone for it, and how many notifications it sent [13; 6]. The second is the shield configuration extension, which draws the shield. It is given “the display names, bundle identifiers, and domains” of what it shields [14].

Both run in a sandbox that, in Apple’s words, “prevents your extension from making network requests or moving sensitive content outside the extension’s address space” [15; 14].

I have run into the second wall myself. My app’s shield configuration extension may read the app’s own files, but not write to them: a file write fails with “Operation not permitted”, and a write to the app’s settings reports success and stores nothing [16].

Everything else is a promise

The monitor extension and the app itself have no such wall. Apple’s documentation of the monitor mentions no sandbox [11], and when a developer asked how to make a network request from it, an Apple engineer showed how to keep it alive until the request finishes [17]. So the alarms, the minute counts they add up to, the moments you met a shield and what you tapped, and the tokens can all be sent to a server. Technically, nothing stops it.

What forbids it is Apple’s developer agreement. An app “may not share device or usage data received through the Family Controls Framework or otherwise, beyond the family controls You provide, or the individual and their device” [18, § 3.3.3(P)]. That is a contract, and Apple reviews each app before it grants the access [19]. It is not a wall.

Some apps send such data, and say so. Opal writes that “Private Data stays on your device”, and on the same page that if you opt in to its social features, “your daily total screen time is shared with confirmed friends via our servers” [20]. ScreenZen stores “your aggregate daily screen time” for its social feature, and may collect a daily total of the time spent in your blocked apps to learn whether the app helps [21]. Whether this fits Apple’s contract is for Apple to judge. What it shows is that “stays on your device” [20] describes an app’s code, not the platform.

In the EU, one app per phone may see far more

Since iOS 26.4, Apple offers more. An app that carries one more permission from Apple, and has yours, may read “the actual bundle identifiers of installed applications, domain names of visited websites, and display names of activity categories” instead of tokens [22]. It may also fetch usage data through a method Apple describes as a way “to export family activity data, for use in another app or platform” [23]. Only one app per phone can hold this access at a time [22], and only on devices in the EU signed in with an Apple Account from an EU country or region [24].

Apple does not say why it is limited to the EU. My app does not ask for this access.

How you can check an app

You cannot read an app’s code, but you can see where it connects. The App Privacy Report in the iPhone’s settings, there since iOS 15.2, lists the domains each app has contacted in the past 7 days [25]. An app that never goes online has no entries there.

The privacy label on the App Store tells you less than it seems to. It is the developer’s own statement, and data processed only on the device does not count as collected [26]. Studies have often found apps sending data their label does not declare. Of 1,687 apps whose traffic was recorded for a minute without anyone touching them, at least 276 sent such data [27]. Among apps that claimed to collect no data, 68.6% sent data to a known tracking domain the first time they started [28]. Some of it may be error rather than intent: when 12 developers were watched filling in the label for their own app, 9 made mistakes, some leaving data out, some adding data they did not collect [29].

What my app sees and keeps

I make I Have No Self Control, an iPhone app that gives the apps you choose a daily limit and puts a price on more time. This is what it does with the access:

• It knows your apps as tokens and shows them through Apple’s label. It never reads their names.
• It uses its alarms only on apps you chose, and only to keep the limits and prices you set.
• Its shield configuration extension reads which of your groups the blocked app belongs to, so that the shield can name the group. It cannot write anything down.
• When you tap a button on the shield, the app records when you met it and what you chose. It does not record which app it was.
• It has no report extension and no usage charts.
• It has no network code, no account and no server. What it records stays on the phone and is gone when you delete the app.

The test builds I give to a few testers have one thing more: they can export a reduced copy of the record, with no group names, no times of day and no dates, and a tester can send it to me by hand. No build in TestFlight or the App Store carries it.

What this means for the app I am building

Writing this, I found two things to change. The first is my app’s most detailed record, its own log: when a group’s limit ran out, and when you met the shield. It never leaves the phone, but it never ends either: nothing deletes old entries while the app is installed. How much history it should keep is now an open question on my list.

The second was my own privacy policy. It said the app does not know which apps you selected. That was true of everything the app keeps, but not of the moment its shield is drawn: then one part of it is told which app it is shielding, and cannot write that down. The policy now says what holds: the app can neither store nor pass on which apps you selected, because wherever it could, Apple hands it only tokens.

How I checked

I read Apple’s documentation, its developer agreement and its engineers’ answers in the developer forums with the help of AI research tools, and checked every quote against its page on 25 September 2026. Every number from a study is traced to the study itself, not to a summary of it. The vendors’ statements come from their own pages, read the same day. The measurements are my own, made on my phones and in Apple’s iPhone Simulator while building the app, and each one below names the device and the iOS version. If you find something I got wrong, the imprint has my address.

This site belongs to an iPhone app: a daily limit on the apps that pull you in, and a price on more time, both set by you earlier. See how it works