With Let's Encrypt having completely dropped support for OCSP recently [1], I wanted to ask if macOS has a means of keeping up to date with their CRLs and if so, roughly how often this occurs? I first observed an issue where a revoked-certificate test site, "revoked.badssl.com" (cert signed by Let's Encrypt), was not getting blocked on any browser, when a revocation policy was set up using the SecPolicyCreateRevocation API, in tandem with the kSecRevocationUseAnyAvailableMethod and kSecRevocationPreferCRL flags. After further investigation, I noticed that even on a fresh install of macOS, Safari does not block this test website, while Chrome and Firefox (usually) do, due to its revoked certificate. Chrome and Firefox both have their own means of dealing with CRLs, while I assume Safari uses the system Keychain and APIs. I checked cert info for the site here [2]. It was issued on 2025-07-01 20:00 and revoked an hour later. [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=revoked.badssl.com

Seeing the following error when attempting automatic passkey upgrade - [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. We're trying to enable Automatic passkey upgrade (https://developer.apple.com/videos/play/wwdc2024/10125/?time=38) for our website but it's not working from our testing on iOS 18.2 and 18.3 Beta Safari. The flow on our website looks like: the customers use autofill to fill out email and password on the sign-in page (abc.com/signin) PublicKeyCredential.getClientCapabilities is called to check if conditionalCreate supported. land on another page of our website (abc.com/pageX), which calls navigator.credentials.create with mediation conditional (Right after sign-in). We checked that we followed the steps in above video: Allow automatic passkey upgrades is enabled, mediation is set to conditional and password autofill is used to signed in. However, Safari threw an error [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Can Apple help guide us if anything is missed here?

Hello, We’ve resumed the migration process after a break. Since my colleague is no longer with us, I had to go through the steps again myself. As before, we’re trying to migrate "Sign In with Apple" users from tenant TENANT_A with client_id=CLIENT_ID_A to tenant TENANT_B with client_id=CLIENT_ID_B I followed the procedure described here: [Apple Developer Documentation](https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer – Migrating Sign In with Apple Users, essentially repeating what my coworker previously attempted in coordination with your employee Stephanie. Here’s a summary of the steps and the issue we’re facing: STEP 1 - get authcode for TEAM A curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=pl.CLIEND_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' I receive response: { "access_token": "<ACCESS_TOKEN_TEAM_A>", "token_type": "Bearer", "expires_in": 3600 } STEP 2 - get authcode for TEAB B curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAB_B_SECRET>' I receive response: { "access_token":"<ACCESS_TOKEN_TEAB_B>", "token_type": "Bearer", "expires_in": 3600 } STEP 3 - get transfer_sub from TEAM A curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_A>' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' --data-urlencode 'sub=USER_SUB_FROM_TEAM_A' --data-urlencode 'target=TENANT_B' I receive response: { "transfer_sub": "USER_SUB_FROM_TEAM_B" } STEP 4 - Team B exchanges transfer identifers curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_B' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAM_B_SECRET>' I receive response: { "error": "invalid_request" } We’ve created a new client_id under tenant B and want to migrate users there. However, we skipped the step described in Step 3 of the documentation(https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#3-Team-A-initiates-app-transfer-to-Team-B), which involves initiating an app transfer. The reason is that this client_id is used solely for web authentication, not for a mobile app, so we don’t have an app to transfer. Based on our analysis and your documentation, it seems this flow only works if the client_id matches across both tenants, which can only be achieved through an app transfer, something we cannot proceed with. Apple previously insisted that we migrate these users, but as shown above, we’re stuck. Is there any alternative flow available, or can you assist us in completing this migration?

we can get token but when send to verity from apple. it reture Error : {"responseCode":"400","responseMessage":"Missing or incorrectly formatted device token payload"}

Is there a step by step program on Sending Push notifications? I seem to be stuck at load private key. I get this error. SecKeyCreateWithData failed with error: Error Domain=NSOSStatusErrorDomain Code=-50 "EC private key creation from data failed" It is a new p8 file. I tried different format. I read some articles that say that there is a bug I think. I don't know for sure because it was written in jibberish. 90% of the code is dealing with these stupid keys. This should be 1 function setting the pipe and then I can use the pipe. This is ridiculous. If anybody has any ideas. The code is a mess because I tried so many different ideas. Push Notification.txt

Hi everyone, I'm experiencing an intermittent issue with Keychain data loss on the latest iOS Beta 2. In about 7% of cases, users report that previously saved Keychain items are missing when the app is relaunched — either after a cold start or simply after being killed and reopened. Here are the key observations: The issue occurs sporadically, mostly once per affected user, but in 3 cases it has happened 4 times. No explicit deletion is triggered from the app. No system logs or error messages from Apple indicate any Keychain-related actions. The app attempts to access Keychain items, but they are no longer available. This behavior is inconsistent with previous iOS versions and is not reproducible in development environments. This raises concerns about: Whether this is a bug in the beta or an intentional change in Keychain behavior. Whether this could affect production apps when the final iOS version is released. The lack of any warning or documentation from Apple regarding this behavior. Has anyone else encountered similar issues? Any insights, workarounds, or official clarification would be greatly appreciated. Thanks!

Hi, It may be a stupid question, but we really wonder if there is a way for MDM to push a unique mTLS cert to our iOS application or if it can populate a client certificate in the iOS where our application can access it. Like browser app, how do browser mTLS certs get pushed? Thanks, Ying

Using the SDK, I've printed out some log messages when I enter the wrong password: 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] invoke 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] general: 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] progname: 'SecurityAgentHelper-arm64' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] OS version: 'Version 15.5 (Build 24F74)' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] pid: '818' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] ppid: '1' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] euid: '92' 2025-08-20 15:58:14.086 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] uid: '92' 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] session: 0x186e9 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] attributes: 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] is root: f 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] has graphics: t 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] has TTY: t 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] is remote: f 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] auth session: 0x0 2025-08-20 15:58:14.087 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] context: 2025-08-20 15:58:14.088 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] authentication-failure: --S -14090 2025-08-20 15:58:14.088 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] pam_result: X-S 9 2025-08-20 15:58:14.089 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] hints: 2025-08-20 15:58:14.089 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] authorize-right: "system.login.console" 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-path: "/System/Library/CoreServices/loginwindow.app" 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-pid: 807 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-type: 'LDNB' 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-uid: 0 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-audit-token: 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................ 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] 00 00 00 00 27 03 00 00 e9 86 01 00 68 08 00 00 ....'.......h... 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-pid: 807 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] flags: 259 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] reason: 0 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] tries: 1 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] immutable hints: 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-apple-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] client-firstparty-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-apple-signed: true 2025-08-20 15:58:14.090 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] creator-firstparty-signed: true 2025-08-20 15:58:14.091 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] arguments: 2025-08-20 15:58:14.091 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] none 2025-08-20 15:58:14.108 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] LAContext: LAContext[4:8:112] 2025-08-20 15:58:14.119 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] token identities: 0 2025-08-20 15:58:14.120 Db SecurityAgentHelper-arm64[818:1efd] [com.example.apple-samplecode.LoggingAuthPlugin:mechanism] token watcher: <TKTokenWatcher: 0x11410ee70> Specifically, is there a manual/link somewhere that can allow me to interpret: authentication-failure: --S -14090 and pam_result: X-S 9

