https://support.apple.com/en-us/126655 As stated in the “Prepare your network environment for stricter security requirements.” my understanding is that additional security requirements will be introduced from OS 27 onward and that we need to prepare for them. However, I understand that the content on this page is mainly about distributing apps and operating the app itself. For example, I believe that simply accessing a web page within the app, or conducting HTTP communications with servers unaffiliated with Apple, will remain possible as before. Is my understanding correct?

Hello Apple Developer Support, We are using ILMessageFilterExtension with the IdentityLookup framework to classify carrier messages. We have already verified that the Message Filter extension is invoked for RCS messages. Our remaining question is specifically about end-to-end encrypted RCS messages on iOS 26.5. Could Apple please clarify the expected behavior for RCS E2EE messages? When an RCS conversation is end-to-end encrypted, is ILMessageFilterExtension expected to receive an ILMessageFilterQueryRequest callback? If the extension is invoked for RCS E2EE, does ILMessageFilterQueryRequest.messageBody contain the decrypted message body locally on device? If the extension is not invoked for RCS E2EE, is this expected behavior because the message content is end-to-end encrypted? Is the behavior different based on carrier, region, or RCS encryption availability? Is there any public Apple documentation that explicitly describes IdentityLookup / Message Filter behavior for RCS E2EE messages? Environment: iOS version: 26.5 Framework: IdentityLookup Extension: ILMessageFilterExtension API: ILMessageFilterQueryHandling.handle(_:context:completion:) Confirmed behavior: Message Filter extension is invoked for RCS messages Question: Whether the same behavior applies to end-to-end encrypted RCS messages We need this clarification to finalize expected product behavior and test coverage for RCS E2EE message filtering.

Hi, we are looking for a solution to install an extension to Microsoft PowerPoint app in a way that's compatible with the new macOS 15 behavior for Group Containers content. PowerPoint extensions Microsoft PowerPoint can be extended by PowerPoint Add-in (.ppam) files. These files must be installed in the app's container at this location: ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/ The PPAM file must be also registered in the MicrosoftRegistrationDB.reg file which is a sqlite database stored at this location: ~/Library/Group Containers/UBF8T346G9.Office/MicrosoftRegistrationDB.reg These locations can be access by non-sandboxed app on macOS 14 and earlier. Slido integration Our Slido app for macOS is distributed outside the Mac App Store, it is not sandboxed and it signed and notarized. The Slido app will install the PPAM file to the documented location and register it in the database. This installation did not require additional user approval on macOS 14 and older. With changes to macOS 15, a new permissions dialog is shown with this text: "Slido" would like to access data from other apps. This will allow Slido to integrate with Microsoft PowerPoint app. [Don't Allow] [Allow] We understand this is a security feature, yet we would like to make the experience for customers much better. As users are able to save PPAM files to the location by themselves without additional permissions, they expect the Slido app would be able to do so as well when run in the user context. Slido installs its files to this location: ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/SlidoAddin.localized/ Can we obtain com.apple.security.temporary-exception.files.home-relative-path.read-write to the SlidoAddin.localized folder? Even when we are different TeamID? Can we obtain a user permission which will be persisted so next time the Slido app can verify its files and uninstall them without further prompts? By having access to the SlidoAddin.localized folder our app would not be able to access any other data in Microsoft PowerPoint. We understand accessing the MicrosoftRegistrationDB.reg file is more sensitive and getting exception to access it would not be feasible. But we are trying to find out our options to make the experience seamless as that's what is expected by our customers on Apple platform. I am thankfully for any guidance and constructive feedback. Jozef, Tech Leader at Slido integrations team

I’m trying to understand the recommended configuration for Sign in with Apple across two separate iOS apps and one website/Services ID under the same Apple Developer team. Goal: A user signs in with Apple in either iOS app or on the website, and our backend can recognize it as the same Apple identity/account, including when the user chooses Hide My Email. Current question: Should both iOS App IDs be configured as separate primary App IDs, or should one be primary and the other grouped with it? The website uses a Services ID associated with the primary App ID. I'm seeing behavior where the user can get a “create/sign in” style prompt in both iOS apps, and we want to avoid accidentally creating separate backend accounts if Apple returns different sub values for each app/client. What is the correct Apple Developer configuration if I need a stable backend identity across: iOS app A (existing, existing users) iOS app B (new, no existing users) web Services ID (new, no existing users) [preferred go forward "create account" service name if possible] Should our backend expect the sub claim in the Apple identity token to be identical across those clients when they are grouped, or should I treat each App ID/Services ID as potentially returning a different sub and link accounts another way? Current configuration and observed behavior: The web Services ID and iOS App B are currently grouped under iOS App A as the primary App ID for Sign in with Apple. This mostly works: when users sign in through App B, they appear to be associated with the same Apple credential/account, and no additional Sign in with Apple entry appears in the Passwords app. However, App B still presents the “create a login” flow and asks the user to choose/share their name and email again. The system prompt also shows App B’s display name, not the web Services ID name or App A’s primary App ID name. This could confuse users into thinking they are creating a separate App B account rather than signing into the same account used by App A and the website. Because of that, users may choose a different name/email option, including a different Hide My Email choice, which could lead our backend to treat the sign-in as a separate account if the Apple identity token differs by client configuration. I'm trying to confirm whether this prompt/UI behavior is expected for a grouped App ID, and whether the Apple identity token’s sub claim should remain stable across App A, App B, and the associated web Services ID.

I'm developing a Unity iOS app using the official "Sign In with Apple" Unity plugin (v1.5.0), and I'm encountering persistent errors during authentication. Here’s the full context: App Info: Unity version: 6000.0.32f1 Bundle ID: com.pfcgaming.applesignin Sign In with Apple enabled in the Apple Developer portal Real iOS device, not simulator Error Logs: txt Copy Edit Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.pfcgaming.applesignin} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" Description: The operation couldn’t be completed. No credentials available for login. What I’ve Done So Far: Verified "Sign In with Apple" is enabled under the App ID in developer.apple.com. Provisioning profile has been regenerated with correct entitlements. Xcode project has the “Sign In with Apple” capability added. Tested on multiple real iOS devices with iCloud + Keychain enabled. Tried both PerformQuickLogin() and LoginWithAppleId() approaches in the plugin. My Observations: These errors started occurring right after enabling "Sign In with Apple" in the developer portal. Based on some community feedback, there may be a backend propagation delay after enabling SIWA (Sign In With Apple) which might cause these errors. Questions: Is it expected to receive error -7003 or 1001 immediately after enabling SIWA in the Developer Portal? How long does it typically take for entitlement changes to fully propagate? Is there any Apple-recommended workaround to test during this wait time? Any insight or confirmation would be helpful. Thanks in advance!

