Screen Time on iOS 15 to 27: Mostly Empty Usage Tables and Counts That Change Without the Write-Ahead Log

1 Introduction

Screen Time is the iOS feature through which a person, or a parent in a Family Sharing group, sees how a device is used and sets limits and restrictions [6]. The commonly repeated advice is that the database RMAdminStore-Local.sqlite holds usage by app and by hour and should be parsed from a full file system extraction [13]; two vendor posts discuss Screen Time as evidence of app use [8], [9]. That advice dates from iOS 12 [13], the public parsers name iOS 12 to 14 (Section 2.4), and we found no re-measurement on current releases.

A motivating example. Two readings of the same iOS 17.6.1 store give different answers to the simplest question, how many usage blocks it holds (Listing 1). Read with its write-ahead log, the store holds 78; the main database file copied alone holds 441. Neither reading raises an error. On the iOS 26 stores in our sample the more likely answer is zero: six of the seven iOS 26 stores whose Screen Time flag is on held no usage rows at all.

copy A: RMAdminStore-Local.sqlite + -wal + -shm
copy B: RMAdminStore-Local.sqlite alone
open each copy read-only and run
  SELECT COUNT(*) FROM ZUSAGEBLOCK;
copy A (log applied)        78
copy B (main file alone)   441

The problem: answers that depend on how the store is read. The example shows two ways in which a reading of this store can mislead. First, a negative is easy to misread: if the usage tables are empty, an examiner may conclude that the device was not used or that Screen Time was off, and whether either conclusion holds depends on what else the store keeps. Second, the count itself depends on whether the database was read with its log, and a report rarely says which. We therefore ask four questions about iPhones running iOS 15 to iOS 26, and about iOS 26 and 27 sysdiagnoses.

• RQ1 (Content). What does the Screen Time store hold, and are usage tables its usual content?
• RQ2 (Write-ahead log). How much does the treatment of the database's write-ahead log change what is reported?
• RQ3 (Deletion). What survives in the installed-app list and in the Core Data persistent history, and what do deletion tombstones show?
• RQ4 (Sysdiagnose). What does a sysdiagnose hold of the ManagedSettings stores, and how do store names vary between releases?

Contributions. This report makes four contributions.

• A measurement of what 17 iPhone Screen Time stores hold: usage rows are present on 4 of 17, and configuration, installed-app rows and persistent history are the more common content (Sections 4.1 and 4.2). This qualifies the usage-centred guidance.
• A measurement of the write-ahead-log effect on this store: 14 of 17 stores report a different count when the database is read without its log (Section 4.3). SQLite documents the log [17]; we found no report of the size of the effect on this store.
• An analysis of deletion tombstones against the live installed-app list of the same store, which separates “the history kept this identifier” from “the app was removed” (Section 4.4).
• Ten read-only parser artifacts, eight for the file system store and two for sysdiagnose ManagedSettings, that present what the store held as stored, with a synthetic store generator and unit tests; the eight file system artifacts agree with independent SQL (Sections 3.3 and 4.7). This is engineering that makes the measurements repeatable, not a research result in itself.

Scope. All results describe 17 iPhone stores of unknown usage and two sysdiagnoses (Section 3.1). A row is evidence of what the store held, and percentages describe this sample only. Section 6 states the limits. Section 2 gives background and positions the work, Section 3 the study design, Section 4 the results and Section 5 what they mean for reading this store.

2 Background and Related Work

This section describes the stores, the two database mechanisms that our results depend on, and the existing parsers, and closes with work on validating forensic tools.

2.1 The Screen Time store

On a full file system extraction the Screen Time and remote-management state sits in two Core Data SQLite files, RMAdminStore-Local.sqlite and RMAdminStore-Cloud.sqlite, in the Application Support folder of the com.apple.remotemanagementd daemon [13]. Core Data names its tables after the model entities with a Z prefix (for example ZINSTALLEDAPP) and keeps an entity-name table, Z_PRIMARYKEY. The usage tables (ZUSAGEBLOCK, ZUSAGECATEGORY, ZUSAGETIMEDITEM and related tables) are named in the queries of the public parsers (Section 2.4). Settings and restrictions are stored as blueprints whose configurations are property lists in the declarative-management format. Apple publishes the declaration schemas for managed devices [3]; the declaration types seen in the store (Section 4.5) do not appear in that schema.

2.2 Persistent history and the write-ahead log

