We adopted the "com.apple.developer.family-controls.app-and-website-usage entitlement" to read usage through "DeviceActivityData.activityData(filteredBy:using:)" after "approvedWithDataAccess". It works as documented. We want to clarify the exclusivity issues. The consent sheet says, under "Limited Access", that Screen Time "will lose access to this data as only one app or service can access it at a time." On our test devices that is exactly what happens: after allowing, the Screen Time pane in Settings shows no new usage until the app is toggled off under Apps with Screen Time Access. Is this intended as permanent design, and is there any supported way for a third-party app and Apple's Screen Time to hold the data simultaneously?

Hi Apple Developer Support, I’m developing an iOS app that uses FamilyControls, ManagedSettings, and DeviceActivity. My app requests Screen Time authorization with: try await AuthorizationCenter.shared.requestAuthorization(for: .individual) Issue: On my development-installed build, AuthorizationCenter.shared.authorizationStatus becomes .approvedWithDataAccess, and the app can display usage data. However, after installing the App Store / App Store Connect distribution build, the same device and same flow returns .approved instead of .approvedWithDataAccess. As a result, the app only treats the authorization as management access, not usage-data access. App details: App name: App时记 Main bundle ID: com.qteqpid.appstop Device Activity Monitor extension: com.qteqpid.appstop.AppStopMonitorExtension Device Activity Report extension: com.qteqpid.appstop.AppStopReportExtension Version/build tested: 2.0 (4) Team ID: 5N6B48T57B What I verified: I exported an App Store Connect IPA from Xcode Organizer on September 3, 2026 and inspected the actual signed entitlements with codesign. The main app and both Screen Time extensions all include: com.apple.developer.family-controls = true com.apple.developer.family-controls.app-and-website-usage = true com.apple.security.application-groups = group.com.qteqpid.appstop get-task-allow = false The DistributionSummary.plist also shows Apple Distribution signing and App Store provisioning profiles for the main app and both extensions. Question: Given that the App Store Connect distribution IPA appears to contain the app-and-website-usage entitlement on the main app and both extensions, what conditions would cause AuthorizationCenter.shared.authorizationStatus to return .approved instead of .approvedWithDataAccess for an .individual authorization? Is there an additional distribution-side approval, App ID setting, provisioning support setting, device state, or Screen Time privacy limitation that can prevent .approvedWithDataAccess even when the signed entitlements are present? I would appreciate guidance on how to verify why data access is not granted in the App Store/TestFlight environment. Thank you.

Hello, I’m looking for some guidance regarding an App Store review that has been taking significantly longer than expected. Our app, SafeKnot, was originally submitted on August 20, 2026 at 20:24. Shortly after submission, we received an automated App Review message indicating two issues: The app uses Screen Time APIs and needed the Family Controls entitlement. The app offers auto-renewable subscriptions but the App Store metadata was missing a functional Terms of Use (EULA) link. We addressed both issues: The required Family Controls entitlement/configuration was completed. The Terms of Use information was added correctly. We then resubmitted the app for review. Since the resubmission, the app has remained in “In Review” status for several days, and we have not received any additional questions, rejection messages, or requests for information from App Review. We also contacted Apple Developer Program Support and received the following case number: Case ID: 20000149485605 Could an Apple engineer or App Review representative please advise whether the submission is still progressing normally, or whether there may be an issue preventing the review from proceeding? We do not want to cancel and resubmit the app unnecessarily, as it is already in the review process. Thank you very much for your help.

Does anybody know if Apple allows for apps to access a user’s applicationa’ usage data? As a part of an app idea I have I need to see What is the screen time of each user on each app (Not only mine). Is it possible?