Hey everyone, I'm hitting an absolute brick wall with Sign in with Apple on an Expo/React Native project distributed via TestFlight. The native API (isAvailableAsync() via expo-apple-authentication) is returning false globally across multiple physical devices, different user Apple IDs, and different network environments. We have completely ruled out a local code crash—the framework initializes, but the local iOS kernel is explicitly returning a hard false on the availability check before even attempting to present the modal sheet. Here is exactly what we have isolated and verified based on DTS documentation: Identifiers & App ID Setup: Team ID: NJ5JQ25956 (Luxor Interactive LLC) iOS Bundle Identifier: com.myoseph.carswipeapp App ID Capabilities: Checked and verified that "Sign in with Apple" is explicitly enabled on the Apple Developer Portal for this explicit bundle ID. Credentials & Provisioning Purge: We suspecting a cached provisioning profile or identifier cross-talk (our Android layout previously used a different package string, though we just unified it to com.myoseph.carswipeapp across the configuration scripts to rule out cryptographic hash collisions). We completely revoked and purged all old Distribution Certificates and App Store Provisioning Profiles from both the build engine cache and the Apple Developer Portal. Regenerated a completely fresh Distribution Certificate (Serial: 7383AE36E5D21E93F3F0B907D3A87DF3) and a brand-new, active Provisioning Profile (ID: L328ZDW2A4). Entitlements Inspection: Inspecting the compiled .ipa container structure shows the explicit com.apple.developer.applesignin entitlement key array is correctly present and injected. Despite having pristine, newly-minted cryptographic certificates tightly bound to a verified App ID, Build 62 on TestFlight still rejects the authentication framework instantly at the OS level. Is there a known propagation lag on Apple's identity database servers for newly updated Team ID capabilities, or is there an internal backend entitlement lock on our corporate Team ID container that isn't reflecting on the developer portal UI? Any insights or a sanity check from DTS would be an absolute lifesaver. Thanks in advance.

