.fullScreenCover(isPresented: $isShow) { Button(action : { isPresented.toggle() }){ Text("Choose") } .familyActivityPicker( isPresented: $isPresented, selection: $selection) .onChange(of: selection){ value in } } In the official version of iOS 18, when I click the Done button of familyActivityPicker, the fullScreenCover pop-up box will disappear.

I have developed three apps using the Screen Time API. The following are common problems I encountered in the three apps: DeviceActivityMonitorExtension is automatically killed after running for a few days (frequently) The same DeviceActivityEvent in DeviceActivityMonitorExtension is triggered twice during eventDidReachThreshold (especially obvious in iOS18.5) Screen Time authorization is automatically canceled for no reason (occasionally) I hope to get help

How to programmatically check if ApplicationToken or ActivityCategoryToken is expired in FamilyActivityPicker? I'm building a Screen Time-based parental control app using FamilyControls and ManagedSettings. We use FamilyActivityPicker to allow the user to select apps and categories to restrict, and we apply the shield using: store.shield.applications = .specific(selection.applicationTokens) store.shield.applicationCategories = .specific(selection.categoryTokens) Sometimes, we observe that the shield silently fails to apply — no error is thrown, but the restrictions aren't enforced. I suspect this may be due to expired or invalid tokens, possibly if the app was removed or the selection became stale. My Questions: Can ApplicationToken or ActivityCategoryToken expire or become invalid over time? If yes, is there a supported or recommended way to detect whether a token is still valid before applying it to the shield? Is comparing the current shield values (store.shield.applications and store.shield.applicationCategories) after applying them a reliable validation method? What's the best practice to handle expired tokens (e.g. re-prompt the FamilyActivityPicker, or show a fallback)? What Is the Expiration Duration of Tokens from FamilyActivityPicker? Any guidance or insight from the Screen Time/FamilyControls team would be greatly appreciated! Thank you!

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!

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.

Hi there, My app uses all the Screen Time API's with individual FamilyControls authorization. I've been using the API's for over 2 years (since they came out). In iOS 18 Beta (maybe started in Beta 3?), I've been experiencing random issues. I tracked it down to where it seems like DeviceActivityMonitor extension is more likely to deadlock in iOS 18. To reproduce: when DeviceActivityMonitorExtension.intervalDidEnd gets called, IF you call DeviceActivityCenter.startMonitoring for that SAME DeviceActivityName from the DeviceActivityMonitorExtension , the startMonitoring call deadlocks (if I pause debugger, it does not advance past DeviceActivityCenter.startMonitoring). The bug is reported in FB14664238. It also contains a sample project where you can reproduce this. I also note in the comment section that this is not the only way to encounter this problem. My application code (which is a lot more complicated) seems to deadlock on calling DeviceActivityCenter.activities. As a result, there seems to be an "overall trend" where, due to some changes, DeviceActivityMonitor extension is more likely to deadlock. The steps are not reproducible on iOS 17.6. This is built using Xcode 17.4. Thank you! 🙏

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

