Hello everyone! We are from Russia, and we no longer have an official Apple store. All phones are imported through parallel imports. Yesterday, my wife logged out of her Apple ID and logged in to someone else's account, and as a result, her phone was in lost and locked mode. We have a sales receipt confirming the purchase, but it is from a Russian store. Can you please tell me if there is a way to unlock the phone or if it is already a brick? Scammers are asking for money to unlock the phone. Thank you in advance for your reply!

While I was submitting a new feedback today for an iPhone/iPad storage issue, I saw a new log called “iOS storage log”. I could find no reference to this when I searched online. It made me wonder if it was new and if it contained personal data? Most of us only have one device, with all our personal data. Therefore, I’d appreciate any input on what personal data these logs contain.

When implementing Sign In with Apple I created an App ID and a Service ID for my app. I didn't configure the Server-to-Server Notification URL properly there and token revocation didn't work. Later on I updated the url config and the name of the identifiers. However, when I Sign in with Apple in my app I still see the old identifier name in my iPhone Settings->Apple Account->Sign in with Apple. I would assume that if the name doesn't update, the configuration doesn't update either. I'm using automatic Xcode signing, I have deleted all the profiles locally, cleaned project, bumped versions, waited for a week, nothing worked. Token revocation for account deletion doesn't work properly I would assume because of the initial misconfiguration. I want to mention that this is working fine for my development build (another bundleID, AppID, ServiceID) What am I missing here?

"Our app has absolutely no integration with DiDi login. We only integrate WeChat, QQ, carrier, and Apple ID login, and all related login entry icons are local resources. On an iPhone 16 Pro Max device with iOS system version 18.7, there was one isolated incident where the Apple ID login entry icon mysteriously changed to the DiDi app icon. What could be the possible iOS system-level causes for this?"

I have an Autofill Passkey Provider working for Safari and Chrome via WebAuthn protocol. Unfortunately, Chrome will not offer my extension as a logon credential provider unless I add the credential to the ASCredentialIdentityStore. I wonder what is the best way to access the ASCredentialIdentityStore from an AutoFill extension? I understand I cannot access it directly from the extension context, so what is the best way to trigger my container app to run, based on a new WebAuthn registration? The best I can think of so far is for the www site to provide an App Link to launch my container app as part of the registration ceremony. Safari will offer my extension even without adding it to the ASCredentialIdentityStore, so I guess I should file a request with Chrome to work this way too, given difficulty of syncing ASCredentialIdentityStore with WebAuthn registration.

I've just implemented Sign-In-With-Apple and everything is working perfectly, but my app seems to be in some strange state where users are unable to remove it from the Sign-In-With-Apple section of their settings. Things I've tried: -- Deleting from Mac. (It just stays in the list) -- Deleting from the iPhone (It stays in the list) -- Deleting from account.apple.com (same issue) -- I've noticed in the browser inspector tools I receive a 200 on the DELETE request, but the app remains. -- Multiple users Also have tried: -- Revoking the token through the REST API -- I get an email saying the token has been revoked, but it's still working -- Same code, different app id (works fine!) It seems like maybe my app is in some sort of weird state? Has anyone come across this before?

When implementing a custom right in macOS authorizationdb, the mechanism array element builtin:authenticate is displaying the message 'Enter the name and password of a user in the "(null)" group to allow this.' on the macOS credential prompt UI popup. I am trying to find a fix to avoid the reference to null group in the message label that is displayed just above the username and password input fields. The current plist uses class as the key and value as the evaluate-mechanisms. The mechanisms array includes mechanism array with elements "builtin:login-begin", "mycustombundle:mycustompreaction", "builtin:authenticate", "mycustombundle:mycustommechanism". I have tried specifying group in the plist, have tried setting hint in the MechanismInvoke for group, username, security, authority, prompt, reason among several other hints into the context duing the execution of mycustombundle:mycustompreaction, but none seem to fix the "(null)" in the message label. Any help is greately appreciated. There is not much of any documentation for developers implementing custom authorization in macOS.

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,