Hello, Apple Developer Technical Support directed me to the Developer Forums for clarification on the following Family Controls use case. DTS reference: Case-ID 21723677 I am evaluating an iOS app called “Zone” before beginning full development. I would like to determine whether the proposed architecture is considered permitted individual device management for focus and productivity, or prohibited use “in organizational settings” under Section 3.3.3(P) of the Apple Developer Program License Agreement. Proposed architecture: Zone is offered to companies as a workplace focus and productivity service. The app is installed on an adult employee’s personally owned iPhone. Participation and each Focus Session are voluntary. The employee independently requests Family Controls authorization using individual authorization. Only the employee can select the apps and websites to restrict. Only the employee can start or stop a Focus Session. During the session, Zone applies restrictions locally on that employee’s iPhone using Family Controls and Managed Settings. The employer cannot authorize or revoke Family Controls access. The employer cannot select restricted apps or websites. The employer cannot remotely start, stop, or schedule a Focus Session. The employer cannot remotely manage or control the employee’s device. Zone would not provide the employer with: Screen Time or Device Activity data App or website tokens App usage history Website browsing history Information about attempts to open restricted apps Location, messages, photos, or other personal device information However, Zone would include a company web dashboard. The dashboard would show only an app-generated boolean status for each participating employee: Zone ON: the employee has voluntarily started a Focus Session Zone OFF: the employee has not started a Focus Session This status is generated by the Zone app itself. It is not derived from Screen Time usage data and does not indicate whether the employee actually attempted to use any restricted app or website. My questions are: Would this architecture be considered permitted individual device management for focus and productivity, even though the service is offered through an employer and the employer can see the Zone ON/OFF status? Or would the employer relationship and company dashboard make this prohibited use of Family Controls “in organizational settings”? If sharing the app-generated ON/OFF status with the employer is incompatible with the Family Controls terms, would the use be permitted if Family Controls operated entirely on-device and no Focus Session status or device information were sent to the employer? Is there another Apple-supported framework or architecture recommended for this use case? I understand that final entitlement approval and App Review decisions may depend on the submitted application. I am seeking architectural guidance before investing in implementation. Thank you.

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

I'm about to start losing all my phone's biome data and my mind with it. I need help from guru engineers. Hope someone could help me. Published Biome research covers reading the SEGB artifacts, but I can't find anything on sync/sync.db and the merge logic. Hoping someone here has looked at it. Setup: iPhone16 Pro on iOS 26.6 paired with a MacBook Air on macOS 26.6. Same Apple ID. Reading my own devices, read-only. What happened My Macbook stopped receiving phone's in_focus biome stream after a large tombstone purge. In ~/Library/Biome/sync/sync.db, table CRDTLocation has rows of (stream, site, day, state). For my iPhone's AppLaunch stream there is a contiguous band of 27 days, 30 June to 29 July, with state = 4. Every other day is state = 2. Other streams on the same device have bands of only 1-2 days. Data behaviour lines up exactly with that band: -every day at or below 29 July: the phone offers batches, zero records ever land -every day after 29 July: records land normally, but only 2-3 per hour, the gap is widening every day. I am now on the 1st of Aug. -14 out of 14 date buckets observed over a week follow this, no exceptions Media.NowPlaying on the same phone has its own state=4 day at 23 July, and it has delivered nothing since 22 July. Over a week it re-offered ~8,900 records spanning 21 June to 16 July, all refused, and it never offers anything dated after its 23 July mark, even though newer data exists on the phone. The 27-day band was created on 30 July: two tombstone segments written over 6 seconds at 08:14 UTC containing ~18,000 deletion records covering 2-24 July. On the Mac those days now show 0 live records and several thousand dead slots. TombstoneBookmark still points at that segment. Questions What do CRDTLocation.state values mean? I'm fairly confident 4 = deleted and 2 = present/known, since days marked 2 sync fine including ones with no data yet. Is that right, and are there other values? Is the refusal rule what it looks like: an incoming batch is dropped if its day is at or below the highest state=4 day for that (stream, site)? Is the comparison meant to be inclusive? Is a tombstone for a day supposed to bar re-delivery of the entire day permanently, or only the specific records that were deleted? Mine appears to bar everything, including records that were never deleted. Is there any supported way to clear a state=4 band, or reset the sync relationship for one stream, without erasing the device? Has anyone seen a tombstone burst like this, ~18,000 deletion records in under 6 seconds while both devices were idle? Normal pruning on my device is ~700/day. Is there a known trigger? Would it be possible to repoint tombstone bookmark manually? The source records still exist on the phone but Biome retention is ~28 days, so they age out within days... please help Thank you!

