Prevent access to the Screen Time API without guardian approval and provide opaque tokens that represent apps and websites.

All subtopics
Posts under Family Controls topic

Post

Replies

Boosts

Views

Activity

Family Controls (Distribution) entitlement — typical review timeline?
Hello! I recently submitted a request for the Family Controls (Distribution) entitlement for my app, and I’m trying to understand what kind of timeline to expect. I’ve seen posts suggesting anywhere from a few days to over a month for approval. Is there a typical review window for this entitlement? And is there anything I can do on my end to help the process move more smoothly? Thanks in advance!
4
1
377
Feb ’26
Scheduled events reach threshold almost immediately on iOS 26.2
Hi, we are developing a screen time management app. The app locks the device after it was used for specified amount of time. After updating to iOS 26.2, we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling. The only solution we've found is to delete the app and reboot the device, but the effect is not lasting long and this does not always help. Before updating to iOS 26, events also used to sometimes fire prematurely, but rescheduling the event often helped. Now the rescheduling happens almost every second and the events keep reaching the threshold prematurely. Can you suggest any workarounds for this issue?
4
2
386
1w
Family Controls entitlement request submitted on March 9, 2026 — no response or status update
Hi, I submitted a Family Controls (Distribution) entitlement request on March 9, 2026 for my iOS app, but I still have not received any approval, rejection, or other status update. At this point, I’m mainly trying to understand: whether this waiting time is currently normal, whether there is any way to check if the request is actually under review, and whether Apple provides any follow-up if more information is needed. This is blocking my progress, because the app depends on the Screen Time / Family Controls APIs. Has anyone recently experienced similar delays, and is there any recommended next step besides waiting? Thanks. Imi
6
1
443
1w
DeviceActivityMonitor extension rejected by App Store Connect validator — NSExtensionPointIdentifier "com.apple.deviceactivity.monitor" invalid (IrisAPI -19241)
Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: "Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid." Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedded.mobileprovision inside the IPA) The binary code signature itself contains com.apple.developer.family-controls = true (verified with codesign -d --entitlements :-) Family Controls entitlement was requested and approved in the Developer Portal for both App IDs Tested with both Xcode 26.2 (iOS 26 SDK) and Xcode 16.4 (iOS 18 SDK) — same error in both cases The IPA is structurally correct. The error comes purely from Apple's server-side IrisAPI validator and does not correspond to anything I can identify or fix in the code or configuration. Has anyone successfully submitted an app with a DeviceActivityMonitor extension to App Store Connect recently? Is there a backend approval requirement for com.apple.deviceactivity.monitor beyond the standard Family Controls entitlement approval? Could this be a known validator bug for this specific extension type? Any help appreciated.
4
1
179
21h
Issue with DeviceActivityMonitor - eventDidReachThreshold Callback Not Triggering Properly
Hello, I'm currently experiencing an issue with the DeviceActivityMonitor extension in my code, specifically with the eventDidReachThreshold callback. I'm hoping to get some insights into why this problem occurs and how to resolve it. Problem: Issue 1: The eventDidReachThreshold callback is not triggering as expected. It appears that the callback is not being invoked when the threshold is reached. Issue 2: After a few seconds, the eventDidReachThreshold callback starts to trigger multiple times. This unexpected behavior is causing problems in my code, as it results in incorrect actions being taken. iOS version: iOS16.7.2 and iOS17.1 Xcode version: 15.0.1 Swift version: 5.9 Here is my code to start the monitoring: func startMonitoring() { var startTime : DateComponents = DateComponents(hour: 0, minute: 0) let endTime : DateComponents = DateComponents(hour: 23, minute: 59) /// Creates the schedule for the activity, specifying the start and end times, and setting it to repeat. let schedule = DeviceActivitySchedule(intervalStart: startTime, intervalEnd: endTime, repeats: true, warningTime: nil) /// Defines the event that should trigger the encouragement. let event = DeviceActivityEvent(applications: socialActivitySelection.applicationTokens, categories: socialActivitySelection.categoryTokens, webDomains: socialActivitySelection.webDomainTokens, threshold: DateComponents(minute: 2)) let events: [DeviceActivityEvent.Name: DeviceActivityEvent] = [.socialScreenTimeEvent : event] do { activityCenter.stopMonitoring([.socialScreenTime]) /// Tries to start monitoring the activity using the specified schedule and events. try activityCenter.startMonitoring(.socialScreenTime, during: schedule, events: events) } catch { /// Prints an error message if the activity could not be started. print("Could not start monitoring: \(error)") } } If there are any known workarounds or potential solutions, please share them. Thank you for your help in resolving this problem.
1
3
1.1k
Nov ’25
Will special entitlements like Screentime API remain valid when transferring an app?
Certain entitlements require special permission from Apple like DriverKit or Screentime API/Family controls. Those entitlements are tied to the bundle IDs of the app. If those entitlements have been granted for an app from developer A (personal account) and we transfer that app to developer B (organization account), including the bundle IDs, will those bundle IDs keep the entitlement? Or will we need to re-request from the developer account B? Any insights or experiences regarding this process would be greatly appreciated.
1
3
727
May ’25
How to open parent app from `ShieldActionDelegate`
Hello, I think it is quite a common use-case to open the parent app that owns the ShieldActionDelegate when the user selects an action in the Shield. There are only three options available that we can do in response to an action: ShieldActionResponse.none ShieldActionResponse.close ShieldActionResponse.defer It would be great if this new one would be added as well: ShieldActionResponse.openParentApp While finding a workaround for now, the problem is that the ShieldActionDelegate is not a normal app extension. That means, normal tricks do not work to open the parent app from here. For example, UIApplication.shared.open(url) does not work because we can’t access UIApplication from the ShieldActionDelegate unfortunately. NSExtensionContext is also not available in the ShieldActionDelegate unfortunately, so that’s also not possible. There are apps however, that managed to find a workaround, in my research I stumbled across these two: https://apps.apple.com/de/app/applocker-passcode-lock-apps/id1132845904?l=en-GB https://apps.apple.com/us/app/app-lock/id6448239603 Please find a screen recording (gif) attached. Their workaround is 100% what I’m looking for, so there MUST be a way to do so that is compliant with the App Store guidelines (after all, the apps are available on the App Store!). I had documented my feature request more than 2 years ago in this radar as well: FB10393561
8
3
1.8k
Nov ’25
Issues with Family Control API: App Blocking & Screen Time for Multiple Children
We are developing a parental control application in SwiftUI with features like app blocking and screen time management. We are using the Family Control API along with Apple Family Sharing, allowing parents to add multiple children to the family group. We have followed the apple documentation still we are facing following issues: App Blocking Issue: The family picker does not display each child's name separately or their apps individually. Instead, it shows all children's apps together, making it difficult to block apps for a specific child. Screen Time Data Issue: We receive the total screen time usage for all children combined rather than separate screen time data for each child. Syncing Delay: When a new child is added to the Family Sharing group, we are unsure how long it takes for their apps to sync and appear on the parent’s device.
2
3
560
Sep ’25
Family Controls extensions stuck in "Submitted"
Hi, I’m requesting the Family Controls distribution capability for my app and its extensions. The main app bundle ID was approved within 1 day. However, I later realized the associated extensions (Shield Configuration, Device Activity Monitor, Device Activity Report) also require separate approval. I submitted those extension requests 4 days ago, and they are still in "Submitted" with no updates. This is currently blocking me from proceeding with TestFlight/App Store submission, since the extensions require the approved capability. Is this delay expected for extension bundle IDs? Thanks for your help.
3
1
304
1w
Changing Screen Time Passcode does not protect apps with Screen Time enabled
Hello, The purpose of "Screen Time Passcode" under Settings/Screen Time is to protect Screen Time preferences and it is asked every time the user updates Downtime, App Limits, Content & Privacy Restrictions and so on. But the private passcode is not requested if the user disables Screen Time for a particular app (only Face ID or phone passcode is requested, but not the private Screen Time passcode). I think this is a mistake, I think the purpose of a private Screen Time passcode is to protect all settings, including apps that use this API, right? Is there any solution to this? Thank you.
6
4
4.3k
May ’25
ApplicationTokens changing
We persist ApplicationTokens in a storage container that ShieldConfigurationExtension has access to. In rare, cases all the ApplicationTokens for a user seem to change. We know this because the Application parameter passed into configuration(shielding application: Application) -> ShieldConfiguration function has a Token that does not match (using == ) any of the ones we are persisting in storage. Interestingly, the persisted ones still work, so I don't believe storage has gotten corrupted or anything. We can use them to add or remove shields, we can use them to display labels of the apps they represent, etc. But they don’t match what’s passed into the ShieldConfiguration extension. If the user goes into the FamilyPicker at this point and selects an app of a token that we are already persisting, the FamilyPickerSelection will have a token matching the new one that is passed into ShieldConfigurationExtension, not the one we persisted when they last selected that app. This leads me to believe the tokens are updated/rotated in some cases. When and why does this happen, and how can we handle it gracefully?
7
4
1.8k
Jul ’25
Screen Time APIs showing severe inconsistencies (DeviceActivity not firing + impossible usage data)
Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik
1
4
225
5d
Guidance on implementing Declared Age Range API in response to Texas SB2420
I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.
10
1
1.5k
Jan ’26
iOS 26.2 (23C55): DeviceActivity eventDidReachThreshold fires with 0 Screen Time minutes
On iOS 26.2 (23C55), DeviceActivityMonitor.eventDidReachThreshold fires intermittently for a daily schedule (00:00–23:59) even when iOS Screen Time shows 0 minutes for the selected apps that day. This causes premature shielding via ManagedSettings. Environment: iPhone 13 Pro Max, iOS 26.2 (23C55). Event selection: 2 apps. Threshold: 30 minutes. Multiple TestFlight users report the same behavior across various app selections and thresholds. Intermittent (~50% of days); sometimes multiple days in a row. Not observed in testing prior to iOS 26.2. Evidence: sysdiagnose + Screen Time screenshots (with 0 screen time on selected apps) + unified logs show UsageTrackingAgent notifying the extension that “unproductive from activity daily reached its threshold,” followed immediately by ManagedSettings shield being applied (extension reacting to the callback). Filed Feedback Assistant: FB21450954. Questions: Are others seeing this on 26.2? Does it correlate with restarting monitoring at interval boundaries or includesPastActivity settings?
5
2
973
3w
ShieldConfigurationExtension not working
I created a ShieldConfigurationExtension in Xcode 14.3 with File > New > Target > ShieldConfigurationExtension. This created the extension with all the necessary Info.plist values (correct NSExtensionPrincipalClass, etc.), with the extension included in embedded content in the host app target. No matter what I try, the extension is not getting invoked when I shield applications from my host app. The custom UI does not show as the shield, and looking at the debugger, an extension process is never invoked. I am shielding categories like this: let managedSettings = ManagedSettingsStore() ... managedSettings.shield.applicationCategories = .all() And my extension code overrides all the ShieldConfigurationDataSource functions. class ShieldConfigurationExtension: ShieldConfigurationDataSource { override func configuration(shielding application: Application) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } override func configuration(shielding application: Application, in category: ActivityCategory) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } override func configuration(shielding webDomain: WebDomain) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } override func configuration(shielding webDomain: WebDomain, in category: ActivityCategory) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } } What am I missing?
5
2
2.9k
Jun ’25
Screentime API new issues on iOS 17.4.1 and 17.5.1
Hi, I have a released screentime app ScreenZen. The last few days I've seen a disturbing spike in bug reports coming from people with 17.4.1 and 17.5.1 phones with no update to the app itself. People reported they saw the issue immediately after updating their iOS version. Unfortunately it is not replicable on all phones with those versions, so we haven't been able to replicate it on our test phones. It appears the issue is the ApplicationToken passed into ShieldActionExtension and ShieldConfigurationExtension does not match any of the ApplicationTokens that the user selected to block through FamilyControls. (The selected ApplicationTokens are being loaded through a group UserDefaults and they are indeed being loaded in the ShieldActionExtension in the bug reports).This is preventing the app from loading the correct settings and handling the blocking accordingly. I am trying to isolate this better with a new release with better logging, but would appreciate any help on this issue.
3
6
2.8k
Jul ’25
Open Parent App From ShieldActionDelegate
Hello, I’m building an app that helps people spend less time on social media apps. For that, I make heavy use of Apple’s Screen Time APIs, such as ManagedSettings and FamilyControls. When an app is locked using a ShieldConfiguration, the user has to open my app in order to unlock it (e.g. enter a code). This is very cumbersome because no documented API exists to open the parent app (=my app) from the ShieldActionDelegate (also part of my app) when the user presses a button of the ShieldConfiguration. The ShieldActionDelegate callback just offers three options in its ShieldActionResponse: .none .defer .close .openParentApp is missing. We are working around this limitation by sending a local push notification that the user has to tap on. This has multiple drawbacks: It has to be ensured that notification permission has been granted. It has to be ensured that notifications can be delivered even while focus is enabled. Features such as Apple Intelligence notification summaries and notification prioritization can heavily delay delivering notifications and thus frustrate the user. Neither my users nor myself do understand why this is not possible in a smoother way, at least according to the documentation. There are 3rd party apps that have such functionality, they can directly open their own app from a button press in the Shield, see here: https://apps.apple.com/us/app/applocker-passcode-lock-apps/id1132845904 It would be great if Apple could level the playfield for all developers and document how this is achievable, because technically it clearly is. Thanks a lot and have a great day!
6
1
720
Jul ’25
DeviceActivityReportExtension: NSExtensionPrincipalClass required by App Store but rejected at runtime
I'm experiencing a contradictory validation issue with DeviceActivityReportExtension that creates an impossible situation: The Problem: Without NSExtensionPrincipalClass in Info.plist → App Store Connect rejects upload with: "Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found" With NSExtensionPrincipalClass → Local install fails with: "defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.deviceactivityui.report-extension" Setup: Extension point: com.apple.deviceactivityui.report-extension Using SwiftUI with @main attribute and DeviceActivityReportExtension protocol Xcode 16.2, iOS 17.6 deployment target Code structure: @main struct SpoolReport: DeviceActivityReportExtension { var body: some DeviceActivityReportScene { // Report scenes here } } The extension builds and runs perfectly without NSExtensionPrincipalClass, but cannot be uploaded to App Store Connect. Adding the key allows upload but breaks local installation. Is this a known issue? Is there a workaround or correct Info.plist configuration for DeviceActivityReportExtension? Thank you!
10
2
645
3w
Tokens change without reason after updating to iOS 17.5.1
Some of our users encounter an issue after updating their iPhone/iPad to iOS 17.5.1. The tokens passed in the Shield Configuration extension don't match the tokens they selected in my app using the FamilyPicker before updating to iOS 17.5.1. It seems the tokens changed for no reason. My app can't match the token from the ShieldConfigurationDataSource to any tokens stored on my end, causing my shield screens to turn blank. The same applies to tokens in the Device Activity Report extension. The only workaround I've found is to tell affected users to unselect and reselect apps and websites to block in my app. This gets them new tokens from the FamilyActivityPicker, which solves the issue. However, for some users, the bug reoccurs a few days later. Tokens seem to change again, causing the same issue in the Shield Configuration extension. I am not able to reproduce the issue on my test devices so I have no sysdiagnose to attach. However, this issue is affecting other screen time apps: https://developer.apple.com/forums/thread/732845 https://forums.developer.apple.com/forums/thread/756440 FB14082790 FB14111223 A change in iOS 17.5.1 must have triggered this behaviour. Could an Apple engineer give us any updates on this?
27
7
3.1k
Aug ’25
Family Controls (Distribution) entitlement — typical review timeline?
Hello! I recently submitted a request for the Family Controls (Distribution) entitlement for my app, and I’m trying to understand what kind of timeline to expect. I’ve seen posts suggesting anywhere from a few days to over a month for approval. Is there a typical review window for this entitlement? And is there anything I can do on my end to help the process move more smoothly? Thanks in advance!
Replies
4
Boosts
1
Views
377
Activity
Feb ’26
Scheduled events reach threshold almost immediately on iOS 26.2
Hi, we are developing a screen time management app. The app locks the device after it was used for specified amount of time. After updating to iOS 26.2, we noticed a huge issue: the events started to fire (reach the threshold) in the DeviceActivityMonitorExtension prematurely, almost immediately after scheduling. The only solution we've found is to delete the app and reboot the device, but the effect is not lasting long and this does not always help. Before updating to iOS 26, events also used to sometimes fire prematurely, but rescheduling the event often helped. Now the rescheduling happens almost every second and the events keep reaching the threshold prematurely. Can you suggest any workarounds for this issue?
Replies
4
Boosts
2
Views
386
Activity
1w
Family Controls entitlement request submitted on March 9, 2026 — no response or status update
Hi, I submitted a Family Controls (Distribution) entitlement request on March 9, 2026 for my iOS app, but I still have not received any approval, rejection, or other status update. At this point, I’m mainly trying to understand: whether this waiting time is currently normal, whether there is any way to check if the request is actually under review, and whether Apple provides any follow-up if more information is needed. This is blocking my progress, because the app depends on the Screen Time / Family Controls APIs. Has anyone recently experienced similar delays, and is there any recommended next step besides waiting? Thanks. Imi
Replies
6
Boosts
1
Views
443
Activity
1w
DeviceActivityMonitor extension rejected by App Store Connect validator — NSExtensionPointIdentifier "com.apple.deviceactivity.monitor" invalid (IrisAPI -19241)
Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: "Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid." Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedded.mobileprovision inside the IPA) The binary code signature itself contains com.apple.developer.family-controls = true (verified with codesign -d --entitlements :-) Family Controls entitlement was requested and approved in the Developer Portal for both App IDs Tested with both Xcode 26.2 (iOS 26 SDK) and Xcode 16.4 (iOS 18 SDK) — same error in both cases The IPA is structurally correct. The error comes purely from Apple's server-side IrisAPI validator and does not correspond to anything I can identify or fix in the code or configuration. Has anyone successfully submitted an app with a DeviceActivityMonitor extension to App Store Connect recently? Is there a backend approval requirement for com.apple.deviceactivity.monitor beyond the standard Family Controls entitlement approval? Could this be a known validator bug for this specific extension type? Any help appreciated.
Replies
4
Boosts
1
Views
179
Activity
21h
Issue with DeviceActivityMonitor - eventDidReachThreshold Callback Not Triggering Properly
Hello, I'm currently experiencing an issue with the DeviceActivityMonitor extension in my code, specifically with the eventDidReachThreshold callback. I'm hoping to get some insights into why this problem occurs and how to resolve it. Problem: Issue 1: The eventDidReachThreshold callback is not triggering as expected. It appears that the callback is not being invoked when the threshold is reached. Issue 2: After a few seconds, the eventDidReachThreshold callback starts to trigger multiple times. This unexpected behavior is causing problems in my code, as it results in incorrect actions being taken. iOS version: iOS16.7.2 and iOS17.1 Xcode version: 15.0.1 Swift version: 5.9 Here is my code to start the monitoring: func startMonitoring() { var startTime : DateComponents = DateComponents(hour: 0, minute: 0) let endTime : DateComponents = DateComponents(hour: 23, minute: 59) /// Creates the schedule for the activity, specifying the start and end times, and setting it to repeat. let schedule = DeviceActivitySchedule(intervalStart: startTime, intervalEnd: endTime, repeats: true, warningTime: nil) /// Defines the event that should trigger the encouragement. let event = DeviceActivityEvent(applications: socialActivitySelection.applicationTokens, categories: socialActivitySelection.categoryTokens, webDomains: socialActivitySelection.webDomainTokens, threshold: DateComponents(minute: 2)) let events: [DeviceActivityEvent.Name: DeviceActivityEvent] = [.socialScreenTimeEvent : event] do { activityCenter.stopMonitoring([.socialScreenTime]) /// Tries to start monitoring the activity using the specified schedule and events. try activityCenter.startMonitoring(.socialScreenTime, during: schedule, events: events) } catch { /// Prints an error message if the activity could not be started. print("Could not start monitoring: \(error)") } } If there are any known workarounds or potential solutions, please share them. Thank you for your help in resolving this problem.
Replies
1
Boosts
3
Views
1.1k
Activity
Nov ’25
Will special entitlements like Screentime API remain valid when transferring an app?
Certain entitlements require special permission from Apple like DriverKit or Screentime API/Family controls. Those entitlements are tied to the bundle IDs of the app. If those entitlements have been granted for an app from developer A (personal account) and we transfer that app to developer B (organization account), including the bundle IDs, will those bundle IDs keep the entitlement? Or will we need to re-request from the developer account B? Any insights or experiences regarding this process would be greatly appreciated.
Replies
1
Boosts
3
Views
727
Activity
May ’25
How to open parent app from `ShieldActionDelegate`
Hello, I think it is quite a common use-case to open the parent app that owns the ShieldActionDelegate when the user selects an action in the Shield. There are only three options available that we can do in response to an action: ShieldActionResponse.none ShieldActionResponse.close ShieldActionResponse.defer It would be great if this new one would be added as well: ShieldActionResponse.openParentApp While finding a workaround for now, the problem is that the ShieldActionDelegate is not a normal app extension. That means, normal tricks do not work to open the parent app from here. For example, UIApplication.shared.open(url) does not work because we can’t access UIApplication from the ShieldActionDelegate unfortunately. NSExtensionContext is also not available in the ShieldActionDelegate unfortunately, so that’s also not possible. There are apps however, that managed to find a workaround, in my research I stumbled across these two: https://apps.apple.com/de/app/applocker-passcode-lock-apps/id1132845904?l=en-GB https://apps.apple.com/us/app/app-lock/id6448239603 Please find a screen recording (gif) attached. Their workaround is 100% what I’m looking for, so there MUST be a way to do so that is compliant with the App Store guidelines (after all, the apps are available on the App Store!). I had documented my feature request more than 2 years ago in this radar as well: FB10393561
Replies
8
Boosts
3
Views
1.8k
Activity
Nov ’25
Issues with Family Control API: App Blocking & Screen Time for Multiple Children
We are developing a parental control application in SwiftUI with features like app blocking and screen time management. We are using the Family Control API along with Apple Family Sharing, allowing parents to add multiple children to the family group. We have followed the apple documentation still we are facing following issues: App Blocking Issue: The family picker does not display each child's name separately or their apps individually. Instead, it shows all children's apps together, making it difficult to block apps for a specific child. Screen Time Data Issue: We receive the total screen time usage for all children combined rather than separate screen time data for each child. Syncing Delay: When a new child is added to the Family Sharing group, we are unsure how long it takes for their apps to sync and appear on the parent’s device.
Replies
2
Boosts
3
Views
560
Activity
Sep ’25
Family Controls extensions stuck in "Submitted"
Hi, I’m requesting the Family Controls distribution capability for my app and its extensions. The main app bundle ID was approved within 1 day. However, I later realized the associated extensions (Shield Configuration, Device Activity Monitor, Device Activity Report) also require separate approval. I submitted those extension requests 4 days ago, and they are still in "Submitted" with no updates. This is currently blocking me from proceeding with TestFlight/App Store submission, since the extensions require the approved capability. Is this delay expected for extension bundle IDs? Thanks for your help.
Replies
3
Boosts
1
Views
304
Activity
1w
Changing Screen Time Passcode does not protect apps with Screen Time enabled
Hello, The purpose of "Screen Time Passcode" under Settings/Screen Time is to protect Screen Time preferences and it is asked every time the user updates Downtime, App Limits, Content & Privacy Restrictions and so on. But the private passcode is not requested if the user disables Screen Time for a particular app (only Face ID or phone passcode is requested, but not the private Screen Time passcode). I think this is a mistake, I think the purpose of a private Screen Time passcode is to protect all settings, including apps that use this API, right? Is there any solution to this? Thank you.
Replies
6
Boosts
4
Views
4.3k
Activity
May ’25
ApplicationTokens changing
We persist ApplicationTokens in a storage container that ShieldConfigurationExtension has access to. In rare, cases all the ApplicationTokens for a user seem to change. We know this because the Application parameter passed into configuration(shielding application: Application) -> ShieldConfiguration function has a Token that does not match (using == ) any of the ones we are persisting in storage. Interestingly, the persisted ones still work, so I don't believe storage has gotten corrupted or anything. We can use them to add or remove shields, we can use them to display labels of the apps they represent, etc. But they don’t match what’s passed into the ShieldConfiguration extension. If the user goes into the FamilyPicker at this point and selects an app of a token that we are already persisting, the FamilyPickerSelection will have a token matching the new one that is passed into ShieldConfigurationExtension, not the one we persisted when they last selected that app. This leads me to believe the tokens are updated/rotated in some cases. When and why does this happen, and how can we handle it gracefully?
Replies
7
Boosts
4
Views
1.8k
Activity
Jul ’25
Screen Time APIs showing severe inconsistencies (DeviceActivity not firing + impossible usage data)
Hi everyone, I’m the developer of one sec, an app used by a large number of users globally to reduce time spent on social media and to build healthier digital habits. Because of this, we rely heavily on Apple’s Screen Time / DeviceActivity / FamilyControls, ManagedSettings APIs – and unfortunately, we’re seeing increasingly severe issues in production that directly impact hundreds of thousands of real iOS users. During the past years, we have been busy filing dozens of feedback requests for different Screen Time issues – and there has been no response from Apple at all. Developer Relations might be able to "confirm" that the bugs are present and that they ended up with the right team – but they are never addressed, neither are workarounds provided. Instead, the situation gets worse and worse. iOS 26 introduced a series of heavy regressions (which have been reported via Apple’s official bug report tool "Feedback Assistant" on iOS 26 beta 1 in June 2025 – and have not been addressed 10 Months later). This is very frustrating for us as developers, but also for our end-users who run into these issues every day. In the end this impacts our ability to build an amazing product and hurts revenue (which affects both us and Apple). 1. DeviceActivity thresholds are not firing at all This affects both: our app’s usage of the API and Apple’s own Screen Time limits Radars: FB22304617, FB20526837, FB15491936, FB12195437, FB15663329, FB18198691, FB18289475, FB19827144 2. Screen Time usage data is clearly corrupted Websites showing hundreds of hours per week Up to ~20 hours per day of usage reported for a single domain Radars: FB22304617, FB17777429, FB18464235 3. DeviceActivity thresholds reaching threshold immediately Newly introduced with iOS 26 Reported on iOS 26 beta 1 in June No response so far / no workaround DeviceActivity calls didReachThreshold immediately after creating the DeviceActivityEvent – instead of waiting till the defined threshold is actually reached. Radars: FB13696022, FB18351583, FB21320644, FB18927456, FB18061981 4. Randomly Randomizing ApplicationTokens From time to time, and without consistency, Screen Time suddenly provides new, random, unknown tokens to my app in the ShieldConfigurationDataSource and ShieldActionDelegate. This has been reported on many times before here on the dev forms, many many years back already: https://forums.developer.apple.com/forums/thread/756440 https://forums.developer.apple.com/forums/thread/758325 https://forums.developer.apple.com/forums/thread/758325?answerId=793267022#793267022 Radars: FB14082790 and FB18764644 5. Moving Tokens from one ManagedSettingsStore to Another Removing an ApplicationToken from one SettingsStore and then adding it to another while the target app remains in foreground leads to the re-use of the ShieldConfiguration. Which can be wrong in many scenarios. It is not possible to request a re-request of the ShieldConfiguration in that scenario. Radar: FB14237883 6. Unable to Open Parent App (one sec) from Shield Many times, when a target app is blocked by a shield, the user wants to perform some action (e.g. to unlock more time for the target app via an intervention). That means, that somehow I have to forward the user from a ShieldActionDelegate back into my target app. Unfortunately, there’s no API for that. Many apps on the App Store rely on private API to achieve that, but that’s too risky for a popular app like one sec. Radar: FB15079668 7. Unable to Open Target App from an ApplicationToken When a user has completed an intervention within one sec, and they indend to to continue to the target app, there is no way that one sec can open the target app just from the token alone. Sure, there are URL schemes, but that means the user has to manually assign URL schemes to each ApplicationToken. That is not a very user friendly process (and in many cases impossible, because not every app registers URL schemes). It would be better if there was a way that my app could open a target app directly from an ApplicationToken, e.g. via an AppIntent that can be run on a button press. This way, the selected apps would remain fully private while still offering advanced functionality: struct OpenTargetAppIntent: AppIntent, OpenAppFromApplicationTokenIntent { func perform() { return .result(openAppFromApplicationToken: applicationToken) } } Radar: FB15500695 Summary Thanks a lot for taking the time to read my feedback. If you have any questions, please feel free to reach out to me any time. I’m always happy to provide more details, logs, and steps to reproduce in my radars / feedback requests or in-person in Cupertino. It would be extremely helpful if someone from the Screen Time / DeviceActivity engineering team could: Take a look at the listed radars. Work on bug fixes and be transparent about when fixes will be shipped. Provide workarounds in the meantime. We genuinely want to build great, reliable experiences on top of Screen Time – but in its current state, it’s becoming very difficult to depend on. – Frederik
Replies
1
Boosts
4
Views
225
Activity
5d
Guidance on implementing Declared Age Range API in response to Texas SB2420
I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.
Replies
10
Boosts
1
Views
1.5k
Activity
Jan ’26
iOS 26.2 (23C55): DeviceActivity eventDidReachThreshold fires with 0 Screen Time minutes
On iOS 26.2 (23C55), DeviceActivityMonitor.eventDidReachThreshold fires intermittently for a daily schedule (00:00–23:59) even when iOS Screen Time shows 0 minutes for the selected apps that day. This causes premature shielding via ManagedSettings. Environment: iPhone 13 Pro Max, iOS 26.2 (23C55). Event selection: 2 apps. Threshold: 30 minutes. Multiple TestFlight users report the same behavior across various app selections and thresholds. Intermittent (~50% of days); sometimes multiple days in a row. Not observed in testing prior to iOS 26.2. Evidence: sysdiagnose + Screen Time screenshots (with 0 screen time on selected apps) + unified logs show UsageTrackingAgent notifying the extension that “unproductive from activity daily reached its threshold,” followed immediately by ManagedSettings shield being applied (extension reacting to the callback). Filed Feedback Assistant: FB21450954. Questions: Are others seeing this on 26.2? Does it correlate with restarting monitoring at interval boundaries or includesPastActivity settings?
Replies
5
Boosts
2
Views
973
Activity
3w
Xcode 26.4 Beta 2 - Missing Capability, Family Controls App & Website Usage
Hi One of the new Family Control API's requires the new "Family Controls App & Website Usage" capability but it appears to be missing in the latest Xcode beta (26.4 B2). MacOS and iOS all running 26.4 Beta 3. Does anyone know if we have to wait for Xcode 26.4 Beta 3 and it's associated SDK's for this one to become available?
Replies
3
Boosts
2
Views
116
Activity
3w
ShieldConfigurationExtension not working
I created a ShieldConfigurationExtension in Xcode 14.3 with File > New > Target > ShieldConfigurationExtension. This created the extension with all the necessary Info.plist values (correct NSExtensionPrincipalClass, etc.), with the extension included in embedded content in the host app target. No matter what I try, the extension is not getting invoked when I shield applications from my host app. The custom UI does not show as the shield, and looking at the debugger, an extension process is never invoked. I am shielding categories like this: let managedSettings = ManagedSettingsStore() ... managedSettings.shield.applicationCategories = .all() And my extension code overrides all the ShieldConfigurationDataSource functions. class ShieldConfigurationExtension: ShieldConfigurationDataSource { override func configuration(shielding application: Application) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } override func configuration(shielding application: Application, in category: ActivityCategory) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } override func configuration(shielding webDomain: WebDomain) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } override func configuration(shielding webDomain: WebDomain, in category: ActivityCategory) -> ShieldConfiguration { return ShieldConfiguration( backgroundBlurStyle: UIBlurEffect.Style.systemThickMaterial, backgroundColor: UIColor.white, icon: UIImage(systemName: "stopwatch"), title: ShieldConfiguration.Label(text: "You are in a Present Session", color: .yellow) ) } } What am I missing?
Replies
5
Boosts
2
Views
2.9k
Activity
Jun ’25
Screentime API new issues on iOS 17.4.1 and 17.5.1
Hi, I have a released screentime app ScreenZen. The last few days I've seen a disturbing spike in bug reports coming from people with 17.4.1 and 17.5.1 phones with no update to the app itself. People reported they saw the issue immediately after updating their iOS version. Unfortunately it is not replicable on all phones with those versions, so we haven't been able to replicate it on our test phones. It appears the issue is the ApplicationToken passed into ShieldActionExtension and ShieldConfigurationExtension does not match any of the ApplicationTokens that the user selected to block through FamilyControls. (The selected ApplicationTokens are being loaded through a group UserDefaults and they are indeed being loaded in the ShieldActionExtension in the bug reports).This is preventing the app from loading the correct settings and handling the blocking accordingly. I am trying to isolate this better with a new release with better logging, but would appreciate any help on this issue.
Replies
3
Boosts
6
Views
2.8k
Activity
Jul ’25
Open Parent App From ShieldActionDelegate
Hello, I’m building an app that helps people spend less time on social media apps. For that, I make heavy use of Apple’s Screen Time APIs, such as ManagedSettings and FamilyControls. When an app is locked using a ShieldConfiguration, the user has to open my app in order to unlock it (e.g. enter a code). This is very cumbersome because no documented API exists to open the parent app (=my app) from the ShieldActionDelegate (also part of my app) when the user presses a button of the ShieldConfiguration. The ShieldActionDelegate callback just offers three options in its ShieldActionResponse: .none .defer .close .openParentApp is missing. We are working around this limitation by sending a local push notification that the user has to tap on. This has multiple drawbacks: It has to be ensured that notification permission has been granted. It has to be ensured that notifications can be delivered even while focus is enabled. Features such as Apple Intelligence notification summaries and notification prioritization can heavily delay delivering notifications and thus frustrate the user. Neither my users nor myself do understand why this is not possible in a smoother way, at least according to the documentation. There are 3rd party apps that have such functionality, they can directly open their own app from a button press in the Shield, see here: https://apps.apple.com/us/app/applocker-passcode-lock-apps/id1132845904 It would be great if Apple could level the playfield for all developers and document how this is achievable, because technically it clearly is. Thanks a lot and have a great day!
Replies
6
Boosts
1
Views
720
Activity
Jul ’25
DeviceActivityReportExtension: NSExtensionPrincipalClass required by App Store but rejected at runtime
I'm experiencing a contradictory validation issue with DeviceActivityReportExtension that creates an impossible situation: The Problem: Without NSExtensionPrincipalClass in Info.plist → App Store Connect rejects upload with: "Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found" With NSExtensionPrincipalClass → Local install fails with: "defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.deviceactivityui.report-extension" Setup: Extension point: com.apple.deviceactivityui.report-extension Using SwiftUI with @main attribute and DeviceActivityReportExtension protocol Xcode 16.2, iOS 17.6 deployment target Code structure: @main struct SpoolReport: DeviceActivityReportExtension { var body: some DeviceActivityReportScene { // Report scenes here } } The extension builds and runs perfectly without NSExtensionPrincipalClass, but cannot be uploaded to App Store Connect. Adding the key allows upload but breaks local installation. Is this a known issue? Is there a workaround or correct Info.plist configuration for DeviceActivityReportExtension? Thank you!
Replies
10
Boosts
2
Views
645
Activity
3w
Tokens change without reason after updating to iOS 17.5.1
Some of our users encounter an issue after updating their iPhone/iPad to iOS 17.5.1. The tokens passed in the Shield Configuration extension don't match the tokens they selected in my app using the FamilyPicker before updating to iOS 17.5.1. It seems the tokens changed for no reason. My app can't match the token from the ShieldConfigurationDataSource to any tokens stored on my end, causing my shield screens to turn blank. The same applies to tokens in the Device Activity Report extension. The only workaround I've found is to tell affected users to unselect and reselect apps and websites to block in my app. This gets them new tokens from the FamilyActivityPicker, which solves the issue. However, for some users, the bug reoccurs a few days later. Tokens seem to change again, causing the same issue in the Shield Configuration extension. I am not able to reproduce the issue on my test devices so I have no sysdiagnose to attach. However, this issue is affecting other screen time apps: https://developer.apple.com/forums/thread/732845 https://forums.developer.apple.com/forums/thread/756440 FB14082790 FB14111223 A change in iOS 17.5.1 must have triggered this behaviour. Could an Apple engineer give us any updates on this?
Replies
27
Boosts
7
Views
3.1k
Activity
Aug ’25