Hello everyone, I'm developing a FIDO2 service using the AuthenticationServices framework. I've run into an issue when a user manually deletes a passkey from their password manager. When this happens, the ASAuthorizationError I get doesn't clearly indicate that the passkey is missing. The error code is 1001, and the localizedDescription is "The operation couldn't be completed. No credentials available for login." The userInfo also contains "NSLocalizedFailureReason": "No credentials available for login." My concern is that these localized strings will change depending on the user's device language, making it unreliable for me to programmatically check for a "no credentials" scenario. Is there a more precise way to determine that the user has no passkey, without relying on localized string values? Thank you for your help.

Recently, we have adapted the passkey function on the Mac, but we always encounter the error message "Unable to verify the web credentials association of xxx with domain aaa. Please try again in a few seconds." We can confirm that https://aaa/.well-known/apple-app-site-association has been configured and is accessible over the public network. Additionally, the entitlements in the app have also been set with webcredentials:aaa. This feature has been experiencing inconsistent performance. When I restart my computer or reinstall the pkg, this feature may work or it may still not work. I believe this is a system issue. Here is feed back ID: FB20876945 In the feedback, I provided the relevant logs. If you have any suggestions or assistance, please contact me. I would be extremely grateful!

I’m implementing a macOS Platform SSO extension using ASAuthorizationProviderExtensionAuthorizationRequest. In beginAuthorization, I intercept an OAuth authorize request and call: request.complete(httpAuthorizationHeaders: [ "x-psso-attestation": signedJWT ]) I also tested: request.complete(httpAuthorizationHeaders: [ "Authorization": "Bearer test-value" ]) From extension logs, I can confirm the request is intercepted correctly and the header dictionary passed into complete(httpAuthorizationHeaders:) contains the expected values. However: the header is not visible in browser devtools the header does not appear at the server / reverse proxy So the question is: Does complete(httpAuthorizationHeaders:) support arbitrary custom headers, or only a restricted set of authorization-related headers ? Is there something that I might be missing ? And if custom headers are not supported, is there any supported way for a Platform SSO extension to attach a normal HTTP header to the continued outbound request ?

I'm experiencing an issue with Sign In with Apple integration in my React Native Expo app (Bundle ID: com.anonymous.TuZjemyApp). Problem Description: When users attempt to sign in using Sign In with Apple, they successfully complete Face ID/password authentication, but then receive a "Sign-Up not completed" error message. The authentication flow appears to stop at this point and doesn't return the identity token to my app. Technical Details: Frontend Implementation: Using expo-apple-authentication. Requesting scopes: FULL_NAME and EMAIL App is properly configured in app.json with: usesAppleSignIn: true Entitlement: com.apple.developer.applesignin Backend Implementation: Endpoint: POST /api/auth/apple Using apple-signin-auth package for token verification Verifying tokens with audience: com.anonymous.TuZjemyApp Backend creates/updates user accounts based on Apple ID Question: I'm not sure why the authentication flow stops with "Sign-Up not completed" after successful Face ID verification. The identity token never reaches my app. Could you please help me understand: What might cause this specific error message? Are there any additional Apple Developer Portal configurations required? Could this be related to app capabilities or entitlements? Is there a specific setup needed for the app to properly receive identity tokens? I set up provisioning profiles, and added Sign in with Apple as a capability and still it doesn't work.

I need to launch ASWebAuthenticationSession from single sign on extension, but its not launching it might issue with anchoring window, I have create custom windo and passing it in presentanchor(for session) function, custom window is launching but ASWebAuthenticationSession browser is not launching Note - flow is like this Apple PSSO register window lauched OIDC login will happen via ASWebAuthenticationSession to get accesstoken which will use in device registration but ASWebAuthenticationSession is not launching, I am using custom scheme as redirect URI iskeywindow for custom window is always false what is right approach to achieve the goal