The store also contains Core Data persistent history. When history tracking is on, each save is recorded as a transaction with change rows of type insert, update or delete, and a delete entry can carry a few attribute values of the removed object, called a tombstone [5]. The tables are ATRANSACTION, ACHANGE and ATRANSACTIONSTRING. Core Data may trim history, so the rows present are the transactions the store still holds.

The database is kept in SQLite's write-ahead-log mode: recent changes sit in a separate -wal file that belongs to the state of the database and that readers consult [17]. The main file alone is therefore the database as it stood at an earlier checkpoint. Practitioner literature warns that opening a database together with its log can write the log into the main file and overwrite records [16].

2.3 ManagedSettings

Apple's ManagedSettings framework lets an app that holds the Family Controls entitlement apply restrictions through named settings stores [4]. A sysdiagnose copies these stores under logs/ManagedSettings; on a file system extraction the live copy sits under /private/var/mobile/Library/com.apple.ManagedSettings. We found no public description of the store names or of the property list keys.

2.4 Practitioner guidance and existing parsers

Practitioner guidance treats the store as a usage source. The Magnet post of 2018 names the database files and the need for a full file system acquisition, and names no tables [13]. Two Cellebrite posts discuss Screen Time artifacts [8], [9]; we could not read their text, so we do not rely on them for table or file details.

Three open-source tools read the usage tables (Table 1). APOLLO ships four Screen Time modules whose metadata name iOS 12 to 14 and macOS [10]. Its timed-items module, the Plaso ios_screentime plugin [15] and the mac_apt screentime plugin [12] all select from ZUSAGETIMEDITEM and join outward to its block, device and user; we did not read the query text of the other three APOLLO modules. A file-name search of the mobile verification toolkit repository [14] at the cited commit found no Screen Time or remote-management module, and iLEAPP [7] had none before the artifacts described here. We found no published parser that reads the configuration tables, the installed-app list, the persistent history or the ManagedSettings stores; the search was not exhaustive.

2.5 Validating forensic tools

Horsman argues that forensic tool testing needs checks that expose a tool's assumptions [11]. We use two such checks: counts from independent SQL, and comparison of the same database read under two treatments of its log.

Position of this work. The guidance and the parsers share one assumption: that the usage tables are where the evidence is. We test that assumption on current releases, read the parts of the store that no public parser presents, and measure how much the treatment of the log changes the answer. Section 4.7 sets the shape of their query against what the stores hold.

3 Study Design

This section describes the evidence, how we read it, the artifacts that make the reading repeatable, and the checks.

3.1 Evidence

We use four classes of evidence (Table 2). All results that quote “of 17” are from set R, the recount set. Set P, the stores on which the artifacts were built and reviewed, is reported separately and never added to set R, because the overlap of the two sets cannot be established: only the iOS 26.6 and 26.6.2 stores of set P can be matched with set R, by identical counts, and the others are no longer on disk. The counts for set P come from the artifact notes and from the release description of the artifacts [2], which speaks of eight real devices for usage; we could not reconcile that number with the seven stores of set P. Ten full file system extractions of the collection match the releases of set P (one each of iOS 26.2.1, 26.5.2, 26.6 and 26.6.2, six of 26.3.1), and a comparison of hashed device identifiers shows that all ten are different phones, so the seven stores come from seven phones if each came from a different extraction. The stores are no longer on disk, so their source extractions cannot be confirmed.

3.2 Reading the stores

For each full file system archive we extracted the Local and Cloud database files with their -wal and -shm files to a scratch folder and opened the copies read-only in SQLite through a short script that uses no code of the artifacts. Entity names were taken from Z_PRIMARYKEY. We counted the rows of each table and, in ACHANGE, the change rows by entity and by change type (insert 0, update 1, delete 2). For deletes of the installed-app entity we took the first tombstone value as the identifier and compared the set of such identifiers with the identifiers in the same store's live list. Identifiers are used for counting only and are never reported.

To measure the effect of the log we repeated the counts on a second copy of the main file alone, with no -wal or -shm file (Listing 1). We call the first copy the store with the log applied, which is the store as it stands, and the second the main file alone.

The reference for every count is the stored data: the independent SQL counts and the archive listings. The Screen Time flag on a store is a stored value, not a record of use.

3.3 Parser artifacts

