Hi Apple Devs, For our app, we utilize passkeys for account creation (not MFA). This is mainly for user privacy, as there is 0 PII associated with passkey account creation, but it additionally also satisfies the 4.8: Login Services requirement for the App Store. However, we're getting blocked in Apple Review. Because the AASA does not get fetched immediately upon app install, the reviewers are not able to create an account immediately via passkeys, and then they reject the build. I'm optimistic I can mitigate the above. But even if we pass Apple Review, this is a pretty catastrophic issue for user security and experience. There are reports that 5% of users cannot create passkeys immediately (https://developer.apple.com/forums/thread/756740). That is a nontrivial amount of users, and this large of an amount distorts how app developers design onboarding and authentication flows towards less secure experiences: App developers are incentivized to not require MFA setup on account creation because requiring it causes significant churn, which is bad for user security. If they continue with it anyways, for mitigation, developers are essentially forced to add in copy into their app saying something along the lines of "We have no ability to force Apple to fetch the config required to continue sign up, so try again in a few minutes, you'll just have to wait." You can't even implement a fallback method. There's no way to check if the AASA is available before launching the ASAuthorizationController so you can't mitigate a portion of users encountering an error!! Any app that wants to use the PRF extension to encrypt core functionality (again, good for user privacy) simply cannot exist because the app simply does not work for an unspecified amount of time for a nontrivial portion of users. It feels like a. Apple should provide a syscall API that we can call to force SWCD to verify the AASA or b. implement a config based on package name for the app store such that the installation will immediately include a verified AASA from Apple's CDN. Flicking the config on would require talking with Apple. If this existed, this entire class of error would go away. It feels pretty shocking that there isn't a mitigation in place for this already given that it incentivizes app developers to pursue strictly less secure and less private authentication practices.

Hi everyone, I'm developing an iOS app using the AppsFlyer SDK. I understand that starting with iOS 14.5, if a user denies the App Tracking Transparency (ATT) permission, we are not allowed to access the IDFA or perform cross-app tracking. However, I’d like to clarify which in-app events are still legally and technically safe to send when the user denies ATT permission. Specifically, I want to know: Is it acceptable to send events like onboarding_completed, paywall_viewed, subscription_started, subscribe, subscribe_price, or app_opened if they are not linked to IDFA or any form of user tracking? Would sending such internal behavioral events (used purely for SKAdNetwork performance tracking or in-app analytics) violate Apple’s privacy policy if no device identifiers are attached? Additionally, if these events are sent in fully anonymous form (i.e., not associated with IDFA, user ID, email, or any identifiable metadata), does Apple still consider this a privacy concern? In other words, can onboarding_completed, paywall_viewed, subsribe, subscribe_price, etc., be sent in anonymous format without violating ATT policies? Are there any official Apple guidelines or best practices that outline what types of events are considered compliant in the absence of ATT consent? My goal is to remain 100% compliant with Apple’s policies while still analyzing meaningful user behavior to improve the in-app experience. Any clarification or pointers to documentation would be greatly appreciated. Thanks in advance!

Hi, A certificate imported on macOS 15 using the security command with the "non-exportable" option was imported in an exportable state. I would like to know how to change this certificate to be non-exportable. Regards, CTJ

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,

Please correct the following issues and upload a new binary to App Store Connect. ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/FirebaseCoreDiagnostics.framework/FirebaseCoreDiagnostics”, which includes FirebaseCoreDiagnostics, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/FBLPromises.framework/FBLPromises”, which includes FBLPromises, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/GoogleDataTransport.framework/GoogleDataTransport”, which includes GoogleDataTransport, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. our app is .NET MAUI app so we already addressed this by adding privacyinfo.xcprivacy privacy manifest under platform/ios/resources but still get flagged for this <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSPrivacyTracking</key> <false/> <key>NSPrivacyTrackingDomains</key> <array/> <key>NSPrivacyAccessedAPITypes</key> <array> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryFileTimestamp</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>C617.1</string> </array> </dict> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategorySystemBootTime</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>35F9.1</string> </array> </dict> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryDiskSpace</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>E174.1</string> </array> </dict> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryUserDefaults</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>CA92.1</string> </array> </dict> </array> <key>NSPrivacyCollectedDataTypes</key> <array/> </dict> </plist>

Hello, We plan to remove our app from the App Store. This post aims to determine whether our company can rely on Private Relay to compensate our customers. Our Challenge: Gift Card Refunds with Private Relay Some customers purchased gift cards through our app using Apple's "Private Relay" during account creation. To process refunds, we need a way to identify these customers. Our system relies on email addresses, which are masked by Private Relay. Potential Solution: Apps Using Apple ID We're exploring "Apps Using Apple ID" as a possible solution for customers to share their Private Relay addresses for refund purposes. Under what circumstances will an app cease to appear in the "Apps Using Apple ID" list? What conditions must be met to initiate a new Private Relay connection for the same user and application? For example, would using the same Apple account to sign into the app on a different device trigger a new Private Relay? Thank you for your help!

Hi all, I'm using a CryptoTokenKit (CTK) extension to perform code signing without having the private key stored on my laptop. The extension currently only supports the rsaSignatureDigestPKCS1v15SHA256 algorithm: func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool { return algorithm.isAlgorithm(SecKeyAlgorithm.rsaSignatureDigestPKCS1v15SHA256) } This setup works perfectly with codesign, and signing completes without any issues. However, when I try to use productsign, the system correctly detects and delegates signing to my CTK extension, but it seems to always request rsaSignatureDigestPKCS1v15SHA1 instead: productsign --timestamp --sign <identity> unsigned.pkg signed.pkg productsign: using timestamp authority for signature productsign: signing product with identity "Developer ID Installer: <org> (<team>)" from keychain (null) ... Error Domain=NSOSStatusErrorDomain Code=-50 "algid:sign:RSA:digest-PKCS1v15:SHA1: algorithm not supported by the key" ... productsign: error: Failed to sign the product. From what I understand, older versions of macOS used SHA1 for code signing, but codesign has since moved to SHA256 (at least when legacy compatibility isn't a concern). Oddly, productsign still seems to default to SHA1, even in 2025. Is there a known way to force productsign to use SHA256 instead of SHA1 for the signature digest algorithm? Or is there some flag or configuration I'm missing? Thanks in advance!