We are integrating Sign in with Apple for our web application and have been stuck on an invalid_client error during the token exchange step. The Problem The authorization step works fine — the user authenticates on Apple's page and a valid authorization code is returned to our callback URL. However, when we exchange that code at https://appleid.apple.com/auth/token, it returns: {"error": "invalid_client"} The Puzzling Part When we send a dummy/expired authorization code with the exact same client_id and client_secret, Apple returns: {"error": "invalid_grant", "error_description": "The code has expired or has been revoked."} This confirms that our client credentials (client_id + client_secret JWT) are valid and accepted by Apple. The invalid_client error only occurs when a real, freshly-issued authorization code is used. Configuration Service ID configured with Sign in with Apple enabled Primary App ID with Sign in with Apple capability enabled Domain verified, Return URL registered Key created with Sign in with Apple enabled, linked to the correct Primary App ID Client Secret JWT Generated per Apple's documentation: Header: alg: ES256, kid set to our Key ID Claims: iss: Team ID iat: current timestamp exp: iat + 6 months (within Apple's limit) aud: https://appleid.apple.com sub: Service ID (matches the client_id used in authorization) Signed with: the .p8 private key associated with the Key Token Exchange Request POST https://appleid.apple.com/auth/tokenContent-Type: application/x-www-form-urlencodedclient_id=client_secret=code=grant_type=authorization_coderedirect_uri= What We've Tried Standalone test endpoint — built a minimal endpoint (no framework) that does the token exchange via server-side curl. Same invalid_client. Multiple Service IDs — created and tried 3 different Service IDs. All produce the same error with real codes. Multiple Keys — tried 2 different keys. Same error. Verified redirect_uri matches exactly between the authorization request and token request. Verified client_id matches exactly between the authorization URL and token request. Used client_secret_post (credentials in body, not Basic auth header). Freshness — code is used immediately upon receipt (within seconds), well before the 5-minute expiry. Filed a Developer Support case — was directed to Forums. Summary Scenario code Result Dummy/expired code abc123 invalid_grant (credentials accepted) Real fresh code from Apple callback invalid_client This pattern suggests something goes wrong specifically when Apple validates the authorization code against the client — even though the client credentials themselves are accepted in isolation. Has anyone encountered this behavior? Is there a known configuration issue that could cause invalid_client only with valid authorization codes? Any guidance would be greatly appreciated.

I can't find any information about why this is happening, nor can I reproduce the 'successful' state on this device. My team needs to understand this behavior, so any insight would be greatly appreciated! The expected behavior: If I delete both apps and reinstall them, attempting to open the second app from my app should trigger the system confirmation dialog. The specifics: I'm using the MSAL library. It navigates the user to the Microsoft Authenticator app and then returns to my app. However, even after resetting the phone and reinstalling both apps, the dialog never shows up (it just opens the app directly). Does anyone know the logic behind how iOS handles these prompts or why it might be persistent even after a reset? Thanks in advance!

I regularly help developers with keychain problems, both here on DevForums and for my Day Job™ in DTS. Many of these problems are caused by a fundamental misunderstanding of how the keychain works. This post is my attempt to explain that. I wrote it primarily so that Future Quinn™ can direct folks here rather than explain everything from scratch (-: If you have questions or comments about any of this, put them in a new thread and apply the Security tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" SecItem: Fundamentals or How I Learned to Stop Worrying and Love the SecItem API The SecItem API seems very simple. After all, it only has four function calls, how hard can it be? In reality, things are not that easy. Various factors contribute to making this API much trickier than it might seem at first glance. This post explains the fundamental underpinnings of the keychain. For information about specific issues, see its companion post, SecItem: Pitfalls and Best Practices. Keychain Documentation Your basic starting point should be Keychain Items. If your code runs on the Mac, also read TN3137 On Mac keychain APIs and implementations. Read the doc comments in <Security/SecItem.h>. In many cases those doc comments contain critical tidbits. When you read keychain documentation [1] and doc comments, keep in mind that statements specific to iOS typically apply to iPadOS, tvOS, and watchOS as well (r. 102786959). Also, they typically apply to macOS when you target the data protection keychain. Conversely, statements specific to macOS may not apply when you target the data protection keychain. [1] Except TN3137, which is very clear about this (-: Caveat Mac Developer macOS supports two different keychain implementations: the original file-based keychain and the iOS-style data protection keychain. IMPORTANT If you’re able to use the data protection keychain, do so. It’ll make your life easier. See the Careful With that Shim, Mac Developer section of SecItem: Pitfalls and Best Practices for more about this. TN3137 On Mac keychain APIs and implementations explains this distinction. It also says: The file-based keychain is on the road to deprecation. This is talking about the implementation, not any specific API. The SecItem API can’t be deprecated because it works with both the data protection keychain and the file-based keychain. However, Apple has deprecated many APIs that are specific to the file-based keychain, for example, SecKeychainCreate. TN3137 also notes that some programs, like launchd daemons, can’t use the file-based keychain. If you’re working on such a program then you don’t have to worry about the deprecation of these file-based keychain APIs. You’re already stuck with the file-based keychain implementation, so using a deprecated file-based keychain API doesn’t make things worse. The Four Freedoms^H^H^H^H^H^H^H^H Functions The SecItem API contains just four functions: SecItemAdd(_:_:) SecItemCopyMatching(_:_:) SecItemUpdate(_:_:) SecItemDelete(_:) These directly map to standard SQL database operations: SecItemAdd(_:_:) maps to INSERT. SecItemCopyMatching(_:_:) maps to SELECT. SecItemUpdate(_:_:) maps to UPDATE. SecItemDelete(_:) maps to DELETE. You can think of each keychain item class (generic password, certificate, and so on) as a separate SQL table within the database. The rows of that table are the individual keychain items for that class and the columns are the attributes of those items. Note Except for the digital identity class, kSecClassIdentity, where the values are split across the certificate and key tables. See Digital Identities Aren’t Real in SecItem: Pitfalls and Best Practices. This is not an accident. The data protection keychain is actually implemented as an SQLite database. If you’re curious about its structure, examine it on the Mac by pointing your favourite SQLite inspection tool — for example, the sqlite3 command-line tool — at the keychain database in ~/Library/Keychains/UUU/keychain-2.db, where UUU is a UUID. WARNING Do not depend on the location and structure of this file. These have changed in the past and are likely to change again in the future. If you embed knowledge of them into a shipping product, it’s likely that your product will have binary compatibility problems at some point in the future. The only reason I’m mentioning them here is because I find it helpful to poke around in the file to get a better understanding of how the API works. For information about which attributes are supported by each keychain item class — that is, what columns are in each table — see the Note box at the top of Item Attribute Keys and Values. Alternatively, look at the Attribute Key Constants doc comment in <Security/SecItem.h>. Uniqueness A critical part of the keychain model is uniqueness. How does the keychain determine if item A is the same as item B? It turns out that this is class dependent. For each keychain item class there is a set of attributes that form the uniqueness constraint for items of that class. That is, if you try to add item A where all of its attributes are the same as item B, the add fails with errSecDuplicateItem. For more information, see the errSecDuplicateItem page. It has lists of attributes that make up this uniqueness constraint, one for each class. These uniqueness constraints are a major source of confusion, as discussed in the Queries and the Uniqueness Constraints section of SecItem: Pitfalls and Best Practices. Parameter Blocks Understanding The SecItem API is a classic ‘parameter block’ API. All of its inputs are dictionaries, and you have to know which properties to set in each dictionary to achieve your desired result. Likewise for when you read properties in output dictionaries. There are five different property groups: The item class property, kSecClass, determines the class of item you’re operating on: kSecClassGenericPassword, kSecClassCertificate, and so on. The item attribute properties, like kSecAttrAccessGroup, map directly to keychain item attributes. The search properties, like kSecMatchLimit, control how the system runs a query. The return type properties, like kSecReturnAttributes, determine what values the query returns. The value type properties, like kSecValueRef perform multiple duties, as explained below. There are other properties that perform a variety of specific functions. For example, kSecUseDataProtectionKeychain tells macOS to use the data protection keychain instead of the file-based keychain. These properties are hard to describe in general; for the details, see the documentation for each such property. Inputs Each of the four SecItem functions take dictionary input parameters of the same type, CFDictionary, but these dictionaries are not the same. Different dictionaries support different property groups: The first parameter of SecItemAdd(_:_:) is an add dictionary. It supports all property groups except the search properties. The first parameter of SecItemCopyMatching(_:_:) is a query and return dictionary. It supports all property groups. The first parameter of SecItemUpdate(_:_:) is a pure query dictionary. It supports all property groups except the return type properties. Likewise for the only parameter of SecItemDelete(_:). The second parameter of SecItemUpdate(_:_:) is an update dictionary. It supports the item attribute and value type property groups. Outputs Two of the SecItem functions, SecItemAdd(_:_:) and SecItemCopyMatching(_:_:), return values. These output parameters are of type CFTypeRef because the type of value you get back depends on the return type properties you supply in the input dictionary: If you supply a single return type property, except kSecReturnAttributes, you get back a value appropriate for that return type. If you supply multiple return type properties or kSecReturnAttributes, you get back a dictionary. This supports the item attribute and value type property groups. To get a non-attribute value from this dictionary, use the value type property that corresponds to its return type property. For example, if you set kSecReturnPersistentRef in the input dictionary, use kSecValuePersistentRef to get the persistent reference from the output dictionary. In the single item case, the type of value you get back depends on the return type property and the keychain item class: For kSecReturnData you get back the keychain item’s data. This makes most sense for password items, where the data holds the password. It also works for certificate items, where you get back the DER-encoded certificate. Using this for key items is kinda sketchy. If you want to export a key, called SecKeyCopyExternalRepresentation. Using this for digital identity items is nonsensical. For kSecReturnRef you get back an object reference. This only works for keychain item classes that have an object representation, namely certificates, keys, and digital identities. You get back a SecCertificate, a SecKey, or a SecIdentity, respectively. For kSecReturnPersistentRef you get back a data value that holds the persistent reference. Value Type Subtleties There are three properties in the value type property group: kSecValueData kSecValueRef kSecValuePersistentRef Their semantics vary based on the dictionary type. For kSecValueData: In an add dictionary, this is the value of the item to add. For example, when adding a generic password item (kSecClassGenericPassword), the value of this key is a Data value containing the password. This is not supported in a query dictionary. In an update dictionary, this is the new value for the item. For kSecValueRef: In add and query dictionaries, the system infers the class property and attribute properties from the supplied object. For example, if you supply a certificate object (SecCertificate, created using SecCertificateCreateWithData), the system will infer a kSecClass value of kSecClassCertificate and various attribute values, like kSecAttrSerialNumber, from that certificate object. This is not supported in an update dictionary. For kSecValuePersistentRef: For query dictionaries, this uniquely identifies the item to operate on. This is not supported in add and update dictionaries. Revision History 2025-05-28 Expanded the Caveat Mac Developer section to cover some subtleties associated with the deprecation of the file-based keychain. 2023-09-12 Fixed various bugs in the revision history. Added a paragraph explaining how to determine which attributes are supported by each keychain item class. 2023-02-22 Made minor editorial changes. 2023-01-28 First posted.

DTS regularly receives questions about how to preserve keychain items across an App ID change, and so I thought I’d post a comprehensive answer here for the benefit of all. If you have any questions or comments, please start a new thread here on the forums. Put it in the Privacy & Security > General subtopic and tag it with Security. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App ID Prefix Change and Keychain Access The list of keychain access groups your app can access is determined by three entitlements. For the details, see Sharing Access to Keychain Items Among a Collection of Apps. If your app changes its App ID prefix, this list changes and you’re likely to lose access to existing keychain items. This situation crops up under two circumstances: When you migrate your app from using a unique App ID prefix to using your Team ID as its App ID prefix. When you transfer your app to another team. In both cases you have to plan carefully for this change. If you only learn about the problem after you’ve made the change, consider undoing the change to give you time to come up with a plan before continuing. Note On macOS, the information in this post only applies to the data protection keychain. For more information about the subtleties of the keychain on macOS, see On Mac Keychains. For more about App ID prefix changes, see Technote 2311 Managing Multiple App ID Prefixes and QA1726 Resolving the Potential Loss of Keychain Access warning. Migrate From a Unique App ID Prefix to Your Team ID Historically each app was assigned its own App ID prefix. This is no longer the case. Best practice is for apps to use their Team ID as their App ID prefix. This enables multiple neat features, including keychain item sharing and pasteboard sharing. If you have an app that uses a unique App ID prefix, consider migrating it to use your Team ID. This is a good thing in general, as long as you manage the migration process carefully. Your app’s keychain access group list is built from three entitlements: keychain-access-groups — For more on this, see Keychain Access Groups Entitlement. application-identifier (com.apple.application-identifier on macOS) com.apple.security.application-groups — For more on this, see App Groups Entitlement. Keycahin access groups from the third bullet are call app group identified keychain access groups, or AGI keychain access groups for short. IMPORTANT A macOS app can only use an AGI keychain access group if all of its entitlement claims are validated by a provisioning profile. See App Groups: macOS vs iOS: Working Towards Harmony for more about this concept. Keychain access groups from the first two bullets depend on the App ID prefix. If that changes, you lose access to any keychain items in those groups. WARNING Think carefully before using the keychain to store secrets that are the only way to access irreplaceable user data. While the keychain is very reliable, there are situations where a keychain item can be lost and it’s bad if it takes the user’s data with it. In some cases losing access to keychain items is not a big deal. For example, if your app uses the keychain to manage a single login credential, losing that is likely to be acceptable. The user can recover by logging in again. In other cases losing access to keychain items is unacceptable. For example, your app might manage access to dozens of different servers, each with unique login credentials. Your users will be grumpy if you require them to log in to all those servers again. In such situations you must carefully plan your migration. The key thing to understand is that an app group is tied to your team, not your App ID prefix, and thus your app retains access to AGI keychain access groups across an App ID prefix change. This suggests the following approach: Release a version of your app that moves keychain items from other keychain access groups to an AGI keychain access group. Give your users time to update to this new version, run it, and so move their keychain items. When you’re confident that the bulk of your users have done this, change your App ID prefix. The approach has one obvious caveat: It’s hard to judge how long to wait at step 2. Transfer Your App to Another Team Historically there was no supported way to maintain access to keychain items across an app transfer. That’s no longer the case, but you must still plan the transfer carefully. The overall approach is: Identify an app group ID to transfer. This could be an existing app group ID, but in many cases you’ll want to register a new app group ID solely for this purpose. Use the old team (the transferor) to release a version of your app that moves keychain items from other keychain access groups to the AGI keychain access group for this app group ID. Give your users time to update to this new version, run it, and so move their keychain items. When you’re confident that the bulk of your users have done this, initiate the app transfer. Once that’s complete, transfer the app group ID you selected in step 1. See App Store Connect Help > Transfer an app > Overview of app transfer > Apps using App Groups. Publish an update to your app from the new team (the transferee). When a user installs this version, it will have access to your app group, and hence your keychain items. WARNING Once you transfer the app group, the old team won’t be able to publish a new version of any app that uses this app group. That makes step 1 in the process critical. If you have an existing app group that’s used solely by the app being transferred — for example, an app group that you use to share state between the app and its app extensions — then choosing that app group ID makes sense. On the other hand, choosing the ID of an app group that’s share between this app and some unrelated app, one that’s not being transferred, would be bad, because any updates to that other app will lose access to the app group. There are some other significant caveats: The process doesn’t work for Mac apps because Mac apps that have ever used an app group can’t be transferred. See App Store Connect Help > Transfer an app > App transfer criteria. If and when that changes, you’ll need to choose an iOS-style app group ID for your AGI keychain access group. For more about the difference between iOS- and macOS-style app group IDs, see App Groups: macOS vs iOS: Working Towards Harmony. The current transfer process of app groups exposes a small window where some other team can ‘steal’ your app group ID. We have a bug on file to improve that process (r. 171616887). The process works best when transferring between two teams that are both under the control of the same entity. If that’s not the case, take steps to ensure that the old team transfers the app group in step 5. When you submit the app from the new team (step 6), App Store Connect will warn you about a potential loss of keychain access. That warning is talking about keychain items in normal keychain access groups. Items in an AGI keychain access group will still be accessible as long as you transfer the app group. Alternative Approaches for App Transfer In addition to the technique described in the previous section, there are a some alternative approaches you should at consider: Do nothing Do not transfer your app Get creative Do Nothing In this case the user loses all the secrets that your app stored in the keychain. This may be acceptable for certain apps. For example, if your app uses the keychain to manage a single login credential, losing that is likely to be acceptable. The user can recover by logging in again. Do Not Transfer Another option is to not transfer your app. Instead, ship a new version of the app from the new team and have the old app recommend that the user upgrade. There are a number of advantages to this approach. The first is that there’s absolutely no risk of losing any user data. The two apps are completely independent. The second advantage is that the user can install both apps on their device at the same time. This opens up a variety of potential migration paths. For example, you might ship an update to the old app with an export feature that saves the user’s state, including their secrets, to a suitably encrypted file, and then match that with an import facility on the new app. Finally, this approach offers flexible timing. The user can complete their migration at their leisure. However, there are a bunch of clouds to go with these silver linings: Your users might never migrate to the new app. If this is a paid app, or an app with in-app purchase, the user will have to buy things again. You lose the original app’s history, ratings, reviews, and so on. Get Creative Finally, you could attempt something creative. For example, you might: Publish a new version of the app that supports exporting the user’s state, including the secrets. Tell your users to do this, with a deadline. Transfer the app and then, when the deadline expires, publish the new version with an import feature. Frankly, this isn’t very practical. The problem is with step 2: There’s no good way to get all your users to do the export, and if they don’t do it before the deadline there’s no way to do it after. Test Before You Ship Once you have a new version of your app, with the new App ID prefix, it’s time to test. To run a day-to-day test: On a test device, install the existing version of the app from the App Store. Use the app to generate keychain items as a normal user would. For example, if you store login credentials in the keychain, use the app to save such a credential. In Xcode, run the new version of your app. Check that the keychain items you created in step 2 still work. After you upload this new version to App Store Connect, use TestFlight to run an internal test: On a test device, install the existing version of the app from the App Store. Use the app to generate keychain items as a normal user. For example, if you store login credentials in the keychain, use the app to save such a credential. Use TestFlight to update the app to your new version. Check that the keychain items you created in step 2 still work. Do this before you release the app to your beta testers and then again before releasing it to customers. WARNING These TestFlight test are your last chance to ensure that everything works. If you detect an error at this stage, you still have a chance to fix it. Revision History 2026-04-07 Added the Test Before You Ship section. 2026-03-31 Rewrote the Transfer Your App to Another Team section to describe a new approach for preserving access to keychain items across app transfers. Moved the previous discussion into a new Alternative Approaches for App Transfer section. Clarified that a macOS program can now use an app group as a keychain access group as long as its entitlements are validated. Made numerous editorial changes. 2022-05-17 First posted.

PLATFORM AND VERSION iOS Development environment: Xcode 26.2, macOS x Run-time configuration: iOS The issue does not seem to be limited to a specific version. DESCRIPTION OF PROBLEM We are reaching out to request in-depth technical assistance regarding an intermittent issue with Sign in with Apple implementation in our application. [Technical Status] We have confirmed that our technical implementation is correct. All necessary code and Xcode Capabilities are properly configured, and the service is working perfectly for the vast majority of our users. However, a small subset of users is consistently encountering "Unknown" Error (Error Code 1000), which prevents them from logging in entirely. [Identified Scenario] Currently, the only reproducible case we have found involves Child Accounts (protected accounts) under Family Sharing, specifically when the user's age is set below the regional requirement for a standalone Apple ID. However, we are receiving reports from other users who do not seem to fall into this category. [Requests for Clarification] To resolve this issue and support our users, we would like to obtain clear answers to the following questions: Root Cause: Why does Error 1000 occur specifically for a small number of users while the service works for most others? Other Scenarios: Are there any known cases or conditions other than the "Child Account" age restriction that trigger this specific error? Account-side Issues: If our code and configurations are verified to be correct, should we conclude that this is an issue specific to the individual's Apple ID/Account status? If so, could you provide a troubleshooting guide or official recommendation that we can share with these users to help them resolve their account-related issues? We are committed to providing a seamless authentication experience and would appreciate your expert insight into these edge cases. Thank you for your support. - (void) quickLogin:(uint)requestId withNonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *appleIDRequest = [[self appleIdProvider] createRequest]; [appleIDRequest setNonce:nonce]; [appleIDRequest setState:state]; ASAuthorizationPasswordRequest *keychainRequest = [[self passwordProvider] createRequest]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[appleIDRequest, keychainRequest]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) loginWithAppleId:(uint)requestId withOptions:(AppleAuthManagerLoginOptions)options nonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *request = [[self appleIdProvider] createRequest]; NSMutableArray *scopes = [NSMutableArray array]; if (options & AppleAuthManagerIncludeName) [scopes addObject:ASAuthorizationScopeFullName]; if (options & AppleAuthManagerIncludeEmail) [scopes addObject:ASAuthorizationScopeEmail]; [request setRequestedScopes:[scopes copy]]; [request setNonce:nonce]; [request setState:state]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[request]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) getCredentialStateForUser:(NSString *)userId withRequestId:(uint)requestId { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { [[self appleIdProvider] getCredentialStateForUserID:userId completion:^(ASAuthorizationAppleIDProviderCredentialState credentialState, NSError * _Nullable error) { NSNumber *credentialStateNumber = nil; NSDictionary *errorDictionary = nil; if (error) errorDictionary = [AppleAuthSerializer dictionaryForNSError:error]; else credentialStateNumber = @(credentialState); NSDictionary *responseDictionary = [AppleAuthSerializer credentialResponseDictionaryForCredentialState:credentialStateNumber errorDictionary:errorDictionary]; [self sendNativeMessageForDictionary:responseDictionary forRequestId:requestId]; }]; } else { [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif }

On Tahoe and earlier, ScreenCapture permissions can disappear and not return. Customers are having an issue with this disappearing and when our code executes CGRequestScreenCaptureAccess() nothing happens, the prompt does not appear. I can reproduce this by using the "-" button and removing the entry in the settings, then adding it back with the "+" button. CGPreflightScreenCaptureAccess() always returns the correct value but once the entry has been removed, CGRequestScreenCaptureAccess() requires a reboot before it will work again.

We have been having very high response times in device check device validation service (https://developer.apple.com/documentation/devicecheck/accessing-and-modifying-per-device-data#Create-the-payload-for-a-device-validation-request) since 17 July at 19:10hs GMT. The service information page says the service was running in green status but that isn't the case and we currenly have stop consuming it. Is it being looked at? Are you aware of this issue? Can you give us an estimate of when it should be working correctly?