We need to transfer an App to other developer account, both the account are belong to our company. As we know, our app is using the Sign in with Apple function that we need to do some transfer job and we refer to this document: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer. There is a lot of users using the Sign in with Apple in our app, totally serval millions. To avoid risks as much as possible that we have to make the work flow very clearly, so we're seeking help here. I have serval questions, some I've got the answers from Google gemini and this Forums, I will list them below, please take a look what I understanding is correct or not, thanks. A. From the document above, can I performed the Steps 1&2 before the app transfer? if so, is there a maximum lead time for these transfer_subs? B. Regarding Step 5(Team B exchanging transfer identifiers via https://appleid.apple.com/auth/usermigrationinfo) are there specific rate limits (requests per second/minute) for this endpoint? Cause we have a huge number of user whose using the Sign in with Apple, we have to transfer the sub values as soon as possible. C. Cause we have a huge number of user whose using the Sign in with Apple again, This transfer job involves huge risks. So, is there any way to simulate these whole operations? Answer by my self: NO.

I'm trying to confirm the correct URL for Apple Attest development. There seems to be a fraud metric risk section that uses this: https://data-development.appattest.apple.com/v1/attestationData However the key verification seems to use this: https://data-development.appattest.apple.com/v1/attestation Currently I'm attempting to verify the key, so the second one seems likely. However I keep receiving a 404 despite vigorous validation of all fields included in the JSON as well as headers. Can anyone confirm please, which URL I should be sending my AppleAttestationRequest to?

From watching the video on App Attest the answer would appear to be no, but the video is a few years old so in hope, I thought I would post this question anyway. There's several scenarios where I would like a notification service extension to be able to use App Attest in communications with the back end(for example to send a receipt to the backend acknowledging receipt of the push, fetching an image from a url in the push payload, a few others). Any change App Attest can be used in by a notification service extension?

I have a project with a single app target that serves two environments, and two schemes, one for each env, using xcconfig files for defining environment-specific stuff. I'm trying to figure this out for months, so I've tried multiple approaches throughout this period: Have a single domain in "Associated domains" in Xcode, defined as webcredentials:X where X gets replaced using a value from xcconfig. Have two domain entries in "Associated domains" webcredentials:PROD_DOMAIN and webcredentials:STAGING_DOMAIN. Have a different order of domains Results are very interesting: whatever I do, whatever approach I take, password autofill works on staging, but doesn't work on production. I'm aware that we need to test production on Test Flight and AppStore builds. That's how we're testing it, and it's not working. Tested on multiple devices, on multiple networks (wifi + mobile data), in multiple countries.. you name it. The server side team has checked their implementation a dozen times; it's all configured properly, in the exact same way across environments (except bundle ID, ofc). We tried a couple websites for validating the apple-app-site-association file, and while all of those are focused on testing universal links, they all reported that the file is configured properly. Still, password autofill doesn't work. I prefer not to share my app's domains publicly here. Ideally I would contact Apple Developer Support directly, but they now require a test project for that, and since 'a test project' is not applicable to my issue, I'm posting here instead.

I’m looking for clarification on how rate limiting works for the App Attest service, especially in production environments. According to the entitlement documentation (https://developer.apple.com/documentation/BundleResources/Entitlements/com.apple.developer.devicecheck.appattest-environment), iOS ignores the environment setting once an app is distributed through TestFlight, the App Store, or Enterprise distribution, and always contacts the production App Attest endpoint. With that context, I have two questions: Rate‑Limiting Thresholds How exactly does rate limiting work for App Attest? Is there a defined threshold beyond which attestation requests begin to fail? The "Preparing to Use the App Attest Service" documentation (https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service) recommends ramping up no more than 10 million users per day per app, but I’m trying to understand what practical limits or failure conditions developers should expect. Per‑AppID Budgeting If multiple apps have different App IDs, do they each receive their own independent attestation budget/rate limit? Or is the rate limiting shared across all apps under the same developer account?

Hello, I am using the prf extension for passkeys that is available since ios 18 and macos15. I am using a fixed, hardcoded prf input when creating or geting the credentials. After creating a passkey, i try to get the credentials and retrieve the prf output, which works great, but i am getting different prf outputs for the same credential and same prf input used in the following scenarios: Logging in directly (platform authenticator) on my macbook/iphone/ipad i get "prf output X" consistently for the 3 devices When i use my iphone/ipad to scan the qr code on my macbook (cross-platform authenticator) i get "prf output Y" consistently with both my ipad and iphone. Is this intended? Is there a way to get deterministic prf output for both platform and cross-platform auth attachements while using the same credential and prf input?

Dear Apple Developer Support, We are currently encountering a recurring issue with the DeviceCheck API across multiple devices in our production environment. The following error is frequently returned: com.apple.devicecheck.error 0 We would like to ask the following: What are the possible underlying causes that could lead to this specific error code (0) in the DeviceCheck API? Is there any known behavior or condition where Wi-Fi network configurations (e.g., DNS filtering, proxy settings, captive portals) could result in this error? Are there known timeouts, connectivity expectations, or TLS-level requirements that the DeviceCheck API enforces which could fail silently under certain network conditions? Is this error ever triggered locally (e.g., client library-level issues) or is it always from a failed communication with Apple’s servers? Any technical clarification, documentation, or internal insight into this error code would be greatly appreciated. This would help us significantly narrow down root causes and better support our users

We use Jamf Blueprint to deploy the managed app and identity to the iOS device (iOS 26.3 installed). Our managed app can access the identity via let identityProvider = ManagedAppIdentitiesProvider() let identity: SecIdentity do { identity = try await identityProvider.identity(withIdentifier: "myIdentity") } catch { } However, the app extension cannot access the same identity. Our app extension is notification extension that implemented UNNotificationServiceExtension APIs. We use above code in didReceive() function to access identity that always failed. The MDM configuration payload is: "AppConfig": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] }, "ExtensionConfigs": { "Identifier (com.example.myapp.extension)": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] } }, "ManifestURL": "https://example.net/manifest.plist", "InstallBehavior": { "Install": "Required" } } Is there any problem in our MDM configuration? Or the notification extension cannot integrate with ManagedApp FM?