Has anybody else experienced something similar? This is on the login screen. I call update() and it doesn't call me back with view() 2025-08-21 17:04:38.669 Db SecurityAgentHelper-arm64[1134:2df1] [***:LoginView] calling update() Then silence...

We have an app that has failed during the app review for the Japanese market but has been accepted in several other markets successfully. We need the user's name in native Katakana format as we need it to be displayed in our restaurant Point of Sale systems for workers to be able to read and understand. We use 'Sign up with Apple', but when doing so, if this returns an anglicised given and family name, we have to request the customer supply their Katakana format name so that our in-store systems and staff can process and fulfil their orders. When the App Review process automatically tests the app, it uses "Apple John" as a customer's name. Since this is not a Japanese name, we ask for it again in the correct format, or we cannot allow the user to register. This contravenes Apple's rules, and thus, our app is rejected. If the Apple identity used belonged to a user more typical of the target market, it would work as required. Does anyone else have this issue, and how did you work around it? Tim

I have had a password autofill app extension in production for years. It still works fine. Except when the user taps a username or password textfield and selects "AutoFill" from the context menu. They are shown a modal error dialog, stating: "AutoFill Unavailable - The developer needs to update it to work with this feature." I cannot find any help on this issue. The AutoFill extension works fine when tapping the "Passwords" bar above the iOS keyboard. Any pointers would be appreciated.

Due to business requirements, we need to transfer our app Gem Space for iOS from our current Apple Developer account to a new account. We have a major concern regarding our users and the data associated with the app. The user data is currently stored using an App Group with the identifier, for example: "group.com.app.sharedData" According to some information we’ve found, it might be possible to complete the transfer by removing the App Group from the old account and creating a new one with the same identifier in the new account. However, other sources suggest that App Group containers are owned by the specific team, and data stored in the container may become inaccessible after the app is transferred to a different team. This raises concerns about the possibility of users losing access to their data after updating the app from the new account. Could you please clarify the expected behavior of App Groups in this case? Do we need to perform any kind of data migration, and if so, could you please provide detailed guidance on how to do it safely and without impacting user data access?

Hello, We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide. Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues. These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists. Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated. Thank you.

