General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.

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,

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 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?

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

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.

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?