In my app I want to integrate a personilized Lock Screen. Does anybody know how that works?

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.

The Problem The Family Activity Picker shows only the child's app categories on the guardian's/parent's device. The application names from the child's device are not showing on the guardian's/parent's device. The authorization is done on the child's device via try await AuthorizationCenter.shared.requestAuthorization(for: .child) Usage of the family activity picker on the guardian's/parent's device struct ContentView: View { @State private var isPresented = true @StateObject private var familyControlsHelper = FamilyControlsHelper.shared var onClose: () -> Void var body: some View { ZStack { Color.black.opacity(0.1).ignoresSafeArea() } .familyActivityPicker( isPresented: $isPresented, selection: $familyControlsHelper.familyActivitySelection ) .onChange(of: isPresented) { _ in if !isPresented { onClose() } } } } IMPORTANT Both devices are real (not simulators), and the app has granted distribution Family Controls entitlement. Question Is this the expected behavior? Or the child's app should appear on the guardian's device? Thanks.

I'm stuck in an impossible situation with DeviceActivityReportExtension on iOS 18. THE ISSUE: Configuration that works on device (iOS 18.2): Info.plist has only NSExtensionPointIdentifier Swift code uses u/main attribute App installs and runs perfectly Extension works correctly App Store validation FAILS: "Missing NSExtensionPrincipalClass" Adding NSExtensionPrincipalClass (as validation requests): Device installation FAILS with Error 3002 Error says: "NSExtensionPrincipalClass key is not allowed for this extension point" Cannot test on device Validation would likely pass ENVIRONMENT: Xcode 16.2 iOS 18.2 Extension point: com.apple.deviceactivityui.report-extension EVIDENCE IT'S WIDESPREAD: Apple Forums (3 days ago): https://developer.apple.com/forums/thread/812380 Stack Overflow (1+ year): https://stackoverflow.com/questions/77866230/ ROOT CAUSE: iOS 18 changed this extension to use u/main pattern (no NSExtensionPrincipalClass needed). App Store validation hasn't been updated and still expects iOS 17 configuration. WHAT I'VE TRIED: ✅ All deployment targets set to iOS 18.3 ✅ Code follows Apple's WWDC 2022 guidance ✅ All entitlements correct ✅ Info.plist validated ✅ Clean builds ✅ Works perfectly on device No configuration satisfies both device runtime AND App Store validation. Has anyone successfully uploaded an app with DeviceActivityReportExtension to TestFlight on iOS 18? Any workarounds? This is blocking TestFlight deployment completely.

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

A screen time app I'm making has started telling users that their limit was reached even when they're far below their limit for the day (sometimes even at 0 minutes for the day). This issue only started happening after upgrading my software to iOS 26.2. Is this happening to anyone else? If so how have you found any solutions or does anyone know of any changes that could be causing this? Any help would be appreciated.

Hi everyone, I'm hoping someone can share their experience or offer advice on entitlement request timelines. I previously had two bundle IDs approved for an app I'm testing via TestFlight - both were approved within a few days. I recently submitted a request for a third bundle ID (JMSHRM8W5J), and after realizing I may not have included enough detail, I submitted a follow-up request (XS2QYC59UU) with more context. It's now been almost three weeks, which is significantly longer than my earlier approvals - though I recognize some of that time included the holidays. A few questions for the community: Has anyone experienced longer wait times for additional entitlements on an existing project (with approved entitlements)? Did submitting a second request help or potentially slow things down? Is there anything I should include in a request to improve chances of quick approval? Any insight would be appreciated. Thanks!

Since the iOS 26.2 update, we have been experiencing anomalous behavior with the DeviceActivityMonitor extension when utilizing the ScreenTime API. Specifically, we are receiving the eventDidReachThreshold event within a few minutes of initiating monitoring, despite configuring a high usage limit. The process of turning off Screen Time -> restarting the device -> turning on Screen Time does not work. Any ideas? Thanks Filed Feedback Assistant: FB21560904

