Hi, I’ve added attestation to my app, and everything worked as expected during setup. However, after deployment, I noticed some unknownSystemFailure entries in the production logs on New Relic. Could you help me understand what typically causes this error? The documentation suggests issues such as failing to generate a token. What scenarios could lead to that?

General: Forums subtopic: Privacy & Security > General Forums tag: App Sandbox App Sandbox documentation App Sandbox Design Guide documentation — This is no longer available from Apple. There’s still some info in there that isn’t covered by the current docs but, with the latest updates, it’s pretty minimal (r. 110052019). Still, if you’re curious, you can consult an old copy [1]. App Sandbox Temporary Exception Entitlements archived documentation — To better understand the role of temporary exception entitlements, see this post. Embedding a command-line tool in a sandboxed app documentation Discovering and diagnosing App Sandbox violations (replaces the Viewing Sandbox Violation Reports forums post) Resolving App Sandbox Inheritance Problems forums post The Case for Sandboxing a Directly Distributed App forums post Implementing Script Attachment in a Sandboxed App forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For example, this one archived by the Wayback Machine.

Hi everyone, I’m developing a multiplayer iOS game that uses Multipeer Connectivity for local peer-to-peer networking. I’d like to display user-assigned device names in the UI to help players identify each other during the connection process. In iOS 16 and later, accessing UIDevice.current.name requires the User-Assigned Device Name Entitlement. The documentation states that the entitlement is granted for functionality involving “interaction between multiple devices that the same user operates”. My game is strictly multiplayer, with devices owned by different users, not a single user managing multiple devices. I have a few questions regarding this: Does the requirement for “devices operated by the same user” definitively exclude multiplayer scenarios where devices belong to different players? Can a Multipeer Connectivity-based game qualify for the entitlement in this case? If the entitlement is not applicable, is prompting users to enter custom names the recommended approach for identifying devices in a multiplayer UI? Has anyone successfully obtained this entitlement for a similar multiplayer use case with Multipeer Connectivity? Thanks in advance.

We are using ASWebAuthenticationSession with apps on IoS to achieve SSO between apps. The IdP for authentication (OIDC) is an on-premise and trusted enterprise IdP based on one of the leading products in the market. Our problem is that the user is prompted for every login (and logouts) with a consent dialogue box: “AppName” wants to use “internal domain-name” to Sign In This allows the app and website to share information about you. Cancel Continue” I have read in various places that Apple has a concept of “Trusted domains” where you can put an “Apple certified” static web-page on the IdP. This page needs to contain specific metadata that iOS can verify. Once a user logs in successfully a few times, and if the IdP is verified as trusted, subsequent logins would not prompt the consent screen. Question: I struggle to find Apple documentation on how to go about a process that ends with this “Apple certified web-page” on our IdP”. Anyone who has experience with this process, or who can point me in some direction to find related documentation?

Hi, Xcode Instruments shows multiple Points of Interest with the information that the framework is not listed in my Privacy Manifest. However, I have already included them in the Privacy Manifest under the privacy tracking domains. I have this problem with every tracking domain i listed in the Privacy Manifest's Privacy Tracking Domains. Did I make a mistake in my Privacy Manifest declaration?

this is my monitor image that shows DeviceCheck api responding very slowly.

Hi. We are trying to get the access token before calling any API. The app can go in bad network areas but the token acquisition keeps happening for the network call. The devices are managed devices which means it has some policies installed. We are using MSAL lib for the authentication and we are investigating from that angle too but the below error seems to be coming from apple authentication which needs our attention. ========================================== LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=68, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=68, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1003 "(null)" ========================================== This happens mostly when we switches the network or keep the device in no or low network area. This comes sometimes when app goes in background too. Just trying to give as much as information I could. Any lead would be highly appreciated. Thank you

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.

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

My app Mocawave is a music player distributed through the Mac App Store. It declares specific audio document types (public.mp3, com.microsoft.waveform-audio, public.mpeg-4-audio, public.aac-audio) in its CFBundleDocumentTypes with a Viewer role. When a user sets Mocawave as the default app for audio files and double-clicks an MP3 downloaded from the internet (which has the com.apple.quarantine extended attribute), macOS displays the alert: "Apple could not verify [filename] is free of malware that may harm your Mac or compromise your privacy." This does not happen when: Opening the same file via NSOpenPanel from within the app Opening the same file with Apple's Music.app or QuickTime Player The app is: Distributed through the Mac App Store Sandboxed (com.apple.security.app-sandbox) Uses com.apple.security.files.user-selected.read-write entitlement The file being opened is a regular audio file (MP3), not an executable. Since the app is sandboxed and distributed through the App Store, I expected it to have sufficient trust to open quarantined data files without triggering Gatekeeper warnings — similar to how Music.app and QuickTime handle them. Questions: Is there a specific entitlement or Info.plist configuration that allows a sandboxed Mac App Store app to open quarantined audio files without this alert? Is this expected behavior for third-party App Store apps, or could this indicate a misconfiguration on my end? Environment: macOS 15 (Sequoia), app built with Swift/SwiftUI, targeting macOS 13+.

we develop extension "Autofill Credential Provider" function for passkey. 1.first step registe passkey 2.second step authenticate with passkey step 1 & step 2 has finished and run success with provideCredentialWithoutUserInteraction. But we want to prepare our interface for use to input password and select passkey what the want. however the func prepareInterfaceToProvideCredential in ASCredentialProviderViewController does call? what i missed? how can i do it?

Hi, We're in the process of implementing Apple's App Integrity, but am getting stalled due to missing documents. Can anyone assist with this? We've been following https://aninterestingwebsite.com/documentation/devicecheck/validating-apps-that-connect-to-your-server to make the necessary updates, but have come up short with where the document references decoding the Attestation Object. Can we get more information here and how the decoding process work?