Our desktop app for macos will be released in 2 channels appstore dmg package on our official website for users to download and install Now when we debug with passkey, we find that the package name of the appstore can normally arouse passkey, but the package name of the non-App Store can not arouse the passkey interface I need your help. Thank you

Hello, I'm exploring the Secure Enclave APIs, and I'm wondering if it's possible to "cryptographically" determine if a block of data was signed on the Secure Enclave. When I sign a block of data using the Secure Enclave (which implies using a key pair automatically generated by the enclave) and distribute the public key to others, is there any way to verify if the message was encrypted on it / its private key was generated by it? In other words, what I'm trying to achieve is to make sure that the public key hasn't been tampered with until it reaches its destination (including on-device threats, since otherwise I could've used a normal keychain item, perhaps?). For the purpose of this example, I'm not necessarily interested in figuring out if the key was signed on a certain device's enclave, but rather on any Secure Enclave. So, using something derived from the enclave's GID Key (described in the Apple Platform Security guide) would work for this.

Hello -- I am developing an Authentication Plug-in for the purpose of invoking login with no user interaction (headless). There seems to be sufficient documentation and sample code on how to implement a plug-in and mechanism, and debug the same, which is great. What I am trying to understand is exactly how to modify the login right (system.login.console) in order to accomplish my goal. Question 1: I had the idea of installing my mechanism as the first mechanism of the login right, and when invoked to set the username and password into the engine’s context, in the belief that this would negate the system from needing to display the login screen. I didn’t modify or remove any other mechanisms. This did not work, in the sense that the login screen was still shown. Should this work in theory? Question 2: I then tried modifying the login right to remove anything that interacted with the user, leaving only the following: <array> <string>builtin:prelogin</string> <string>builtin:login-begin</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>MyAuthPlugin:customauth,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>CryptoTokenKit:login</string> </array> The mechanisms I removed were: <string>builtin:policy-banner</string> <string>loginwindow:login</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:authenticate,privileged</string> <string>loginwindow:success</string> <string>loginwindow:done</string> In place of builtin:authenticate I supplied my own mechanism to verify the user’s password using OD and then set the username and password in the context. This attempt appears to have failed quite badly, as authd reported an error almost immediately (I believe it was related to the AuthEngine failing to init). There’s very little information to go on as to what each of these mechanisms do, and which are required, etc. Am I on the wrong track in attempting this? What would be the correct approach?

Hi everyone, I am trying to use ASWebAuthenticationSession to authorize user using OAuth2. Service Webcredentials is set. /.well-known/apple-app-site-association file is set. When using API for iOS > 17.4 using new init with callback: .https(...) everything works as expected, however i cannot make .init(url: ,callbackURLScheme: ....) to work. How can i intercept callback using iOS <17.4? Do I really need to use universal links? callbackURL = https://mydomain.com/auth/callback

I am working on improving Keychain item storage secured with Face ID using SecAccessControlCreateWithFlags. The implementation uses the .biometryAny flag as shown below: SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .biometryAny, &amp;error ) While this approach generally works as expected, I encountered a specific edge case during testing. On iOS 18.3.1 with Xcode 15.4, the following sequence causes the Keychain item to become inaccessible: Navigate to Settings &gt; Face ID &amp; Passcode and select Reset Face ID. Before setting up a new Face ID, tap the Back button to exit the setup process. Reopen the Face ID setup and complete the enrollment. Return to the app—previously stored Keychain items protected by .biometryAny are no longer available. This behavior appears to be a change introduced in recent iOS versions. In versions prior to iOS 15, resetting or deleting Face ID entries did not invalidate existing Keychain items protected by .biometryAny. This difference in behavior between iOS versions raises questions about the changes to biometric protection handling. Any suggestions are welcomed that might shine a light on what the best practice to use keychain access control and prevent the data to become unavailable.