Hello, I'm experiencing a significant delay getting the Family Controls entitlement approved for my Shield Configuration Extension, and I'm hoping someone here can help or has experienced something similar. Background: I'm developing an app that uses the Screen Time API with Family Controls. My main app bundle (lukedev.Bloka) was approved for Family Controls (Distribution) and works perfectly. The Problem My Shield Configuration Extension (lukedev.Bloka.Shield) has been stuck waiting for approval for over 2 weeks: Request ID: 6C8LD22UVM Submitted: November 20, 2025 Status: Still "Submitted" Current State: Only shows "Family Controls (Development)" in capabilities What I've Tried ✅ Submitted entitlement request via the proper channels ✅ Contacted Apple Developer Support (case #102762028251) ✅ Verified the main app has full Family Controls approval ✅ Deleted and regenerated all provisioning profiles multiple times ✅ Confirmed the App ID configuration is correct in the Developer Portal The Issue Without Family Controls (Distribution) approval for the Shield extension, I cannot: Test the complete app functionality on physical devices Submit the app to App Store Connect Move forward with development The error I'm getting during provisioning: Provisioning profile failed qualification Profile doesn't include the com.apple.developer.family-controls entitlement Questions Has anyone experienced multi-week delays for Shield extension entitlements? Is this normal? Should Shield extensions automatically inherit entitlements from the main app, or do they really require separate approval? The documentation isn't clear on this. Are there any known workarounds to test Shield Configuration Extensions during development while waiting for distribution approval? How can I escalate this request? Developer Support initially told me I already had approval (for the main app) but didn't address the extension's separate bundle ID. Technical Details Xcode: 16.2 Target: iOS 18+ Main App: Family Controls (Distribution) ✅ Approved Shield Extension: Family Controls (Development only) ❌ Stuck Why This Matters The Shield Configuration Extension is a core component of Screen Time API apps - it's not optional. Without it, the app cannot properly display blocking interfaces. The fact that it requires a separate 2+ week approval process (after the main app was already approved) seems like a significant oversight in Apple's review process. Has anyone successfully navigated this situation or found a way to expedite the review? Any help or insights would be greatly appreciated! Thanks, Luca

General: Forums topic: Family Controls Forums tag: Family Controls Configuring Family Controls documentation Requesting the Family Controls entitlement documentation Screen Time Technology Frameworks documentation FamilyControls documentation What's new in Screen Time API video Meet the Screen Time API video

We're building a parental control app using FamilyControls (.child authorization). Our architecture: Parent sends pause command → Firestore + FCM Child receives push → NotificationService Extension triggers main app Main app sets ManagedSettings Shields Problem: If child disables Notifications in Settings and force-quits the app, we cannot enforce Shields. What we've tried: Firestore Realtime Listener (works only when app is running) DeviceActivityMonitor (intervalDidStart/End only triggers at schedule boundaries, eventDidReachThreshold requires explicit app selection via FamilyActivityPicker) Question: Is there a recommended approach for parental control apps to reliably enforce Shields when the child has disabled notifications? Or is this a known limitation?

Issue: The search functionality in FamilyActivityPicker has disappeared on iPadOS 26.0+. This feature was working in previous versions but is now missing. Framework: FamilyControls Expected: Search bar should be available in FamilyActivityPicker to help users find apps quickly. Actual: Search functionality is completely missing. Impact: Makes app selection difficult for users with many installed apps. Is this a known issue? If it's a bug, please address it in an upcoming update. If intentional, guidance on alternatives would be appreciated. Thank you.

Hello! I am experiencing some strange bugs around DeviceActivityEvents: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold is called. includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26? Only workaround I have found is to ask users to re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed. Feedback filed under: FB18061981 FB18927456

Hi everyone, I submitted this feature request through Apple’s Feedback Assistant and wanted to share it here, because many families run into the same issue and Apple prioritizes features based on the number of reports they receive. Current limitation: Screen Time only allows one single Downtime period per day for child accounts. For families with separate school hours and bedtime, this is very impractical. My real-world use case: • Downtime 1: 08:00–13:00 (school) • Downtime 2: 20:00–06:00 (bedtime) Both serve completely different purposes, but are not possible to combine with the current system. My suggestions to Apple: Support multiple Downtime periods per day for child accounts. Allow custom exceptions per Downtime block (e.g., allow Phone app). Provide more flexibility overall for families using Screen Time. If you would benefit from this too, it would be great if you could submit the same request via the Feedback app – the more reports Apple receives, the higher the chance for implementation. My Feedback ID: FB21265678 Thank you! 🙏 Hallo zusammen, ich habe über die Feedback-App einen Vorschlag an Apple eingereicht und wollte ihn hier teilen, weil viele Familien dasselbe Problem haben und Apple mehr Rückmeldungen braucht, um das Thema zu priorisieren. Aktuelles Problem: In Bildschirmzeit kann für Kinder aktuell nur eine einzige Auszeit pro Tag eingerichtet werden. Für Familien mit getrennten Schul- und Schlafenszeiten ist das extrem unpraktisch. Mein Anwendungsfall: • Auszeit 1: 08:00–13:00 (Schule) • Auszeit 2: 20:00–06:00 (Schlafenszeit) Beides erfüllt unterschiedliche Zwecke, ist aber nicht kombinierbar. Mein Vorschlag an Apple: Mehrere Auszeiten pro Tag für Kinderaccounts. Pro Auszeit eigene Ausnahmen festlegen (z. B. Telefon erlauben). Allgemein mehr Flexibilität im Screen-Time-System für Familien. Wenn ihr das ebenfalls hilfreich findet, wäre es super, wenn ihr es auch über die Feedback-App meldet – je mehr, desto besser. Feedback-ID meines Vorschlags: FB21265678 Danke euch! 🙏

Is it possible to change the title "Choose Activites" and also remove the search on the FamilyActivityPicker?

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.

class ShieldActionExtension: ShieldActionDelegate { override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) { // Handle the action as needed. switch action { case .primaryButtonPressed: if let url = URL(string: "blockfocusapp://") { let extensionContext = NSExtensionContext() extensionContext.open(url, completionHandler: nil) } // completionHandler(.defer) case .secondaryButtonPressed: let userDefaults = UserDefaults(suiteName: "group.in.appsquare.FocusApp.shieldExt") userDefaults?.set(false, forKey: "shouldOpenMainApp") completionHandler(.defer) @unknown default: fatalError() } } override func handle(action: ShieldAction, for webDomain: WebDomainToken, completionHandler: @escaping (ShieldActionResponse) -> Void) { // Handle the action as needed. completionHandler(.close) } override func handle(action: ShieldAction, for category: ActivityCategoryToken, completionHandler: @escaping (ShieldActionResponse) -> Void) { // Handle the action as needed. completionHandler(.close) } } I want to be able to open my app from ShieldActionExtension

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

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

Hello, I’m running into an issue with the Family Controls (Distribution) entitlement not being included in my App Store Connect provisioning profiles. Here’s the situation: •Both my main app and its Screen Time extension have been approved for Family Controls (Distribution) In Certificates, Identifiers & Profiles → Identifiers, I can clearly see that the capability Family Controls (Distribution) is enabled for both App IDs. However, when I generate a new provisioning profile (either manually or via Xcode), the resulting .mobileprovision file’s Entitlements section does not include the Family Controls (Distribution) entitlement. As a result, building for distribution or archiving fails to recognize that entitlement, even though everything looks correct in the Developer Portal. But the missing entitlement persists. How can I successfully generate a distribution provisioning profile that includes Family Controls (Distribution)? Thanks in advance for any guidance — this seems like a subtle configuration issue, and I’d love to hear how to get over it. I can provide the Team ID and bundle ID upon request. STEPS TO REPRODUCE I’ve tried: •Regenerating both App IDs and provisioning profiles •Revoking and re-creating distribution certificates •Cleaning derived data and re-downloading profiles from Xcode Every time, creating a profile for App Store Connect will fail to include the capabilities the app has been approved for.