Are there current plans to implement Microsoft 365 groups with Platform SSO to control administrator access in macOS 27? If so, would you be able to provide a rough estimate of when we can expect changes to be implemented by identity providers?

When a host app hasn't implemented ATT at all — which is still common in enterprise apps — what's the expected behavior for third-party SDKs that rely on tracking authorization? Should the SDK default to notDetermined handling indefinitely, or is there a recommended fallback experience?

For a third-party ads SDK embedded in host apps: the ATT authorization status is determined at the app level, but our SDK initializes before the host app necessarily calls ATTrackingManager.requestTrackingAuthorization(). What's Apple's recommended pattern for: SDK initialization that's ATT-status-agnostic at launch Receiving a callback or notification when ATT status changes post-initialization, without polling Is there a system notification or delegate pattern for ATT status changes that SDKs should be using in iOS 27? — Divya Ravi, Senior iOS Engineer

Are there any mechanisms to troubleshoot or test SiwA server-to-server notifications? I am not seeing any traffic from Apple for user account changes (e.g., revoking authorization for an app), but the URL that I have configured in my account matches my endpoint, it is available from the public internet, and other SiwA functions are working correctly. Any guidance will be appreciated.

Throughout the years I've done a few integrations at my company with an iOS Application and an identity provider. I've implemented samples with UIWebView, WKWebview, Certificate based authentication through custom URLSession implementations and lastly through ASWebAuthentication. Also I gave the SSO Extension a try, but got stuck at some point (also Apple Forum didn't give me some solution -> https://developer.apple.com/forums/thread/117747) I'm having troubles digging through the Apple resources to find the best approach for big enterprises. We make use of a MDM solution, so I was hoping to find means to 'exploit it' and don't implement any custom authenticationframework anymore. Also, granting SSO between Apps and websites is what my ideal goal would be. Could you point me to some resources that can help me or give me some guidance on which of the frameworks/SDKs to use?

Future of Behavioral Authentication on Apple PlatformsWith the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy and security challenges would need to be solved before such an approach could become practical on Apple platforms?

do you see a future where devices continuously verify a user’s identity through behavioral signals rather than discrete login events?

with the advancement of on-device ai, do you see a future where devices continuously verify a user’s identity through behavioral patterns rather than discrete authentication events such as Face ID or password entry?

With the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy, security, and battery-efficiency challenges would need to be solved before such an approach could become practical on Apple platforms?

Are there any Kerberos feature or behavior changes in macOS 27?

Hey there, I'm trying to building an iOS credential provider (ASCredentialProviderExtension, iOS 17+) that manages passkeys backed by keys generated in the Secure Enclave, attested via App Attest. My question is about the cross-device (FIDO2 hybrid / "passkey on a nearby device") flow, where a phone authenticates a sign-in initiated on a separate client device (e.g. a laptop browser). Specifically, Can a third-party credential provider serve as the authenticator in this flow, signing with its own key — or is the cross-device role reserved for iCloud Keychain? If it can, does the OS handle the BLE advertisement and tunnel/handshake on the provider's behalf? I ask because it seems like CBPeripheralManager.startAdvertising(_:) will not emit raw bytes, so an app can't emit a CTAP hybrid advert itself. If neither is supported, is there any supported API — including MDM-managed/supervised-device capabilities — for an app to act as a cross-device FIDO2 authenticator with a non-iCloud-Keychain key? Thanks!

We have a macOS app (io.formhealth.SideCore) that acts as a browser-style wrapper, embedding multiple web applications in WKWebView panes. We need the com.apple.developer.web-browser.public-key-credential entitlement so that WebAuthn/passkey flows (e.g. Google OAuth) work within the embedded webviews. The capability doesn't appear on macOS App IDs in the developer portal, and the entitlement request form at developer.apple.com/contact/request/system-extension returns "Your account can't access this page." What's the correct process to request this entitlement for a non-App-Store macOS app?

I'm trying to diagnose some issues with my AutoFill credential provider not loading on macOS. As far as I can tell I have all the entitlements and provisioning profiles correct, and ASSettingsHelper.requestToTurnOnCredentialProviderExtension() returns true with the Credential Provider showing up enabled in System Settings. However all other attempts to call into AuthenticationServices fail, and ASCredentialIdentityStore.shared.getState() always returns false for state.isEnabled Looking at the logs I don't see anything that stands out but I am not sure I've got the correct filter on the logs. I see discovery taking place 2026-05-29 08:43:09.389967-0700 0xd7d00 Default 0x83c0b1 26490 0 CredentialProviderExtensionHelper: (PlugInKit) [com.apple.PlugInKit:discovery] [d 88616305-672E-4143-81A6-832522BCD790] <PKHost:0x7e6c24900> Beginning discovery for flags: 0, point: com.apple.authentication-services-credential-provider-ui 2026-05-29 08:43:09.390070-0700 0xd7d00 Info 0x83c0b1 26490 0 CredentialProviderExtensionHelper: (PlugInKit) [com.apple.PlugInKit:discovery] [d 88616305-672E-4143-81A6-832522BCD790] <PKHost:0x7e6c24900> Query: { "LS:ExtensionPlatforms" = ( 1, 6, 2 ); NSExtensionPointName = "com.apple.authentication-services-credential-provider-ui"; NSUserElection = 1; } 2026-05-29 08:43:09.392893-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:sandbox] issued file extension for [/Applications/test.app/Contents/PlugIns/testIDCredentialProvider.appex] 2026-05-29 08:43:09.392936-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:ls] [u C85BFC1E-25E1-4917-A1D8-0123013482EE] [com.myapp.test.App.testid-credential-provider(7.35)] info [CFBundleIdentifier] => [com.myapp.test.App.testid-credential-provider] 2026-05-29 08:43:09.392947-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:sandbox] issued mach extension for [com.myapp.test.App.testid-credential-provider] And I see it being discovered correctly: 2026-05-29 08:43:09.394535-0700 0xd7d00 Default 0x83c0b2 26490 0 CredentialProviderExtensionHelper: (ExtensionFoundation) [com.apple.extensionkit:NSExtension] discovered extensions: attributes { "LS:ExtensionPlatforms" = ( 1, 6, 2 ); NSExtensionPointName = "com.apple.authentication-services-credential-provider-ui"; NSUserElection = 1; }, extensionSet {( <EXConcreteExtension: 0x7e71b41c0> {id = com.myapp.test.App.testid-credential-provider} )} I don't see any errors related to security or provisioning that I can tell. Any tricks I can use to see why I can't use my Credential Provider?

Is anyone else seeing 403 errors for PCC VRE when trying to pull assets for Release 41303? My pccvre audit of the Transparency Log passes (valid root digests for 41385), but the download fails consistently on specific CDN URLs: Failed to download SW release asset... response: 403 I’ve verified csrutil allow-research-guests is active and the license is accepted. Release 41385 seems fine, but 41303 is a brick wall. Is this a known pull-back or a CDN permissions sync issue?

We have encountered an issue reported by one of our users involving the Local Authentication framework. In our biometric authentication flow, we first check biometric availability using: let context = LAContext() var error: NSError? let canEvaluate = context.canEvaluatePolicy( .deviceOwnerAuthenticationWithBiometrics, error: &error ) For this particular user, canEvaluatePolicy repeatedly returned false with the error LAError.biometryNotAvailable (observed 7 times in our logs). What makes this unexpected is that: The user had Face ID configured and actively using it on the device. The user reported that they had not changed their Face ID enrollment. The user reported that they had not changed their device passcode. We are not aware of any MDM restrictions applied to the device. The issue appears to have been transient, as it was reported only for this user. We are trying to better understand under what conditions iOS may return LAError.biometryNotAvailable even when Face ID is configured on the device. Some questions we have: Are there known scenarios where Face ID is enrolled but canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) can temporarily return LAError.biometryNotAvailable? Can iOS return this error during transient system states (e.g., Face ID subsystem restart, device startup, system update, thermal conditions, etc.)? Is there any recommended diagnostic information we should collect to help identify the root cause when this occurs in production? Environment: iOS version: 26.4.2 Device model: iPhone 14 Pro Max LocalAuthentication framework Face ID authentication Any insights into possible causes of this behavior would be appreciated.

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected — calling AXIsProcessTrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvent.tapCreate(tap: .cgSessionEventTap, place: .headInsertEventTap, options: .listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list 3. Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preference.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15 (Sequoia), signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable — this is for audio, not HID). Question: Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