Our app — a screen-time / focus app — has had no App Review activity for two weeks, and we believe the trigger was an automated Guideline 2.5.1 check that froze an otherwise actively progressing review. (This forum account is linked to the developer account in question; we can provide the App ID, bundle IDs, submission IDs, and support case numbers through any private channel on request.) Context: Jul 2–5: Our first submission (Version 1.0.0) was under active review. We went through several ordinary metadata / paywall-related iterations, and the reviewer responded within roughly 24 hours each time. Nothing related to Screen Time was raised in these human reviews of builds 9 and 10. Jul 8: After we submitted build 11 — which addressed the remaining human-review feedback — we received an automated Guideline 2.5.1 (Performance: Software Requirements) message stating that the app uses the Screen Time API but has not been submitted with the Family Controls entitlement, and that review of the submission cannot proceed. All reviewer activity stopped at that point, and there has been none since. What we verified: The Family Controls (Distribution) entitlement is granted to our account and assigned to all four bundle IDs (the main app plus its DeviceActivityMonitor, ShieldAction, and ShieldConfiguration extensions). We verified with codesign that com.apple.developer.family-controls = true is present in the code signature and embedded provisioning profile of every one of the four executables in the submitted IPA — so the entitlement named in the automated message is present in the flagged build. For context: builds 9 and 10, with an identical Screen Time API surface and identical entitlements (verified at the binary level with nm against the submitted artifacts), had been human-reviewed on Jul 2–5 with no Screen Time-related objection. We recognize those builds may simply not have reached the automated analysis stage before being superseded, so we do not draw firm conclusions from that. What we did anyway (build 12, submitted Jul 9): In case the automated check actually concerns the separate com.apple.developer.family-controls.app-and-website-usage entitlement (which we do not request and do not need), we removed every reference from our main app to the APIs associated with it: AuthorizationStatus.approvedWithDataAccess, ManagedSettings.Application.bundleIdentifier, ManagedSettings.Application.localizedDisplayName, ManagedSettings.ActivityCategory.localizedDisplayName, and ManagedSettings.WebDomain.domain. We verified with nm that none of the four executables in the build 12 IPA reference these APIs. The app does not use FamilyActivityData, DeviceActivityReport, app usage events, web usage events, or App and Website Usage data access. No automated message has appeared for build 12. What has happened since: Jul 9–14: No reviewer activity on build 12. We filed an expedited review request and opened two Developer Support cases (Jul 8 and Jul 14). No response to any of them. Around Jul 15: Hoping to clear the frozen state, we cancelled and resubmitted the same Version 1.0.0 / build 12. Around Jul 17: Filed a second expedited review request for the new submission. Jul 22 (today): The new submission has been in "Waiting for Review" since Jul 15, with no reviewer activity and no reply to either support case or either expedite request. What we are asking: Could someone check whether the Jul 8 automated flag is still attached to the app record and blocking reviewer assignment, and help get the current submission assigned to a reviewer? If the automated check flags build 12 again, could the message specify which entitlement and which binary / API references triggered it, so we can address it precisely? We can provide codesign output, entitlement plists, provisioning profile dumps, and nm symbol listings on request. Thank you.

Hey everyone,I’m running into a deeply frustrating structural bug with the redesigned Screen Time menus in the iOS beta, and I wanted to see if anyone else has found a workaround (or is facing the same thing).In previous iOS versions, if a site was blocked by the filter, you could hit "Allow Website," enter your code, and go on with your day. It didn't permanently log itself into your settings.In this beta, the system acts like a strict binary engine. The second you manually approve a site or click "Allow Anyway," that URL is permanently added to a list. There is no swipe-to-delete option anymore. You are completely locked into either choosing "Always Allow" or "Never Allow" for that URL. There is literally no middle ground or way to just remove it from the menu entirely.To make it worse, I have tried literally everything: disabling Screen Time, turning off tracking, and I even went as far as doing a full Reset All Settings. Guess what? The list was still there. It seems to be pulling straight from an iCloud ghost-sync loop that ignores local device overrides.Has anyone successfully forced these URLs to delete, or are we completely at the mercy of Apple patching this database design flaw in a future beta build?

