Many apps are distributed on the public App Store. Those same apps can also be installed on company managed devices. While user enrolled devices will likely or certainly have an Apple Account on there, that is not the case for supervised devices. The company that manages the device might prohibit the use of Apple Accounts. I'd like to see a capability where the MDM can provision the device with an assurance of an age being met. In the majority of practical purposes, users enrolling devices into an MDM are likely employees due to the nature of MDM. Same for users of supervised devices. An API that lets the MDM tell the app that even though the API returns unavailable (or some new enum), that its okay to proceed because the business is assuming the risk of the age being met to consume some app. I have a feedback I wrote up last December for this FB21340165 Another idea I've played around with would be to have a fail proof way for developers to detect if the app is MDM installed, just on the regular, not related to DeclaredAgeRange API. One could look for managed app configuration via the legacy UserDefaults mechanism, or the new ManagedApp framework--but there is no guarantee that the MDM administrator is actually going to use that feature. If you're deploying an app to your company devices and employee enrolled devices, you can implement app config with a signal to the app, but for B2B apps and other businesses there is no assurance. To be clear, I'm not asking for interpretation of the regional laws as I know the FAQ page directs developers to our internal legal reps, I just want to know how to best use the DeclaredAgeRange API in the context of an MDM deployment.

es_set_deadline_miss_mode() is there going to be a way to check the deadline was missed and ES replied? what file open flags are going to be used? es_set_deadline_max_milliseconds() is there a limit for the max value? can we apply it for all event types or are there any limitations? es_set_deadline_min_milliseconds() is for ES descendants clients but the set_deadline_max version does not mention descendants in the description. Is it just missed in the description? Could you describe intended usage of the descendant ES clients a bit more, please? Are the reserved ES events (like the one for pasteboard) preparation for potential public use or are they solely intended for internal use?

Is there a setting or option from the last iOS updates that turned on stolen device protection? There seemed to be mixed results coming out from these updates that either turned this on when it was off, remained off and didn't get turned on, or had no effect (ie. it was off initally and stayed off).

Unlike almost all other system TCC prompts, the DeclaredAgeRange does not have an API to detect the current status. This makes it hard to determine when it is appropriate to show a permission flow that explains what the app does with the information. I do the workflow during onboarding, and when app features are being accessed. I would like to not just 'pop up' if the user completed onboarding on iOS 18, and then upgraded to 26 (or 27). FB21157742

The DeclaredAgeRange framework's 'actions' are not sendable. This means when the app is in swift 6 mode, the sample code provided in the documentation won't even compile due to the thread isolation. Is there any reason why the action closure in the environment can't be sendable? Otherwise @preconcurrency import for me. FB20959748

As the direct TCC.db access will be restricted, is there a recommended way to check what permissions an app is granted in real time without the need to restart for changes to take effect? How does end-user popup fatigue and complacency come to factor into your decisions to gate functionality behind TCC?

I have an ES client that tracks file activity on the system. Was I'm finding is that es_event_unlink_t events are sent when some process attempts to delete a file, but such attempts can fail, of course, due to permissions or any number of other reasons. Can you suggest ways for my client program to determine reliably whether a file was actually deleted? I suppose I could schedule a stat() or something, and assume the file was deleted if it doesn't exist (and wasn't re-created in the meantime), but it seems a bit fiddly. Am I missing anything?

For a Swift package that requires app developers to set a String API key at the app level (one key per app, not per user), what is Apple’s recommended approach for allowing those keys to be securely rotated without requiring an App Store redeploy?

I'd like to know if there is any way for an app to deep link the user to their Apple Account --> Personal Information --> Age Range for Apps screen within settings. I don't have a feedback for this (yet). The idea is simple. If a user denies sharing permission, but the app developer makes the decision to use the API to enforce their own apps terms (i.e. 16+, 18+, etc.) one would throw up a non-dismissible screen and the user is stuck. The best I have come up with is to link to Apple's support page on the Age Range for Apps feature. However, this isn't an ideal user experience and leaves a lot for the user to do. If they really want to use they can change their mind and I want to help reduce that friction. Why does this matter? From my 'non-legal' research and experimentation with this API, I have decided the easiest thing is to just check the age in all regions--use it for checking and evaluating against your apps terms of use. For example, I have a brewery app, while it won't check 21+ through the API, certainly the app is not meant to be used by minors. Aside from a few rough edges in the API, the framework is overall really well thought out. Most people I talk with about this haven't even heard of the new Apple Account setting, and the ones that think they can find it go to privacy and security in the Settings app.

Are there any plans to add Endpoint Security support for intercepting or observing listen() calls, so SIEM and EDR products can reliably monitor when processes begin accepting inbound network connections?

Would Apple provide a way to identify if the customer is from a specific State where the Age Assurance laws are in place and hence only limit the Age Range sharing data to customers from those specific States? (2) If the customer declines to share Age Range data with the app developer, would Apple impose any restrictions on what/how the customer can do or view in the app?

Are there any plans to add camera-access or camera-activation events to EndpointSecurity.framework, so security products (like SIEM/EDR) can reliably detect when applications start or stop using the camera without relying on private APIs or log monitoring?

There have been a lot of changes to the DeclaredAgeRange and PermissionKit APIs. I get it, things have to change to align with evolving regional requirements. I was surprised to not see a talk this summer about the frameworks and the new APIs, nor updated sample code. Is this something that can be done? Developers have to juggle a lot of availability checks. It would be great to have a very clear table that describes if OS version this, then API that should be used.

What is the differences between significant location services on compared to this being off? Would there be more accurate location reporting?

Hi Apple Community, Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : These can be solved if the Identity Provider implements Platform SSO , but not being implemented by all major Identity Providers Except major iDPs like Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG 
I KNOW PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDP, AND MEANINGFUL SSO TOKENS CAN BE ONLY ISSUED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed Feedback with FB23065453

Hi Apple Community & Apple Team, 
Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : All the above Problems can be solved if the Identity Provider implements Platform SSO , but not being implemented by major Identity Providers Except Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG ( Resource Owner Password Grant ) 
ITS RIGHT THAT PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDENTITY PROVIDER, AND MEANINGFUL ID TOKENS CAN BE ONLY USED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed a Feedback with ID FB23065453

As an iOS developer, what should I make sure of so users can clearly see that privacy is considered in my app?

Hey guys, I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!

We are deploying Platform SSO using the Secure Enclave authentication method. However, users are still being prompted for their username and password during registration. This undermines our goal of going passwordless and is causing deployment friction with customers. Once the Secure Enclave method is deployed and initialized, is there a way to suppress or skip this password dialog so users only authenticate via hardware/biometrics?

In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.