I’m implementing passkey registration and authentication in an iOS 17 app with a credential provider extension, but I’m running into an issue. Setup: I have a credential provider target configured. The app correctly shows the pop-up to register the passkey with my app. My Info.plist is set up properly. Issue: When the following function is triggered: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { "code to generate registrationRequest..." let controller = ASAuthorizationController(authorizationRequests: [registrationRequest]) controller.delegate = self controller.presentationContextProvider = self controller.performRequests() } I get the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 I do not own the relying party domain (e.g., https://webauthn.io), so I cannot configure an apple-app-site-association file on the website. Question: How can I register and authenticate passkeys on any site that allows passkeys (such as webauthn.io) when I don’t control the webpage? Are there any workarounds or best practices for handling this in iOS 17? Any insights would be greatly appreciated!

I have filed bug reports on this to no avail, so I am bringing it up here hoping someone at Apple will address this. Since the first beta of 26.3, with voice control enabled there are now two icons in the menu bar (*plus an orange dot in full screen) that never go away. That orange microphone isn't serving its intended purpose to notify me that something is accessing my microphone if it is always displayed. I use voice control extensively, so it is nearly always on. In every prior version of macOS, the orange icon was not on for voice control. Even if voice control is not listening but simply enabled in system settings, the orange icon will be there. And there is no need for this icon to be on for a system service that is always listening. This orange icon in the menu bar at all times is incredibly irritating, as it takes up valuable space to the right of the notch, and causes other actual useful menu bar items to be hidden. As well, if some other application on my system were to turn on the mic and start recording me I would never know since that orange icon is always on. It also places an orange dot next to the control center icon taking up even more of the precious little menu bar real estate. Please fix this! Either exempt voice control (as Siri is always listening and it doesn't get the orange icon) or exempt all system services, or give me a way to turn this off. If you cannot tell, I find this incredibly annoying and frustrating.

I'm developing a passkey manager using ASCredentialProviderViewController. I've set a custom AAGUID in the attestation object during registration: let aaguid = Data([ 0xec, 0x78, 0xfa, 0xe8, 0xb2, 0xe0, 0x56, 0x97, 0x8e, 0x94, 0x7c, 0x77, 0x28, 0xc3, 0x95, 0x00 ]) However, when I test on webauthn.io, the relying party receives: AAGUID: 00000000-0000-0000-0000-000000000000 Provider Name: "iCloud Keychain" It appears that macOS overwrites the AAGUID to all zeros for third-party Credential Provider Extensions. This makes it impossible for relying parties to distinguish between different passkey providers, which is one of the key purposes of AAGUID in the WebAuthn specification. Is this expected behavior? Is there a way for third-party Credential Provider Extensions to use their own registered AAGUID? Environment: macOS 26.2 Xcode 26.2