I am developing a custom authorization plugin for macOS, and I’ve encountered an issue where the auth plugin view remains visible on the home screen for a few seconds after login. Issue Details: After entering valid credentials, I call setResult(.allow) in my plugin to proceed with login. The authentication succeeds, and macOS starts transitioning to the home screen. However, for a few seconds after login, the authorization plugin view is still visible on the home screen before it disappears. I have observed this issue even when using Apple's sample authorization plugin. Observation: This issue occurs without an external monitor (on a single built-in display). If I manually close the plugin window inside Destroy(AuthPlugin.mechanism), then the auth plugin views do not appear on the home screen, which seems to fix the issue. However, when I do this, a gray screen appears for about a second before the desktop environment fully loads. I suspect that the gray screen appears due to the time macOS takes to fully load the home screen environment after login. Questions: Why does the authorization plugin view persist on the home screen for a few seconds after login? Is manually closing the plugin window in Destroy(AuthPlugin.mechanism) the correct way to prevent this, or is there a better approach? Is my assumption that the gray screen appears due to the home screen not being fully loaded correct? If the gray screen is caused by home screen loading, is there a system notification or event I can listen to in order to know when the home screen has fully loaded?

Dear Apple Developer Support Team, We are experiencing a recurring issue with the DeviceCheck API where the following error is being returned: com.apple.devicecheck.error 0 Upon analyzing our logs, we have noticed that this error occurs significantly more often when users are connected to Wi-Fi networks, compared to mobile networks. This leads us to suspect that there might be a relationship between Wi-Fi configuration and the DeviceCheck service’s ability to generate or validate tokens. We would like to know: Is this error code (0) known to be caused by specific types of network behavior or misconfigurations on Wi-Fi networks (e.g., DNS filtering, firewall restrictions, proxy servers)? Are there any recommended best practices for ensuring reliable DeviceCheck API communication over Wi-Fi networks? Additionally, could you please clarify what general conditions could trigger this com.apple.devicecheck.error 0? The lack of specific documentation makes debugging this issue difficult from our side. Any guidance or internal documentation on this error code and its potential causes would be greatly appreciated. IDE: Xcode 16.3 Looking forward to your support. Best regards,

Hi, we were recently approved for the com.apple.developer.web-browser.public-key-credential entitlement and have added it to our app. It initially worked as expected for a couple of days, but then it stopped working. We're now seeing the same error as before adding the entitlement: Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" Do you have any insights into what might be causing this issue? Thank you!

Hi team, We are experiencing an issue where some users in China are unable to create passkeys due to authentication errors. This is the UI flows The method we use to prompt users is passkey creation. Technically, this is implemented using Apple’s AuthenticationServices framework. We create an instance of ASAuthorizationController and conform to ASAuthorizationControllerDelegate to handle the results of the authentication attempt. In failure cases, we receive ASAuthorizationError.failed (code 1004), along with some additional details describing the nature of the failure. However, we are currently unable to determine the exact root cause of this issue or how to resolve it. At this point, we can only make assumptions based on the limited error information provided. Our current hypothesis is that due to network restrictions, Apple may be unable to reach the .well-known endpoint where we host the associated domain file. Alternatively, even if the file is successfully loaded and cached to Apple’s CDN, the system in China may not be able to reach the CDN itself. We would greatly appreciate it if you could help us understand what might be causing this problem and guide us on how we can resolve it effectively. Thanks, Hung

Since release of 18.4. prepareInterfaceToProvideCredential .oneTimeCode case is not called and instead prepareInterfaceForUserChoosingTextToInsert() is called. That is the wrong delegate for this case and it causes confusion for the users. Also, some TOTP fields are recognised however, the key icon button is not presented above the keyboard next to TOTP suggestions. I've also tested 18.5 and it has the same issue. provideOneTimeCodeWithoutUserInteraction works just fine.

Hello, I’m trying to set up Sign In with Apple for my Firebase Authentication integration. Steps I followed: Created a Service ID in Apple Developer, e.g. com.example.myapp.signin. Tried to enable Sign In with Apple and configure the Web Authentication Configuration. Web Domain: myapp.firebaseapp.com Return URL: https://myapp.firebaseapp.com/__/auth/handler When I click Save, I get the following error in the browser console and a blank response page: Unsupported Request PATCH to http://developer.apple.com/services-account/v1/bundleIds/XXXXXXXX not supported. Reference #... What I have verified so far: My Apple Developer Program membership is active (paid). My App ID (e.g. com.example.myapp) exists in Identifiers. The App ID has Sign In with Apple capability checked. I need to link the Service ID with this App ID for Firebase web-based auth. Goal: Complete setup of Apple as a sign-in provider in Firebase Authentication. To do this, Apple requires me to add the Firebase return URL above, but the Developer Portal prevents saving with the 501 error. Has anyone else run into this, and is there a workaround (e.g. enabling via Xcode, App Store Connect, or other methods)? Is this a known bug with the Apple Developer Portal? Here is the screenshot of the error: And Response part: Thanks in advance!

Using the simplified sign-in with tvOS and a third party password manager, I receive a complete ASPasswordCredential, and I can easily log into my app. When I do the same thing but with Apple's password manager as the source, I receive an ASPasswordCredential that includes the email address, but the password is an empty string. I have tried deleting the credentials from Apple Passwords and regenerating them with a new login to the app's website. I have tried restarting my iPhone. Is this the expected behavior? How should I be getting a password from Apple's Password app with an ASAuthorizationPasswordRequest?