With the declining literacy rates I think it would be incredibly valuable for apple to implement a separate keyboard experience for minors. One without auto or predictive text, swipe to text, or even potentially also voice memos. These are all very convenient features that I think could unfortunately contribute or even enable the literacy crisis as more and more children grow up and rely on technology. I also think bringing back the ‘look up’ tool on highlighted text into the main options would support and encourage more education (or even adding a thesaurus option as well) From: A Gen Z adult who grew up learning how to spell at the same time I learned how to text. Without relying on all of the convenience features that in turn can remove the mental friction that learning to fix your mistakes provides, my iPhone was teaching me how to spell with simple red lines that required me to interact with my spelling in order to correct my mistakes. Note: Autocorrect was still a feature at the time however was often turned off by most people because of text slang culture which coincidentally helped create more intentional spell check interactions. I believe the decision to turn off autocorrect should be considered a more conscious responsibility so it should not necessarily be left up to a child to decide for themselves.

I am the developer of a screen time awareness app currently on the App Store. It uses the Family Controls and DeviceActivity frameworks, with the distribution entitlement approved, to show users their own cumulative screen time since install. All tracking today is fully on-device and nothing leaves the user's phone. I am planning an optional social feature and I want to confirm Apple's position before building it, because I want to stay clearly within the Developer Program License Agreement, specifically Section 3.3.3(P) regarding data received through the Family Controls framework. Here is how the feature would work: The app monitors the user's own device activity via DeviceActivityMonitor threshold events. This is the same mechanism the app already uses for its on-device counter. On-device, that counter is converted into an abstracted, gamified score. The score is not expressed in hours, minutes, or any unit of time, and the app never displays it as time. If, and only if, the user opts in to the feature, the app uploads a self-chosen username, the date the user's count began, and the user's abstracted score values to my backend. Score values may be computed over different time windows, for example a lifetime score alongside daily, weekly, or monthly scores, but they are all the same abstraction: no raw time totals, no per-app or per-category data, no contacts, and no identifiers beyond what the account itself requires. Friends who have mutually opted in see each other's usernames and scores on a leaderboard. The app never displays another person's screen time, and no time values are stored server-side. The feature is off by default, data is encrypted in transit and at rest, and users can delete their account and all associated data from within the app at any time. The privacy policy will disclose all of this. My question: does transmitting this opt-in, abstracted score, derived on-device from DeviceActivity threshold events, comply with DPLA Section 3.3.3(P) and the intended use of the Family Controls framework? If this specific design is not acceptable, is there any form of opt-in social comparison feature that would be, and what constraints would it need to satisfy? I am aware of earlier threads here where sending screen time data off-device was flagged as non-conforming, which is exactly why I am asking before writing any code rather than after. I would rather design this correctly from the start than risk a rejection later. Thank you for your time. Happy to provide any additional detail about the design.

Title: Screen Time displaying unresolved app entry — blank icon, no developer/category metadata, not present in iPhone Storage, persists after factory reset Device/OS: iPhone 16 Plus / iOS 26 (latest) Description: Screen Time is showing daily usage for an app entry with no resolvable identity: • Icon: blank/wireframe placeholder (does not render) • Category: “Other” • Age Rating: “No Rating” • Developer: listed as “Apple” (appears to be a fallback default, not accurate) • Daily usage: ~2 minutes total, averaging 34s/day, logged in short discrete intervals (e.g. 38s from 10–11AM, 1 min from 11AM–12PM, 1 min 12PM–1PM) Steps taken to rule out causes: 1. Checked Settings → General → iPhone Storage — this app/entry does not appear anywhere in the installed apps list. 2. Checked Screen Time → Add Limit → Categories, Apps, and Websites → Edit List — entry still shows with blank icon and no name text. 3. Set a 1hr/day limit with “Block at End of Limit” enabled — the block does not appear to enforce. 4. Confirmed the entry does not appear under Mac or Apple Watch Screen Time activity — only on iPhone. 5. Performed a full factory reset with no backup restore (clean setup) — the entry still appeared with new activity the following day, ruling out leftover local data from before the reset. 6. Confirmed fresh activity is still being logged day-to-day, ruling out a stale/orphaned record from a previously deleted app. Expected behavior: Screen Time should either resolve the app’s real name/icon/developer from its bundle metadata, or if the entry has no corresponding installed app, it should not continue generating new daily usage intervals with an unresolvable identity. Actual behavior: Persistent unidentified usage entry with no way to determine which process is generating it, and App Limits set against it do not appear to block anything. Impact: Cannot identify what is generating this usage, cannot verify Screen Time limits are functioning against it, and cannot rule out it being tied to a background process/extension not visible through standard iOS UI. Related known issues: This may be conn