In these threads, it was clarified that Credential Provider Extensions must set both Backup Eligible (BE) and Backup State (BS) flags to 1 in authenticator data: https://developer.apple.com/forums/thread/745605 https://developer.apple.com/forums/thread/787629 However, I'm developing a passkey manager that intentionally stores credentials only on the local device. My implementation uses: kSecAttrAccessibleWhenUnlockedThisDeviceOnly for keychain items kSecAttrTokenIDSecureEnclave for private keys No iCloud sync or backup These credentials are, by definition, single-device credentials. According to the WebAuthn specification, they should be represented with BE=0, BS=0. Currently, I'm forced to set BE=1, BS=1 to make the extension work, which misrepresents the actual backup status to relying parties. This is problematic because: Servers using BE/BS flags for security policies will incorrectly classify these as synced passkeys Users who specifically want device-bound credentials for higher security cannot get accurate flag representation Request: Please allow Credential Provider Extensions to return credentials with BE=0, BS=0 for legitimate device-bound passkey implementations. Environment: macOS 26.2 (25C56), Xcode 26.2 (17C52)

We are working on a PoC iOS App to use "Sign in with Apple" on iOS. The app needs to authenticate the current user on MDM managed corporate iPads (with Shared iPad enabled) and each user having a Managed Apple ID (created in Apple Business Manager). We have started with Apple's example app: https://developer.apple.com/documentation/authenticationservices/implementing-user-authentication-with-sign-in-with-apple When we run it on a normal iPad (without MDM supervision) it works fine. When we run the same code on a managed iPad with Shared iPad enabled and Managed Apple ID's the app errors out when a user taps the "Sign in with Apple" button. A User-facing error message is displayed: “Your Apple Account cannot be used to create accounts for other apps.” And when we run the app from Xcode we see the following logs: Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} 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=72, _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=72, _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=1000 "(null)" Could not authenticate: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) We have confirmed that in ABM "Sign in with Apple" feature is enabled with "Allowed apps": "All apps". We have also confirmed that the Managed AppleIDs created in ABM have no field to provide the birthday of the user and therefore ruling out age restrictions for "Sign in with Apple". Is "Sign in with Apple" supported in MDM managed iPADs with Shared iPad enabled and managed AppleIDs? If it is supported, do we know what other configurations we need to get it to work? Do we know why "Sign in with Apple" would error out with Authorization failed: Error Domain=AKAuthenticationError Code=-7027 "(null)" UserInfo={AKClientBundleID=com.sampleapp.test2} 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=72, Environment: • iPadOS version: IPadOS Version 18.7 • Xcode version: Version 26.0 (17A324) • Device type: iPad Air 11-inch (M3) in Shared iPad mode • Account type: Managed Apple ID created in ABM enrolled with Intune MDM) Thank you

Hi, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