We recently transferred two applications to a different account, both of which utilize Keychain and shared app containers. Before transferring the first application, we anticipated losing access to the Keychain and took proactive measures by backing up data to the app’s private container in the final release prior to the transfer. During the app transfer process, we removed the shared container group ID from the old account and recreated it under the new account. In our testing, Keychain restoration from the local backup was successful, and users experienced no disruptions. However, after releasing the application, we observed that approximately 25% of our users not only lost their Keychain data as expected but also their shared app container data. As we have been unable to reproduce this issue internally, we are seeking your guidance on how to prevent a similar situation when transferring our second application. At this stage, we have not yet released any updates from the new account, and the Keychain data remains backed up in the app’s private container. We would appreciate any insights or recommendations you can provide to ensure a smooth transition for our users and make sure we can keep the data in shared container.

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

Why does the following code generate a public key that can't be parsed by openssl? import Security import CryptoKit func generateKeys() throws -> (privateKey: SecKey, publicKey: SecKey) { let query: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrIsPermanent as String: false ] var error: Unmanaged<CFError>? guard let privateKey = SecKeyCreateRandomKey(query as CFDictionary, &error) else { throw error!.takeRetainedValue() } let publicKey = SecKeyCopyPublicKey(privateKey)! return (privateKey, publicKey) } extension SecKey { func exportBase64EncodedKey() -> String { var error: Unmanaged<CFError>? guard let data = SecKeyCopyExternalRepresentation(self, &error) else { fatalError("Failed to export key: \(error!.takeRetainedValue())") } return (data as Data).base64EncodedString(options: [.lineLength64Characters]) } } func printPublicKey() { let keyPair = try! generateKeys() let encodedPublicKey = keyPair.publicKey.exportBase64EncodedKey() var header = "-----BEGIN PUBLIC KEY-----" var footer = "-----END PUBLIC KEY-----" var pemKey = "\(header)\n\(encodedPublicKey)\n\(footer)\n" print(pemKey) } printPublicKey() when parsing the key I get this: openssl pkey -pubin -in new_public_key.pem -text -noout Could not find private key of Public Key from new_public_key.pem 404278EC01000000:error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported:crypto/encode_decode/decoder_lib.c:102:No supported data to decode. Replacing kSecAttrKeyTypeECSECPrimeRandom with kSecAttrKeyTypeRSA and a bigger key size (e.g. 2048) gives me a working public key that can be parsed by Openssl. Thanks!

Hello, I have created an app for both iOs and Android where upon speaking two trigger words, the listening app sends a text and then calls to an inputted designated phone contact. The Android version works perfectly. The iOs version also works perfectly but the iOs app emiits a PopUp for each, the text and then the call asking "Do you really want to send the text -or- make the call". Basically, I input the contact info and I spoke the trigger words. So, yes I want to send the text and make the call. So, I have to click the two PopUps then the device sends and calls. Is there a way to suppress the PopUps in any way? The app is designed for emergencies. So, a dely to anser a popup is not at all good. Maybe by telling the device to allow auto calls and texts from my app? Any and all help on this issue will be very welcomed... Thanks :)

Our app uses Face ID to optionally secure access to the app for device owner. This not the new 'Require Face ID' feature of iOS 18 - this is our own custom implementation that has some other related logic for authentication handling. Starting in iOS 18.3.1, starting the app results in multiple Face Id checks being fired - sometimes just a couple but sometimes many more. Curiously, this is happening even when I completely disable any code we have that prompts for Face ID. It appears to come from nowhere. This does not happen on prior iOS 18 releases so, while I might be doing something improper in the code, something specific has changed in iOS 18.3.1 to cause this issue to manifest. I'm looking for advice as to what could be occurring here, how to debug a Face Id check that appears to come from nowhere, and what, if any, workarounds exist.

Hi,is there an option to mark the file or folder or item stored in user defaults ... not to be backed up when doing unencrypted backup in iTunes?We are developing iOS app that contains sensitive data. But even if we enable Data Protection for the iOS app it can be backed up on mac unencrypted using iTunes. Is there a way to allow backing up content only if the backup is encrypted?

I have my custom Authplugin implemented at login (system.login.console), and I want to remove password requirement validation/authentication from system.login.console authorization right. Do you see any functionality loss in completely removing password need at login. And is there any reference which can help me here to acheive this?

I have a small command-line app I've been using for years to process files. I have it run by an Automator script, so that I can drop files onto it. It stopped working this morning. At first, I could still run the app from the command line, without Automator. But then after I recompiled the app, now I cannot even do that. When I run it, it's saying 'zsh: killed' followed by my app's path. What is that? The app does run if I run it from Xcode. How do I fix this?