Dear community, I recently transferred my iOS app to a different developer account as part of an app acquisition. When uploading now on the new team the first build from the new team via Xcode Cloud, I get: ITMS-90076: Potential Loss of Keychain Access - The previous version of software has an application-identifier value of ['OLDTEAMID.ch..'] and the new version of software being submitted has an application-identifier of ['NEWTEAMID.ch..']. This will result in a loss of keychain access. I understand this is expected, since the App ID prefix changed from the old Team ID to the new one. The problem is that this app is a crypto wallet: it stores the user's private key in the keychain using the default access group ($(AppIdentifierPrefix)$(CFBundleIdentifier)), with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and no iCloud synchronization. If existing users update to a build signed by the new team, they permanently lose access to their keys — there is no server-side recovery. <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string> </array> It was extremely stupid to do it like this :( I've read the "App ID Prefix Change and Keychain Access" post, which describes migrating keychain items into an app-group-based access group before the transfer, then transferring the app group along with the app. Unfortunately, my transfer has already completed. My questions: Is transferring the app back to the original team, shipping a migration update that moves keychain items into an app group access group, and then re-transferring the app together with the app group still the recommended (and only) path in this situation? Are there any pitfalls with migrating items protected by SecAccessControl (.userPresence) into an app group access group, given that reading them requires biometric/passcode authentication? Is there any timing constraint or cooldown I should be aware of when transferring an app back and then transferring it again shortly after? Any other less time intensive options? Is it possible to "transfer a team id"? Or rename/handover the old account to the new developer? Thank you for the team and guidance on this.

Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,

With the recent Platform SSO announcements from Apple, I noticed that users can now authenticate at the macOS login window and Filevault screen using an OIDC-based web authentication flow through their IDP. My understanding was that historically, unlocking the user's keychain and establishing a login session required either: The user's local account password, or Smart card-based authentication integrated with macOS login mechanisms. Given the new Platform SSO capabilities, I am curious about the underlying authentication model and whether it introduces new possibilities for third-party developers. Specifically, is there now any supported mechanism for a third-party login or authorization solution to leverage Secure Enclave-backed credentials to establish a user session and unlock the login keychain without requiring a local password, similar to the passwordless experience enabled by Platform SSO? My use case is providing a passwordless login experience through a custom authorization plugin for organizations that may not want to deploy Platform SSO but still want users to authenticate using device-bound cryptographic credentials stored in the Secure Enclave. Are the capabilities used by Platform SSO available to third-party developers, or are they restricted to the Platform SSO framework and its associated system integrations? Any guidance on supported architectures or limitations would be appreciated.

We are planning to roll out Apple App Attest for our iOS app and have a question about DCAppAttestService.attestKey(_:clientDataHash:) rate limiting during a large-scale rollout. We understand that attestKey(:clientDataHash:) should be used only during the initial App Attest key registration flow, and that subsequent protected API requests should use generateAssertion(:clientDataHash:). However, during rollout, existing users may gradually register App Attest keys, and we want to avoid causing unnecessary attestation traffic spikes. Could Apple confirm the recommended approach for handling this at scale? Specifically: Is there any supported process to request temporary rate limit accommodation for attestKey calls during a large-scale rollout? If rate limit accommodation is not available, should we rely entirely on staged rollout, exponential backoff, retryAfter handling, and grace-mode handling? Are there any additional recommendations for apps with a large number of daily active users to avoid App Attest attestation rate limiting? Thank you.

We are a financial institution and are considering to introduce passkeys as login mechanism for our web banking application. We see this as an important step to curb phishing. But we saw that there is a way to share passkeys with others - https://support.apple.com/guide/iphone/share-passwords-iphe6b2b7043/ios - and are wondering if this can be disabled by us for our passkeys. Social engineering attacks are very sophisticated nowadays and we are afraid attackers would be able to manipulate customers to share their passkeys with them. thanks for your help stefan