We have a crash on DCDevice.current.isSupported We want to try to make a serial queue to generate tokens but the side effect would be the same token would be used on multiple server API requests that are made within a few ms of each other? Is this safe or will the Apple server immediately reject the same token being reused? Can you share how long tokens are safe to use for? Here is the code we want to try final actor DeviceTokenController: NSObject { static var shared: DeviceTokenController = .init() private var tokenGenerationTask: Task<Data?, Never>? var ephemeralDeviceToken: Data? { get async { // Re-using the token for short periods of time if let existingTask = tokenGenerationTask { return await existingTask.value } let task = Task<Data?, Never> { guard DCDevice.current.isSupported else { return nil } do { return try await DCDevice.current.generateToken() } catch { Log("Failed to generate ephemeral device token", error) return nil } } tokenGenerationTask = task let result = await task.value tokenGenerationTask = nil return result } } }

https://developer.apple.com/news/?id=j9zukcr6 starting from Jan 2026 there is change in requirements for account notifications for Sign in with Apple. Does this apply only to developers based in South Korea or all apps which are avai via the korean App Store?

After registe Passkey with webauthn library, i create a passkeyRegistration with follow, let passkeyRegistration = ASPasskeyRegistrationCredential(relyingParty: serviceIdentifier, clientDataHash: clientDataHashSign, credentialID: credentialId, attestationObject: attestationObject) and then completeRegistrationRequest like that, extensionContext.completeRegistrationRequest(using: passkeyRegistration) But a bad outcome occurred from user agent. NotAllowedError:The request is not allowed by the user agent or the platform in the current context. And the return data rawID & credentialPublicKey is empty,

On iOS 26, QuickLookAR (ARQuickLookPreviewItem) shares the actual .usdz file via the system Share Sheet instead of the original website URL. This is a regression from iOS 17–18, where sharing correctly preserved and sent only the source URL. Repro steps: 1. Open a web-hosted USDZ model in QuickLookAR (Safari). 2. Tap Share. 3. Share via any messenger. 4. The full .usdz file is sent. Expected: Share Sheet sends only the original URL. Actual: Share Sheet sends the USDZ file. Impact: Uncontrolled distribution of proprietary 3D assets. Critical IP / data leak. Blocks production AR deployments relying on QuickLook. Environment: iOS 26.0–26.1, iPhone 14 / 15. Works as expected on iOS 17–18. Test case: https://admixreality.com/ios26/

Hi, We are using the MSAL library to authenticate users, with SSO authentication implemented through the Microsoft Authenticator app. The problem is that once or twice a day, a prompt for forced authentication appears, indicating that silent token acquisition is failing and resulting in a requirement for forced authentication. Below are some of the logs: ================================================= 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] Silent flow finished. Result (null), error: -51115 error domain: MSIDErrorDomain 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] acquireTokenSilent returning with error: (MSALErrorDomain, -50002) Masked(not-null) ==================================================== We initially raised this issue with Microsoft, but according to them: In the app's logs, the single one failure it contains, was when the SSO extension returned the error com.apple.AuthenticationServices.AuthorizationError, -6000 during a silent call. This error code is generated by the system framework (Apple), not by our code. It indicates that the framework encountered an unexpected internal issue before or after calling the SSO extension. MSAL returning interaction_required to the client app is the most effective way to recover from this error (as you mention, after the user selects the account the app continues working as expected). Additionally, as you also mention, the interactive call is made by switching to Authenticator (not displaying a "window" without leaving Eva Lite app), which means MSAL is not able to use the SSO extension and is using the fallback to legacy authentication. The recommended next step is for the customer to request support directly from Apple as this is an issue on their side. Additionally, the customer can also try to update to the latest iOS, in case Apple has already fixed this issue. ============================================= STEPS TO REPRODUCE There is no such steps its just that this is an enterprise application which is getting used on managed devices[iPhone 14]. The device are managed using some intune policy. Platform and Version: iOS Development Environment: Xcode 15, macOS 13.6.1 Run-time Configuration: iOS 18 Please let me know if there are any solutions to resolve this problem. Thank you.

I've made my first app and encountered an unexpected (potentially existential) issue. The Manager app is designed to tag 3rd party "plugins" used by a DAW, storing metadata in a local SQLite database, and move them between Active and Inactive folders. This allows management of the plugin collection - the DAW only uses what's in the Active folder. Permissions are obtained via security-scoped bookmarks on first launch. The app functions as intended: plugin bundles move correctly and the database tracks everything. No information is written to the plugins themselves. The Problem:
When moving plugins using fs.rename() , the MAS sandbox automatically adds the com.apple.quarantine extended attribute to moved files. When the DAW subsequently rebuilds its plugin cache, it interprets quarantined plugins as "corrupt" or potentially malicious and refuses to load them. Technical Details: Moving files with NSFileManager or Node.js fs APIs within sandbox triggers quarantine Sandboxed apps cannot call xattr -d com.apple.quarantine or use removexattr() The entitlement com.apple.security.files.user-selected.read-write doesn't grant xattr removal rights User workaround: run xattr -cr /path/to/plugins in Terminal - not acceptable for professional users Question:
Is there any MAS-compliant way to move files without triggering quarantine, or to remove the quarantine attribute within the sandbox? The hardened-runtime DMG build works perfectly (no sandbox = no quarantine added). Any insight appreciated!