Apple Feedback Ticket: FB16804936 Background We develop a parental control application called Adora Kids (https://apps.apple.com/us/app/adora-kids/id6443787669) that requires "Location Always" permission to function properly. Our app has Screen Time authorization and provides monitoring services for parents. Issue We are experiencing a recurring problem where child users receive the system notification "Adora accessed your location in the background" every few days. This frequently results in children disabling location permissions, which prevents our app from functioning as intended. Current Approach and Limitations We have explored using Content & Privacy Restrictions for Location Services as a potential solution, but have encountered two significant limitations: These restrictions cannot be accessed programmatically via the ManagedSettings framework (unlike AppStoreSettings and other restrictions). The current implementation is "all-or-nothing" - enabling location restrictions blocks permission changes for ALL apps on the device, preventing children from granting legitimate location access to other applications. Questions Is there a way to programmatically access and manage Content & Privacy Restrictions for Location Services through the ManagedSettings framework that we might have overlooked? Are there any recommended approaches for apps with Screen Time authorization to prevent users from changing specific permissions (particularly location) while still allowing them to manage permissions for other apps? Does Apple have plans to implement app-specific permission locking for apps with Screen Time authorization in future iOS releases? Are there any alternative approaches or workarounds that other developers have successfully implemented for this use case? Any guidance from the developer community or Apple engineers would be greatly appreciated. This is a critical functionality issue affecting the reliability of our parental control service. Thank you in advance for your assistance.

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.

I requested the Family Controls Entitlement last week and haven’t heard back at all. I’ve submitted the request three times now, but I haven’t received a confirmation, a case number, or even an acknowledgment that it was received. I called Apple Support, but they said they have no visibility into the entitlement request process, which leaves me completely in the dark. I just want to know if my request is under consideration or not. This is especially frustrating because I’ve had strong engagement on social media around my app, and I have stakeholders waiting for updates. Right now, I can’t send the app for review, and I can’t even distribute it via TestFlight to internal testers. Honestly, I didn’t expect this kind of radio silence from Apple. Has anyone else experienced this when requesting entitlements?

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.

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?

I'm currently running into an issue during the App Store review process where my reviewer isn't liking how the Screen Time API is being used to hide apps. For some context, my app uses the Managed Settings and Device Activity frameworks in the Screen Time API to allow users to set restrictions on their personal devices and save those restrictions into a preference object that they can switch between. This was detailed as my app's primary purpose in my Family Controls & Personal Device Usage Entitlement Request, which was approved last year. After around a year of working on this app, it's finally done and ready for submission to the App Store. However, my App Reviewer recently rejected the app with this single complaint: Guideline 2.5.1 - Performance - Software Requirements The app uses public APIs in an unapproved manner, which does not comply with guideline 2.5.1. Specifically, your app uses ScreenTime API to hide apps. Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, unapproved uses of public APIs in apps is not allowed. Next Steps Please revise the app to ensure that documented APIs are used in the manner prescribed in the documentation. All I'm doing is passing a set of Application objects to ManagedSettings.ApplicationSettings.blockedApplications, I'm not doing anything special. The documentation for this API itself states: The system hides blocked applications and prevents the user from launching them. In my reply, I let the reviewer know Regarding Guideline 2.5.1, I believe my use of the Screen Time API appears to align with Apple's documented intended functionality. The specific API I'm using, ManagedSettings.ApplicationSettings.blockedApplications, is explicitly documented by Apple as: "The system hides blocked applications and prevents the user from launching them." This is why I used the term "hide" in my app's marketing and functionality descriptions - I was directly referencing Apple's own terminology for this feature. The documentation clearly indicates this is an approved capability of this API. The source for this documentation can be found here: https://developer.apple.com/documentation/managedsettings/applicationsettings/blockedapplications-swift.property. I've also provided a screenshot of this documentation below. Despite providing a link to the documentation and a screenshot that shows the text from Apple explicitly stating "The system hides blocked applications", the App Reviewer just copy-and-pasted the same text in their reply and rejected the app. I should also note that we don't have control over how the system handles the Application set we pass into ManagedSettings.ApplicationSettings.blockedApplications, the system will always try to "hide" these apps as specified in the documentation. We can't change this behavior. Has anyone else faced this sort of rejection before? Is using ManagedSettings.ApplicationSettings.blockedApplications now considered an illegal use of the API? Or are we not allowed to use the words noted in the documentation of this API? The app rejection suggested I "consult with fellow developers and Apple engineers on the Apple Developer Forums." Any guidance here would be much appreciated as I continue to appeal this. For any Apple staff members reading this post, I can provide the Submission ID of the App Review privately if needed to help resolve this issue.

I’m developing a self-management app using Family Controls, but I’ve encountered a FamilyActivityPciker's crash due to an XPC(or UIRemoteView) issue when there are too many tokens(maybe 200+ items) in a category. This makes bad UX, so I’m looking for a workaround. (I guess that the crash reason is cross process memory limitations, such as App Extension 50MB memory limitation.) A lot of web domains contribute to increase the number of tokens, However, even after clearing Safari’s browsing history, the tokens displayed in the FamilyActivityPicker remains unchanged. Is there any workaround that a 3rd party developer can implement to address this issue? prevent FamilyActivityPicker crashes or reduce the number of web domain tokens? For example, if there’s a way to reset the web domain tokens shown in FamilyActivityPicker from the Settings app, I could offer a help to users. Does anybody have ideas? Expanding SNS Category (29 items) It succeeded. Expanding Productivity & Finance (214 items) It failed. The screen froze, then appears blank. When the number of items is around 100, the crash rate is 50%, but when the items are over 200, the crash rate is 100%. Search Bar Problem The search bar also has same problem. If the number of search results are small, it works good without any blank, but if there are a lot of search results (200+), the XCP crashes and the screen appears blank. Code to Reproduce import SwiftUI import FamilyControls struct ContentView: View { @State private var selection = FamilyActivitySelection() @State private var isPickerPresented: Bool = false var body: some View { VStack { Button("Open Picker") { isPickerPresented = true } } .familyActivityPicker(isPresented: $isPickerPresented, selection: $selection) } } Steps to Reproduce Prepare a category that has 200+ items Try to open the category in the picker The screen will freeze, then appears blank. Errors in Console [u EDD60B83-5D2A-5446-B2C7-57D47C937916:m (null)] [com.apple.FamilyControls.ActivityPickerExtension(1204)] Connection to plugin interrupted while in use. AX Lookup problem - errorCode:1100 error:Permission denied portName:'com.apple.iphone.axserver' PID:2164 ( 0 AXRuntime 0x00000001d46c5f08 _AXGetPortFromCache + 796 1 AXRuntime 0x00000001d46ca23c AXUIElementPerformFencedActionWithValue + 700 2 UIKit 0x0000000256b75cec C01ACC79-A5BA-3017-91BD-A03759576BBF + 1527020 3 libdispatch.dylib 0x000000010546ca30 _dispatch_call_block_and_release + 32 4 libdispatch.dylib 0x000000010546e71c _dispatch_client_callout + 20 5 libdispatch.dylib 0x00000001054765e8 _dispatch_lane_serial_drain + 828 6 libdispatch.dylib 0x0000000105477360 _dispatch_lane_invoke + 408 7 libdispatch.dylib 0x00000001054845f0 _dispatch_root_queue_drain_deferred_wlh + 328 8 libdispatch.dylib 0x0000000105483c00 _dispatch_workloop_worker_thread + 580 9 libsystem_pthread.dylib 0x0000000224f77c7c _pthread_wqthread + 288 10 libsystem_pthread.dylib 0x0000000224f74488 start_wqthread + 8 ) Error acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2 "Specified target process does not exist" UserInfo={NSLocalizedFailureReason=Specified target process does not exist}>

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.

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?

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?

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.

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?

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!