Hi, is there official information about iOS and iPadOS versions which no longer get security updates/support. I only know of an unofficial site "endoflife.com" and by their data there are no updates for iOS v18 but where can I verify that this information is legit. Our strict policy only allows that we deploy our app for OS version which still get security updates. Regards

QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26 Since iOS 26, QuickLookAR (or ARQuickLookPreviewItem) no longer preserves the original web URL when sharing a model. Instead of sending the link to the hosted file, the system directly shares the actual USDZ model file with the recipient. This is a critical regression and a severe breach of intellectual property protection, as it exposes proprietary 3D models that must never be distributed outside of the controlled web environment. In earlier iOS versions (tested up to iOS 18), QuickLookAR correctly handled sharing — the share sheet would send the website link where the model is hosted, not the file itself. Starting with iOS 26, this behavior has changed and completely breaks the intended secure flow for AR experiences. Our project relies on allowing users to view models in AR via QuickLook, without ever transferring the underlying 3D assets. Now, the share operation forces full file sharing, giving end users unrestricted access to the model file, which can be copied, rehosted, or reverse-engineered. This issue critically affects production environments and prevents us from deploying our AR-based solutions. Implement a standard QuickLookAR preview with a USDZ file hosted on your web server (e.g., via ARQuickLookPreviewItem). 2. Open the AR view on iOS 26. 3. Tap the Share icon from QuickLookAR. 4. Send via any messenger (Telegram, WhatsApp, etc.). 5. Observe that the actual .usdz model is sent instead of the original website URL. ⸻ Expected behavior: QuickLookAR should share only the original URL (as in iOS 17–18), not the file itself. This ensures that intellectual property and licensed 3D models remain protected and controlled by the content owner. ⸻ Actual behavior: QuickLookAR shares the entire USDZ file, leaking the model content outside of the intended environment. ⸻ Impact: • Violation of copyright and confidential data policies • Loss of control over proprietary 3D assets • Breaking change for all existing web-based AR integrations • Critical blocker for AR production deployment ⸻ Environment: • iOS 26.0 and 26.1 (tested on iPhone 14, iPhone 15) • Safari + QuickLookAR integration • Works correctly on iOS 17 / iOS 18 ⸻ Notes: This regression appears to have been introduced in the latest iOS 26 system handling of QuickLookAR sharing. Please escalate this issue to the ARKit / QuickLook engineering team as it directly affects compliance, IP protection, and usability of AR features across production applications. Additional Notes / Verification: Please test this behavior yourself using the CheckAR test model on my website: https://admixreality.com/ios26/ • If the login page appears, click “Check AR” and then “View in Your Space”. • On iOS 18 and earlier, sharing correctly sends the website URL. • On iOS 26, sharing sends the actual USDZ model file. This clearly demonstrates the regression and the security/IP issue.

With the ScreenTime API Apple talks a lot about their focus on privacy and the data not leaving the device. Does that mean there would be a problem with an app where the users ScreenTime data is shared to a custom backend? Could this potentially cause an app to be rejected from the AppStore?