Hello, sorry for the awkward text formatting but I kept getting prevented from positing due to "sensitive language"... Help.txt

% curl -v https://app-site-association.cdn-apple.com/a/v1/zfcs.bankts.cn Host app-site-association.cdn-apple.com:443 was resolved. IPv6: (none) IPv4: 218.92.226.151, 119.101.148.193, 218.92.226.6, 115.152.217.3 Trying 218.92.226.151:443... Connected to app-site-association.cdn-apple.com (218.92.226.151) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /etc/ssl/cert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted http/1.1 Server certificate: subject: C=US; ST=California; O=Apple Inc.; CN=app-site-association.cdn-apple.com start date: Sep 25 13:58:08 2025 GMT expire date: Mar 31 17:44:25 2026 GMT subjectAltName: host "app-site-association.cdn-apple.com" matched cert's "app-site-association.cdn-apple.com" issuer: CN=Apple Public Server RSA CA 11 - G1; O=Apple Inc.; ST=California; C=US SSL certificate verify ok. using HTTP/1.x GET /a/v1/zfcs.bankts.cn HTTP/1.1 Host: app-site-association.cdn-apple.com User-Agent: curl/8.7.1 Accept: / Request completely sent off < HTTP/1.1 404 Not Found < Content-Type: text/plain; charset=utf-8 < Content-Length: 10 < Connection: keep-alive < Server: nginx < Date: Wed, 04 Feb 2026 02:26:00 GMT < Expires: Wed, 04 Feb 2026 02:26:10 GMT < Age: 24 < Apple-Failure-Details: {"cause":"context deadline exceeded (Client.Timeout exceeded while awaiting headers)"} < Apple-Failure-Reason: SWCERR00301 Timeout < Apple-From: https://zfcs.bankts.cn/.well-known/apple-app-site-association < Apple-Try-Direct: true < Vary: Accept-Encoding < Via: https/1.1 jptyo12-3p-pst-003.ts.apple.com (acdn/3.16363), http/1.1 jptyo12-3p-pac-043.ts.apple.com (acdn/3.16363), https/1.1 jptyo12-3p-pfe-002.ts.apple.com (acdn/3.16363) < X-Cache: MISS KS-CLOUD < CDNUUID: 736dc646-57fb-43c9-aa0d-eedad3a534f8-1154605242 < x-link-via: yancmp83:443;xmmp02:443;fzct321:443; < x-b2f-cs-cache: no-cache < X-Cache-Status: MISS from KS-CLOUD-FZ-CT-321-35 < X-Cache-Status: MISS from KS-CLOUD-XM-MP-02-16 < X-Cache-Status: MISS from KS-CLOUD-YANC-MP-83-15 < X-KSC-Request-ID: c4a640c815640ee93c263a357ee919d6 < CDN-Server: KSFTF < X-Cdn-Request-ID: c4a640c815640ee93c263a357ee919d6 < Not Found Connection #0 to host app-site-association.cdn-apple.com left intact

Trusted execution is a generic name for a Gatekeeper and other technologies that aim to protect users from malicious code. General: Forums topic: Code Signing Forums tag: Gatekeeper Developer > Signing Mac Software with Developer ID Apple Platform Security support document Safely open apps on your Mac support article Hardened Runtime document WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04: 32), most notably app bundle protection WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46), namely, app container protection WWDC 2024 Session 10123 What’s new in privacy covers an important change in macOS 15 (starting at 12:23), namely, app group container protection Updates to runtime protection in macOS Sequoia news post Testing a Notarised Product forums post Resolving Trusted Execution Problems forums post App Translocation Notes (aka Gatekeeper path randomisation) forums post Most trusted execution problems are caused by code signing or notarisation issues. See Code Signing Resources and Notarisation Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Apple Team and Community, We encountered a sudden and widespread failure related to the App Attest service on Friday, July 25, starting at around 9:22 AM UTC. After an extended investigation, our network engineers noted that the size of the attestation objects received from the attestKey call grew in size notably starting at that time. As a result, our firewall began blocking the requests from our app made to our servers with the Base64-encoded attestation objects in the payload, as these requests began triggering our firewall's max request length rule. Could Apple engineers please confirm whether there was any change rolled out by Apple at or around that time that would cause the attestation object size to increase? Can anyone else confirm seeing this? Any insights from Apple or others would be appreciated to ensure continued stability. Thanks!

I have a very basic binary question around passkeys. Assuming everything is on latest and greatest version with respect to iOS, when user starts creating a passkey in platform-authenticator i.e., iCloudKeyChain (Apple Password Manager) , will iCloudKeyChain create a hardware-bound passkey in secure-enclave i.e., is brand new key-pair created right inside Secure-enclave ? OR will the keypair be created in software i.e., software-bound-passkey ?? i.e., software-bound keypair and store the private-key locally in the device encrypted with a key that is of course created in secure-enclave.

冷启动后我们读文件，发现："error_msg":"未能打开文件“FinishTasks.plist”，因为你没有查看它的权限。 是否有这些问题： 「iOS 26 iPhone 16,2 cold launch file access failure」） 核心内容：多名开发者反馈 iPhone 15 Pro（iOS 26.0/26.1）冷启动时读取 Documents 目录下的 plist 文件提示权限拒绝，切后台再切前台恢复，苹果员工回复「建议延迟文件操作至 applicationDidBecomeActive 后」。

In iOS 18, i use CNContactPickerViewController to access to Contacts (i know it is one-time access). After first pick up one contact, the Setting > Apps > my app > Contacts shows Private Access without any option to close it. Is there any way to close it and undisplay it ? I tried to uninstall and reinstall my app, but it didn't work.