The measurements run alongside ten artifacts (Table 3). An artifact is a parser module that presents one kind of record as a table [7]. Ours report what the store held as stored: flags as Yes or No with a blank for no value, Core Data dates converted to UTC, and no verdicts. The Screen Time passcode is reported as present or absent and the value is never read. Columns whose meaning we could not establish are shown as stored and labelled undefined. Notes in each artifact name the data it was tested on and what was not covered. The note of the Usage artifact was written before any store with usage rows was available and still describes the artifact as “unverified on real data”; its counts have since agreed with independent SQL on the four stores of Section 4.2 that hold usage rows (check C1), but the note has not yet been revised.

3.4 Checks

We ran five checks.

1. C1 Agreement. Row counts of the eight file system artifacts, produced by the parser suite's command-line tool, equal the independent SQL counts on every store (the Usage artifact is compared with the sum of its three tally tables).
2. C2 Log effect. Counts with the log applied against counts in the main file alone (Section 3.2).
3. C3 Tombstones. Tombstone identifiers against the live installed-app list of the same store.
4. C4 Usage-rooted reading. The join that starts at the timed-item table, as the three public parsers do (Section 2.4), written by us in SQL and counted per store. C4 states what a reading of that shape returns.
5. C5 Sysdiagnose structure. The structure of an iOS 26.6 sysdiagnose, counted from the archive listing, against the counts recorded for the ManagedSettings artifacts.

3.5 Tools and versions

The artifacts as released (commit in Artifact Availability) under Python 3.13; SQLite 3.50.4 through the Python sqlite3 module for the recounts; archive listings with zipfile and tar. Public tools were examined as source: APOLLO at commit bd725461 (December 2020), the Plaso and mac_apt plugins as on their default branches on 27 October 2026, and the mobile verification toolkit at commit 3ba15716.

4 Results

Usage is the exception in these stores, and on most stores the counts depend on the log. Table 4 answers each research question; the subsections give the evidence.

4.1 What the stores hold

Configuration is the only content common to all stores (Figure 1). Every one of the 17 stores held one settings row, and all but one held a blueprint; the always-allowed-apps blueprint was present on 16. The Cloud store held no installed-app, usage or user rows on any of the 17, and held persistent-history transactions on five. Beyond the single-row configuration the stores differ widely (Figure 2, Table 5): eleven held an installed-app list, twelve held history transactions, eight held installed-app delete tombstones and four held usage rows. Four stores (one iOS 18.5, one iOS 26.2, one iOS 26.3.1 and one iOS 26.6) hold nothing but the singleton configuration, so on them no table beyond that configuration returns rows.

4.2 Usage tables (RQ1)

Usage tables held rows on four of the 17 stores (Table 6): the three iOS 15 to 17 stores and one iOS 26.4.2 store, which also holds 1,654 counted items. They were empty on the iOS 18.5 store and on 12 of the 13 iOS 26 stores.

The tables hold a recent window. From the first block to the last, the populated stores span 4, 17, 20 and 29 days; the store with 476 blocks spans 20 days. Persistent history shows why the windows are short. On the four populated stores the history records 4,587, 654, 30,347 and 5,941 inserts and 4,321, 352, 37,261 and 112 deletes of usage entities. Usage rows are written continuously and removed again, which is consistent with a rolling window, although the history does not say what rule removes them.

The flag does not predict rows. One reading of the empty stores is that the feature was off. The stored Screen Time flag was on for seven of the 13 iOS 26 stores, and usage was empty on six of those seven. Over all 17 stores the flag was on for ten: usage was present on four of them and empty on six, all iOS 26. On the three iOS 15 to 17 stores the flag was on and all three hold usage rows; on the iOS 18.5 store it was off and the tables were empty.

The one populated iOS 26 store is also the one configured store. A second reading is that rows require a configuration. The populated iOS 26 store is the only one of 17 whose organization-settings row holds a passcode value, and the only one with usage-limit blueprints (nine rows), downtime blueprints (two) and managed-user blueprints (two). This is consistent with a store on which Screen Time limits had been set and a passcode used; it is a single store.

Notes written during artifact development recorded usage as empty on every store of set P. That was true of those stores; set R shows that it is not true in general.

4.3 The write-ahead log (RQ2)

All 17 stores came with a -wal file of 0.6 to 4.0 MB, and reading the main file alone changed at least one counted table on 14 of them (Table 7). The change goes both ways (Figure 3). On the iOS 17.6.1 store the main file alone holds 441 usage blocks where the store as it stands holds 78; on the populated iOS 26.4.2 store it holds 354 where the store holds 476. On three iOS 26 stores the settings and user tables are empty in the main file and filled only through the log. One iOS 18.5 store shows one history transaction in the main file and none with the log applied. The size of the difference ranges from a single row to several hundred, and we make no claim that it will be the same on another device.