We are evaluating whether Apple Platform SSO can be used by a native macOS application to silently authenticate against our backend through an identity provider's SSO extension. Our environment is as follows: Apple Platform SSO is configured and active. Device registration and user registration have completed successfully. Authentication is backed by Secure Enclave / Platform SSO. The identity provider is integrated through an SSO extension. Tokens are active and Not Expired We would like to understand the intended behavior and supported usage patterns of Platform SSO from the perspective of a third-party native macOS application. Specifically: Once Platform SSO is active, is there a supported way for a third-party macOS application to obtain IdP bearer/access tokens silently (without UI, password prompts, or web-based authentication) through the SSO extension? If silent token acquisition is supported, is it intended to work for any third-party application, or only for applications developed and distributed by the IdP/vendor that provides the SSO extension? In our testing, requests created via ASAuthorizationSingleSignOnRequest are rejected by the extension with doNotHandle. Does this generally indicate that: the request falls outside the extension's supported flow, a different request configuration is expected, or ASAuthorizationSingleSignOnRequest is not intended for this Platform SSO scenario? For native macOS applications that need silent authentication, should the recommended approach be: standard OAuth/OIDC flows, Platform SSO APIs, or a combination of both? If OAuth/OIDC is involved, which parts of those flows are expected to be handled transparently by Platform SSO and the SSO extension? If a combination of both is the recommended approach, many OAuth/OIDC flows rely on flow-specific security mechanisms such as client secrets, private keys, client certificates, or signed client assertions. In that case, the overall model becomes unclear Is there a standard protocol or capability that SSO extensions are expected to implement to support application authentication under Platform SSO, or is this entirely vendor-specific and dependent on the IdP's implementation and SDK? If there is an Apple-recommended pattern for enabling silent authentication from native third-party macOS applications when an IdP SSO extension is present, we would appreciate any guidance or references to relevant documentation. Thank you.

I am using ASAuthorizationProviderExtensionLoginManager.resetKeys() to generate new user-specific keys, specifically userDeviceSigningKey and userDeviceEncryptionKey. Based on the documentation, my understanding was that resetKeys() only resets keys associated with a particular user account: https://developer.apple.com/documentation/authenticationservices/asauthorizationproviderextensionloginmanager/resetkeys/ However, during testing, I observed that calling resetKeys() also resets sharedDeviceSigningKey. I had assumed that shared device keys would only be reset via resetDeviceKeys().

We are developing an enterprise security solution for macOS that includes Wi-Fi awareness and network-based policy enforcement - WiFi Control. On current macOS releases, access to the connected Wi-Fi's SSID/BSSID appears to require Location Services authorization. In many corporate environments, end users do not have local administrator privileges and cannot enable Location Services themselves. Enabling it often requires coordination with IT administrators, which can be difficult to scale in large organizations with a geographically distributed workspace. This creates a deployment challenge for enterprise security products because network identification becomes unavailable on managed Macs, even when the device is enrolled and managed through MDM. As far as we understand: MDM on macOS does not provide a mechanism equivalent to managed-device Wi-Fi control available in iOS management scenarios. System Extension running with elevated privileges cannot obtain the current SSID/BSSID through frameworks such as CoreWLAN even when Location Services access is granted (it requires user session). Our questions are: Is there currently any supported API or entitlement that allows enterprise security products to determine the currently connected SSID/BSSID on managed macOS devices without requiring end users to enable Location Services? Are there plans to provide a managed-device exception, entitlement, or MDM-controlled authorization model for enterprise security vendors that need network identity information for security and compliance use cases? Would Apple consider exposing SSID/BSSID information to approved System Extensions or Endpoint Security-based products in managed corporate environments, while maintaining existing privacy protections for consumer devices? We fully understand the privacy rationale behind restricting Wi-Fi information, but enterprise security and compliance solutions often need to identify trusted and untrusted networks. Today, the Location Services dependency significantly complicates deployment and usability in managed corporate environments. Any guidance on recommended approaches or future platform direction would be greatly appreciated.

Hi! We're having issues with the sign in flow, starting today. As per the documentation, the issuer of the tokens should be https://appleid.apple.com sign in docs. But in the published configuration, it is now stated as https://account.apple.com metadata endpoint. Once the token is received through the sign in flow, the issuer is however still appleid.apple.com. This is causing problems for us where we expect the issuer in the metadata endpoint to be the same as the actual token issuer. What is correct here?

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?

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