I'm building a consumer iOS app that helps users be more intentional about opening distracting apps. It never hard-blocks; it only nudges. I have Family Controls (Distribution) approved and a working TestFlight build using FamilyControls / DeviceActivity / ManagedSettings. I've confirmed from testing and the forums that: ShieldActionResponse is only .none / .defer / .close (no supported way to open my main app from the shield extension — threads 719905, 793060). ShieldConfiguration is a static snapshot (no countdown/animation; FB14237883). DeviceActivityMonitor events are threshold/schedule based and cannot hook "the app was just opened," and on iOS 26 eventDidReachThreshold fires immediately/incorrectly (thread 808470). I'd like to confirm the supported approaches for these UX patterns (each = every-app-open vs on-a-schedule): On app open, present my own full-screen UI (a brief non-blocking "pause") without requiring the user to manually create a Shortcuts personal automation. Is there any supported API for this, or is a user-created Shortcuts automation the officially recommended path? On app open, deliver a local notification (rather than UI) — supported only via a user-created Shortcuts automation, or is there another way? On a schedule / at fixed intervals, automatically bring my app's UI to the foreground (e.g., re-show a screen every N minutes) — I believe this is not allowed (apps can't self-foreground); can you confirm, and is a user-tapped notification the only path? On a schedule / at fixed intervals, send repeating local notifications while a usage limit is exceeded — given the iOS 26 eventDidReachThreshold regression, what's the recommended way to reliably detect "over limit" and drive repeating reminders? Some third-party apps appear to open their main app from a shield/monitor context. Is there any supported mechanism enabling that which I may have missed? I'd rather build on a supported path than risk anything review-sensitive. Guidance (or where to file an enhancement request) is appreciated. Thank you.

Hi everyone, I am currently working on a specialized analytics and time-tracking application, and I am trying to find a reliable way to detect which app the user currently has open in the foreground in real-time. On Android, this is typically handled via Accessibility Services or UsageStats, but I am well aware of iOS’s strict sandboxing rules and privacy protections. So far, I have researched and tested a few workarounds, but none perfectly fit the use case: Screen Time API (FamilyControls / DeviceActivity): This is fantastic for blocking apps or getting daily aggregate usage, but it does not provide real-time callbacks or the bundle ID of the app currently on the screen. MDM (Mobile Device Management): Requires enterprise enrollment and wiping the device, which isn't feasible for a consumer-facing app. ReplayKit (Broadcast Extension): We are currently utilizing RPBroadcastSampleHandler to screen record the device and using OCR and Core ML to visually identify the app (e.g., detecting the YouTube UI). However, this is incredibly resource-intensive and pushes the 50MB Jetsam limit for extensions. My Question: Is there any official API, restricted entitlement, or system notification (like NSWorkspace.shared.frontmostApplication on macOS) that allows a background process to simply read the bundleID of the active foreground app on iOS? If not, is ReplayKit combined with OCR or Machine Learning truly the only way to detect what app a user is actively viewing on iOS without a jailbreak? Thank you in advance for any insights!

Hi, I’m using FamilyControls + DeviceActivity. Users select apps/categories/web domains via FamilyActivitySelection. I need to show today’s total usage for that selected group only, not the device’s full Screen Time. Setup: A visible DeviceActivityReport shows today’s per-app list with a daily DeviceActivityFilter for the selected tokens. This visible list is usually accurate and updates quickly. A separate hidden DeviceActivityReport uses the same filter to compute an aggregate total by summing app.totalActivityDuration in makeConfiguration(representing:). The extension sends that total to the main app via notify_set_state + Darwin notification. DeviceActivityMonitor is only used as a fallback. Problem: The visible app list stays current, but the aggregate total for the same selected apps sometimes lags by several minutes or updates only after new selected-app usage occurs. Sometimes the total appears temporarily frozen while the app list still looks correct. Questions: Is a hidden DeviceActivityReport a supported way to compute a selected-app aggregate total? Is makeConfiguration expected to run often enough for a near-live total? Why would the visible per-app report update while a hidden report with the same filter does not? What is the recommended architecture for a reliable, non-inflated today total for selected apps only? Thanks!