4.4 Installed-app list and tombstones (RQ3)

The installed-app list (ZINSTALLEDAPP) held 3 to 539 rows on 11 stores (median 108). The display-name column was empty on every row examined in set P, so the identifier is the only name. The list is one that Screen Time keeps; the data do not show that it records when an app was installed or removed. In set P the list had 336 rows on one store and 21 on another, and none on three.

The persistent history of eight stores holds 218 delete entries for installed-app rows, which cover 207 distinct identifiers when counted per store. Of those 207, 173 (84 percent) are absent from the live list of the same store and 34 (16 percent) are present in it. The history thus keeps identifiers that the list no longer holds, which is the property useful to an examiner, and it also keeps identifiers that the list holds again: an entry records that the row was deleted at some point, not that the app left the phone. In set P the artifact notes record 158 delete entries covering 90 distinct identifiers on two stores whose installed-app list was empty, and 20 covering 17 on a third. Delete entries of every kind numbered 4,135, 4,151 and 1,733 on three stores of set P, most of them of usage entities.

4.5 Configuration

The single configuration row discriminates poorly between stores: the settings row exists on all of them, and the cloud-sync and family-setup flags were off or empty on most. Blueprints hold declaration payloads. In set P five declaration types were seen: a policy type for always-allowed applications (on every store), an application-store type, an iCloud type, an iCloud account policy type and a date-and-time type, each of the last four on one store only. In Apple's public schema repository a configuration declaration type is named after its file [3], and none of the five type strings matches a file name there at the cited commit. File contents were not searched, so the five types are undocumented in that repository by name only, and the payloads cannot be decoded from the public schema. The passcode columns were empty on 16 of 17 stores; the artifact reports presence only.

4.6 ManagedSettings in sysdiagnoses and on the file system (RQ4)

The sysdiagnose artifacts read 13 property lists on iOS 27.0 and 12 on iOS 26.6 (Table 8). The store names differ between the two releases (Figure 4): five on iOS 26.6, eight on iOS 27.0, two in common (Default and UserSafety). The files carry no time, so no row says when a setting was set. The recount of the iOS 26.6 sysdiagnose from its archive listing found seven store files, four caller files and one effective-settings file, 12 property lists in all, as recorded for the artifact. The artifact notes record that on two further iOS 26 sysdiagnoses from a public corpus the only keys were Safari history and private-browsing denial keys, user-safety caller keys, scanning-policy keys and a device-activity caller key, with no app-installation, web-content or shield key.

The file system holds a live copy. Fifteen of the 17 stores carry a store listing in SettingRecords.plist; the iOS 15.6 and 16.1.2 stores do not. Table 9 gives the names. One name embeds a Core Data object address of a blueprint configuration, which links the settings store to the Screen Time database. The iOS 17.6.1 and 18.5 stores list only Default and UserSafety; SafariStore appears from iOS 26.1. The names on the iOS 26.6 store are a subset of those of the iOS 26.6 sysdiagnose, which comes from a different device. The file system artifacts do not read this live copy.

4.7 Validation

Row counts of the eight file system artifacts equalled the independent SQL counts on all 17 stores, 8 × 17 = 136 of 136 (C1; Table 10). When the artifacts were first run on real stores of set P they exposed a schema error: timed usage items reach their block through the category row, not through a block column of their own. The review of the contribution recorded the same agreement with independent counts on the stores of set P [2].

A usage-rooted reading (C4) returns rows on 4 of 17 stores and none on 13. Of those 13, nine hold installed-app rows or history that such a reading does not show; the other four hold only the singleton configuration. C4 describes the shape of the public parsers' query, not their output on our stores.

5 Discussion

The results change what an examiner can say from this store and how a tool should read it. This section draws four lessons.

5.1 An empty usage table says nothing about use

On the stores we hold, a Screen Time database is more often a configuration and history store than a usage store. Empty usage tables are the common state on the iOS 18.5 and iOS 26 stores, so they support no statement about use, and a stored Screen Time flag that is on does not predict usage rows either. The statement the data support is narrower: the store held no usage rows when the extraction was taken, and the persistent history, where present, shows whether usage rows had been written and removed. A missing row does not show that an app or a limit never existed.

5.2 A tombstone records a deletion, not a removal

A delete entry in the history, with an identifier, records that a row with that identifier was removed from the list. Because 16 percent of the identifiers are also in the live list, the entry must not be read as removal of an app from the phone. It is useful for the other 84 percent: it shows an identifier that the live list does not hold. The positions of the tombstone values follow the store's data model, which we did not read, so we name only the first value and only for the installed-app entity.

5.3 Every reading should state whether the log was applied

A copy that omits the log reports the store as it stood at an earlier checkpoint. On 14 of 17 stores it reports something different, in both directions, so no rule such as “the main file has more” holds. The mechanism is documented for SQLite [17], but the effect here is not minor: the whole configuration was missing from the main file on three stores. Examiners and tools that read a database should state whether the log was applied. Where history is trimmed, a main file read alone may also hold transactions that the live store no longer holds, as on the iOS 18.5 store.

5.4 Relation to prior work and a missing file

The public parsers [10], [12], [15] target the usage chain and were written against iOS 12 to 14. Our usage results on iOS 15.6, 16.1.2 and 17.6.1 agree that these tables carry data for those releases; we add the contrast on iOS 18 and 26 and the other content of the store. One further observation concerns extraction. One full file system archive listed the daemon's folders and a second database in a system container, but not the Screen Time database file. Absence of the store in an extraction is therefore not absence of Screen Time, and an examiner should record that the file was missing, not that there was nothing to find.

6 Threats to Validity

Internal validity. The artifacts and the recount SQL were written by the same author, so agreement shows that the artifacts report what the tables hold, not that the tables mean what we think. The tombstone counts use the first tombstone value as the identifier; the data model was not read to confirm which attribute it is. The log comparison used two copies; opening a copy lets SQLite checkpoint it, which we avoided for the main-file-only copy by leaving the log and shared-memory files out.

Construct validity. A row is a record the store held, not proof of a user action; we did not observe the actions that produced these records, so no row is tied to a known action. The Screen Time flag, the platform value and the family flags are shown as stored and their meaning is not established. Usage windows are measured from block start times and say nothing about when the extraction was taken. Identifiers of different stores are counted per store, so 207 is not a count of distinct apps over all stores.

External validity. The sample is 17 stores from iPhones of unknown usage: one store each for iOS 15 to 18 and the rest from iOS 26. The iOS 26 usage result rests on one populated store, and the explanation offered for it (limits and a passcode configured) rests on that store alone. The sample includes no iPad, no macOS, no iOS 19 to 25, and no store from a device known to run a child profile. The 17 stores come from 17 different phones: a comparison of hashed device identifiers found no two of the collection’s iPhone extractions to be one phone, apart from one same-day pair of iOS 16.1.2 extractions of which only one holds a store. Set P overlaps set R in a way that cannot be established.

Conclusion validity. No statistical inference is made; percentages describe the sample only. Confidence is moderate for what the stores hold and for the write-ahead-log effect, which rest on direct counts, and low for how often a feature is used and for what the stored flags mean, because 17 stores of unknown usage are not a sample of a population.

Limitations. The Core Data model was not read, so the tombstone positions are not named, and the daemon's second database was not studied.

Reproducibility. The fixtures are synthetic and released with the code; the real-data results can be checked only by someone with comparable images.

7 Conclusion and Future Work

On 17 iPhone stores, Screen Time usage rows were found on 4, so the usage-centred advice describes the iOS 15 to 17 stores and one configured iOS 26 store, not most of the iOS 18 and iOS 26 stores we hold. What those stores keep is configuration, an installed-app list and persistent history with deletion tombstones. Reading the database without its write-ahead log changes the answer on most stores, and the ManagedSettings stores in sysdiagnoses use names that differ between iOS 26.6 and 27.0. Reading the store beyond its usage tables, and stating whether the log was applied, are practices that any parser of this store can adopt, open-source parsers included. What remains open is whether the usage result on iOS 18 and 26 holds on more stores, and what the stored flags and tombstone values mean.

Future work, in order of importance: (1) more iOS 18 and iOS 26 stores from research devices, including stores that hold usage-limit and managed-user blueprints, to test the configured-store explanation; (2) iPad, macOS and iOS 19 to 25, to test the claims on other releases and platforms; (3) reading the Core Data model so that tombstone values and the stored flags can be named, and reading the live ManagedSettings copy and the daemon's second database; (4) revising the note of the Usage artifact, which still describes it as unverified on real data, now that four stores with rows exist.