General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Why are we doing this nonsense? We want to be able to run builds in a sandbox such that they can only see the paths they are intended to depend on, to improve reproducibility. With builds with a very large number of dependencies, there's a very large number of paths added to the sandbox, and it breaks things inside libsandbox. Either it hits some sandbox length limit (sandbox-exec: pattern serialization length 66460 exceeds maximum (65535), Nix issue #4119, worked around: Nix PR 12570), or it hits an assert (this report; also Nix issue #2311). The other options for sandboxing on macOS are not viable; we acknowledge sandbox-exec and sandbox_init_with_parameters are deprecated; App Sandbox is inapplicable because we aren't an app. Our use case is closer to a browser, and all the browsers use libsandbox internally. We could possibly use SystemExtension or a particularly diabolical use of Virtualization.framework, but the former API requires notarization which is close to a no-go for our use case as open source software: it is nearly impossible to develop the software on one's own computer, and it would require us to ship a binary blob (and have the build processes to produce one in infrastructure completely dissimilar to what we use today); it also requires a bunch of engineering time. Today, we can pretend that code signing/notarization doesn't exist and that we are writing an old-school Unix daemon, because we are one. The latter is absolutely diabolical and hard to implement. See this saga about the bug we are facing: Nix issue #4119, Nix issue #2311, etc. What is going wrong I can't attach the file fail.sb as it is too large (you can view the failing test case at Lix's gerrit, CL 2870) and run this: $ sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Assertion failed: (diff <= INSTR_JUMP_NE_MAX_LENGTH), function push_jne_instr, file serialize.c, line 240. zsh: abort sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Or a stacktrace: stacktrace.txt Credits Full credits to Jade Lovelace (Lix) for writing the above text and filing a bug. This is submitted under FB16964888

On macOS 26.6.2 (build 25G83), arm64, I am using the Security framework through JXA, executed by a static /usr/bin/osascript helper launched from the Codex desktop application's local command environment. A dummy-only test attempts to add one generic-password item to the local file-based login keychain. SecItemAdd returns OSStatus 100001. The system's "security error 100001" command describes this as "UNIX[Operation not permitted]". The helper explicitly opens the login keychain and selects it using kSecUseKeychain for the add operation. Synchronizable and Data Protection Keychain options are false. It supplies an access object created by SecAccessCreate with an empty trusted-application array. What I have confirmed: Keychain open/status calls succeed and report unlocked, readable, and writable. I understand these flags do not establish permission for this individual operation. Attribute-only exact lookups report the dummy item as not found before and after each failed add. Granting narrowly scoped filesystem write permission for the login keychain file through the launching tool did not resolve the failure. I have not performed a comparison outside that restricted execution environment. I have not established whether the cause is the environment, API/ACL configuration, or an OS issue. Is this JXA/Security usage supported for a file-based keychain? Which documented diagnostics can distinguish process/sandbox restrictions from item ACL or authentication requirements? Are there relevant constraints on this query/access-object construction? I am seeking a supported implementation, not a way to disable or bypass security protections. I can provide a dummy-only reproducer without credentials or personal paths.

I’m seeking DTS guidance on supported ScreenCaptureKit usage and diagnostics for an intermittent authorization failure, filed as FB24757092. Captured evidence (my incident) On macOS 26.6.2 (25G83), Apple silicon, an already-authorized custom Apple Development-signed AltTabDebug build encountered renewed Screen Recording prompts. Unified logs show root tccd exhausting file descriptors during authorization. Three failing tccd processes each reported 255 total descriptors, with 250 unique descriptors referring to the same app executable. SecStaticCodeCreateWithPath failed with error 100024 (UNIX[Too many open files]); tccd could not match the existing kTCCServiceScreenCapture code requirement, and replayd reported TCC Disallow / user denied for captureScreenshot. Later checks allowed the same running app again. This confirms resource exhaustion and authorization failures. It does not establish why descriptors accumulated, a persistent leak mechanism, a per-capture leak rate, or a deterministic reproducer. The reported load spike and roughly one-second display freeze have an uncertain causal relationship to these failures. I have not established reproduction on macOS 27 or descriptor exhaustion in an unmodified release build. No incident-time sysdiagnose was collected. Separate upstream observations The AltTab maintainer reported testing the signed release in /Applications on the same OS build: 446 screenshots produced 1,350 ScreenCapture authorization requests, with repeated code-signature validation; approximately 23 ms of root-tccd CPU per thumbnail was reported. These are the maintainer’s measurements, not independently repeated by me, and do not measure descriptor growth per capture. https://github.com/lwouis/alt-tab-macos/issues/6025 https://github.com/lwouis/alt-tab-macos/issues/6025#issuecomment-5640382131 Questions Is there a supported ScreenCaptureKit capture pattern, request concurrency/rate guidance, or recovery strategy to reduce repeated authorization work and avoid renewed prompts when code validation fails from transient resource exhaustion? How should an app distinguish a genuine permission denial from an unavailable/failed authorization service, without repeatedly requesting permission? Which logging profile, trace, or incident-time diagnostics should we collect to correlate capture submissions/completions with tccd descriptor lifetime and isolate the accumulation mechanism? FB24757092 contains the focused timeline, descriptor dumps, prompt screenshot, and separately attributed maintainer findings. Raw diagnostics and private system/account information are intentionally omitted here. I built a standalone Swift/AppKit probe that uses one retained SCContentFilter per batch, logs submissions and actual callbacks, bounds outstanding requests, stops new submissions on the first error, and discards images. On macOS 27.0 (26A428), its ad-hoc-signed build captured its own window successfully in 446-request captureScreenshot batches at concurrency 1 and 4. This validates the harness, not reproduction of the original failure. The code-level form requests a focused project demonstrating the issue; this probe does not yet reproduce exhaustion. Could DTS advise the next isolation step and whether a private support case is appropriate for the existing evidence?

We recently completed an app transfer between two Apple Developer Program teams. Before releasing the first post-transfer version, we need to verify the update behavior from several specific historical versions signed by the previous team. Our main question is not limited to TestFlight: we would like to know Apple's recommended and supported method for reproducing this update path. Could you clarify the following? What is Apple's recommended and supported method for testing an update from a specific pre-transfer version to the first post-transfer release? Can an archived Ad Hoc IPA signed by the previous team be used as the starting version for this test? Can that IPA be updated by a post-transfer TestFlight, Development, or Ad Hoc build signed by the recipient team? Which of these methods most accurately reproduces an App Store update after an app transfer? For a manual Development or Ad Hoc update, is the previous-application-identifiers entitlement required? If it is required, how should the recipient team request a provisioning profile that authorizes this entitlement? Thank you.

I'm using the code below. It functions correctly on iOS 27.2 Beta 1 but crashes on iOS 27.2 Beta 2. API implemented here Xcode version - Version 27.2 beta (27B5019j) iOS Version - iOS 27.2 Beta 1 and Beta 2 behavior App Store region - Germany if (@available(iOS 27.2, *)) { [ATTrackingManager requestTrackingAuthorizationUsingExpandedInterface:YES additionalInformationAction:^{ NSLog(@"[ATT] Additional Information Clicked"); } completionHandler:^(ATTrackingManagerAuthorizationStatus status) { NSLog(@"[ATT] completion status: %ld", (long)status); }]; Resulted in a crash at runtime. No error at compile time. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[ATTrackingManager requestTrackingAuthorizationUsingExpandedInterface:additionalInformationAction:completionHandler:]: unrecognized selector sent to class 0x28f3d0f80' *** First throw call stack: (0x1998ee8e0 0x19966c380 0x1999ee444 0x1998aa774 0x1998aaa30 0x1020a3a60 0x102fc8558 0x102fe1df0 0x103003dd8 0x102fd8340 0x102fd8280 0x1998a0614 0x19989187c 0x1998927e4 0x24643df24 0x19da6db54 0x1020a5264 0x1996e35b8) libc++abi: terminating due to uncaught exception of type NSException *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[ATTrackingManager requestTrackingAuthorizationUsingExpandedInterface:additionalInformationAction:completionHandler:]: unrecognized selector sent to class 0x28f3d0f80' *** First throw call stack: (0x1998ee8e0 0x19966c380 0x1999ee444 0x1998aa774 0x1998aaa30 0x1020a3a60 0x102fc8558 0x102fe1df0 0x103003dd8 0x102fd8340 0x102fd8280 0x1998a0614 0x19989187c 0x1998927e4 0x24643df24 0x19da6db54 0x1020a5264 0x1996e35b8) terminating due to uncaught exception of type NSException

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

Hello, I was planning to transfer an app to a different Apple Developer account and had a question regarding DeviceCheck behavior after the transfer. Currently, the app uses the DeviceCheck service with a DeviceCheck key associated with the transferring account. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. Could you clarify the following: Will DeviceCheck validations continue to function after the app transfer using the existing DeviceCheck key and "iss" value associated with the transferor account? Or will DeviceCheck requests begin failing until a new DeviceCheck key is generated under the recipient account and our backend is updated to use the new "iss" value? Any guidance on the expected transition behavior would be greatly appreciated. Thank you.

Problem On iOS 27.0 beta (build 24A5430a) ATTrackingManager.requestTrackingAuthorization() completes with the status still .notDetermined and no prompt is ever presented. The ATT system prompt does not appear in any app on the Store. Environment iOS 27.0 beta 8 iPad and iPhone, both affected Country IT Question: Is this expected behavior, or is it a change in the new version of iOS? If it is a change, could you please point me to a reference that documents this? Happy to provide anything further through the Feedback report rather than here.

Title: Does identifierForVendor (IDFV) change after transferring an app to another Apple Developer account? We are planning to transfer an existing App Store app from one Apple Developer account/team to another using App Transfer. The app currently uses: UIDevice.current.identifierForVendor as one of the identifiers sent to our backend. We would like to confirm the exact behavior of identifierForVendor after the app is transferred to the recipient developer account. Our scenario is: The app is currently published under Developer Team A. Existing users already have the app installed on their devices. We transfer the app to Developer Team B through App Store Connect. Developer Team B creates new certificates/provisioning profiles and publishes a new version of the same app. Existing users update the app normally from the App Store, without uninstalling it. Questions: After an existing user updates from the last version published by Team A to the first version published by Team B, will UIDevice.current.identifierForVendor remain the same, or will it be regenerated? Is the vendor used to calculate IDFV associated with: the App Store app record, the Bundle ID, the Team ID, the App ID Prefix, the developer organization/vendor, or some other value? Does App Transfer itself cause IDFV to change, or does the value only change under specific conditions such as changing the organization name or uninstalling all apps from the same vendor? If IDFV changes after App Transfer, does Apple provide any official migration or mapping mechanism that allows the backend to associate the old IDFV with the new IDFV? For example, Sign in with Apple provides a user migration mechanism when transferring an app between developer teams. Is there any equivalent mechanism for identifierForVendor? Is there any difference between: users who update the app directly after the transfer, and users who uninstall the old version and reinstall the app after the transfer? We have reviewed the documentation for identifierForVendor and App Transfer, but we could not find an explicit statement describing the IDFV behavior specifically for an App Transfer between two different developer teams. Our main concern is maintaining backend device associations for existing users after the transfer. We would appreciate an official clarification on whether IDFV continuity is guaranteed across App Transfer, and if not, what migration strategy Apple recommends.

I have a follow-up question about file-based Keychain ACLs, this time specifically about inspecting the authorization state after it has been configured. I’ve been looking through the public SecAccess / SecACL / SecTrustedApplication APIs. I can enumerate ACL entries and their authorizations, and SecACLCopyContents gives me the trusted applications associated with an ACL. What I haven’t been able to establish is whether the complete stored caller-matching condition can be read back through a supported API. In particular, SecTrustedApplicationCopyData returns opaque application-identifying data. Is that data intended to be a complete representation of the condition that the Keychain will use to recognize that trusted application? Or can the stored trusted-application condition contain additional code-signing requirements or other matching constraints that are not represented by SecTrustedApplicationCopyData? My higher-level requirement is to verify, after configuring a private key, that its effective authorization scope is no broader than an independently reviewed policy. Ideally I would like to compare: the authorized private-key operations; all trusted-application subjects and their complete matching conditions; prompt-related state; and partition-list constraints. Is there a public and supported API, or an Apple-provided tool with a supported machine-readable contract, that can enumerate the complete effective authorization state of a private key in a file-based Keychain? I’m deliberately not trying to infer this from the current executable’s path, designated requirement, hash, security dump-keychain output, or representative negative tests unless Apple considers one of those to be the supported way to establish the stored authorization state. I realise from the existing guidance, including TN3137 and the discussion around file-based Keychains, that this is legacy technology. If complete supported introspection simply isn’t available for this model, knowing that limitation would also answer my question. Thanks.

I am trying to get my first app approved and keep getting denied. In my app, I allow for Sign in With Apple. This allows the user to use Hide my Email to give a temp/private email. That is fine and I accept it. One of the major features of my app requires that parent's confirm their real address in order to see information and communicate about their children. It's a sports/coaching app. Coaches create their roster and associate parents with players via email address. Those parents then login and see their list of players (children) and can chat with the team, get schedules, etc. Without the real email, I have no way to validate that parent should have access to that player's details. It has to be secure. And a parent won't know their Hide my Email address ahead of time in order to provide it to the coach. Apple keeps denying my app saying that I cannot ask for their real email. I have explained it and the reviewer never addresses my explanation. Just denies it with the same reason. What can I do?

What supported public API and verification contract should a sandboxed macOS file manager use to preserve a copied file's quarantine/provenance metadata? We observe different results in App Sandbox versus Finder and an otherwise-matched non-sandbox diagnostic. We want to keep App Sandbox and all security protections enabled, not remove quarantine or invent undocumented flag masks. Environment: macOS 26.6.2 (25G83), Apple Silicon, local APFS. Optimized Foundation-only diagnostic, Apple Development signing, Hardened Runtime, launched directly as an executable. The sandbox variant has app-sandbox, user-selected read/write and app-scope bookmark entitlements. This is not a notarized distribution-build comparison. Reproduction: Use an existing regular JPEG with naturally present com.apple.quarantine metadata identifying Chrome, raw flags 0283 and a nonempty event field. Keep the original read-only. Record SHA-256, length, full raw extended attributes and fresh NSURL quarantinePropertiesKey observations. Keep access to a user-granted local test directory active. Copy to a new, absent destination in a fresh directory using each of these three arms: fclonefileat with CLONE_ACL | CLONE_NOFOLLOW_ANY | CLONE_RESOLVE_BENEATH (28). copyfile with COPYFILE_CLONE | COPYFILE_ACL; record COPYFILE_STATE_WAS_CLONED. FileManager.copyItem(at:to:). Observe source and destination without setting, removing or repairing metadata. Each arm waits at least 1.1 seconds before copying; the source quarantine timestamp is much older than call time. Repeat with fresh destinations. Also copy the same source through actual Finder Copy/Paste twice. Compare two signed variants made from the same compiled payload, with identical executable name, bundle ID, Development identity and Hardened Runtime. The only signed entitlement difference is app-sandbox=true versus its omission. The sandbox variant resolves the existing exact folder grant; the non-sandbox diagnostic uses that same fixed test directory directly. Results: Sandbox diagnostic: all six calls succeed and data hashes/lengths match. All six outputs change raw flags 0283 to 0082, agent Chrome to the diagnostic app, event field nonempty to empty, and timestamp. Public output lacks the source event identifier and adds LSQuarantineTypeSandboxed. Matched non-sandbox diagnostic: all six copies preserve the full observed raw quarantine record and public quarantine dictionary. copyfile reports WAS_CLONED=true in both contexts. Finder: both copies preserve the full observed raw quarantine record and public dictionary. Source bytes and declared preserved metadata remain unchanged. Other compared raw attributes, mode, flags, birth/modification times, owner/group and ACL match in these cases. We also reproduced timestamp-only differences with files naturally quarantined by the diagnostic itself. The foreign-agent control above shows that the difference is not limited to timestamp. The chosen source exposes no public origin/data URL, so their preservation is untested. We have not traced the responsible internal component, tested Gatekeeper effects, or established whether the transformation is security-equivalent. We do not claim the three APIs use independent implementations or that all possible public API combinations have been tested. Could you clarify: Is this transformation expected for copying from an App Sandbox process, or should we file it as a bug? What documented preservation behavior should a sandboxed file manager rely on? Is there a supported API or operation that preserves the source's quarantine/provenance metadata in this context without disabling App Sandbox or weakening security protections? If exact raw equality is intentionally not guaranteed, which supported public properties or behaviors should verification check? Is a quarantine-properties dictionary round-trip supported, and what information does it preserve or omit? We have not attempted a metadata repair. Separately, a pathname-based repair after cloning would require its own destination-identity/race safety review because the clone call does not return a creation-bound destination descriptor. We are asking for supported API semantics, not private implementation details or a security bypass. We can prepare a minimal sanitized standalone reproducer if needed. No user files, sandbox grants, private logs or diagnostic binaries are attached to this initial question.

I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.

On macOS 27, App Attest attestations include a key access control property (the aclBlob, OID 1.2.840.113635.100.8.6) that Apple says reflects SIP and Full Security mode being enabled. Is this just a wrapper around the CSR check (csr_check / what csrutil status reads) at attestation time, or is the SIP state actually enforced by the Secure Enclave and bound to the attested key?

Running 'tccutil reset microphone' gives the error message 'tccutil: Failed to reset microphone'. The same command worked in the past. Deleting the TCC.db files didn't help. In the console there is an error from the tccd daemon saying handle_TCCAccessResetInternal: Invalid Service Name: kTCCServicemicrophone(Service name is invalid on this platform) Any ideas?

Anyone else notice that Autofill is providing passwords and credit cards without requiring any type of security. On my MacBook Air, it requires Touch ID or password. On my Mac mini it does not require anything. That seems like a major security hole?

We are implementing a one-free-trial-per-device rule for an iOS app. Our server uses App Attest to validate the app instance and DeviceCheck’s per-device bits to record that the device has received its trial. We grant the trial only after the server can confirm that the DeviceCheck bit was successfully stored. The unresolved case is when our server sends an update request to Apple, but the connection times out or closes before receiving a response. Apple may have accepted the write even though our server does not know the outcome. What is Apple’s recommended recovery procedure for this situation? Specifically: After an uncertain update response, can the server query the device’s bits to authoritatively determine whether the update succeeded? Does DeviceCheck provide read-after-write consistency for this query? If the queried bit is still unset, is it safe and supported to retry the update using the same desired bit values? Are repeated updates that set the bits to their existing values idempotent? Which response, if any, should be treated as confirmation that the write is durable before granting the trial? Our current design fails closed: it does not grant the trial when the write outcome is uncertain. We want to avoid both granting multiple trials and permanently denying an eligible user because of a transient network failure.

I'm building an iOS app (bundle identifier ca.fanforge.pos, Team ID 856C6JT832) that uses a third-party payment SDK to connect to a physical Bluetooth card reader. The SDK requires my app to successfully complete Apple's App Attest process against the production environment before it will allow a real card reader to connect. I have set the entitlement com.apple.developer.devicecheck.appattest-environment to production in my app's entitlements, and I have enabled the App Attest capability on my App ID in the Apple Developer portal. I confirmed directly, by extracting the compiled app binary and running codesign -d --entitlements :- MyApp on it, that the entitlement is present with the value production in the actual signed binary, not just in my source configuration. When I distribute this exact build as an ad-hoc build (a registered test device added to my provisioning profile, not through TestFlight or the App Store), the card reader fails to connect with an error indicating it cannot establish a secure connection to the payment provider's servers. When I distribute the identical app (same version, same entitlements, same provisioning) through TestFlight instead, the card reader connects successfully and I am able to process a real payment. Steps I have already taken to rule out other causes: Verified the payment provider's account credentials are valid and correctly configured for production (confirmed via a direct API call returning a successful response) Verified the App Attest capability is enabled on my App ID in the Apple Developer portal Verified the entitlement value directly in the compiled binary's code signature (not just my source files) Registered the required application signature with the payment provider Fully removed and reinstalled the app between tests Confirmed the reader hardware itself works correctly (it connects successfully in the TestFlight-distributed build) My question: Does ad-hoc distribution have different behavior than documented for the com.apple.developer.devicecheck.appattest-environment entitlement? Apple's documentation states that after distribution through TestFlight, the App Store, or the Apple Developer Enterprise Program, an app automatically uses the production App Attest environment regardless of the entitlement value. It also states that for other distribution methods, the entitlement value itself should directly control which environment is used. My ad-hoc build has the entitlement explicitly set to production, yet its behavior matches what I would expect from the sandbox environment, not production. Expected outcome: I would like to understand whether ad-hoc distribution is expected to correctly honor an explicit production entitlement value for App Attest, or whether there is a known limitation or additional requirement for ad-hoc distribution specifically that isn't covered in the entitlement's documentation.

⚠ It'd be great to get some Apple Dev eyes on this -- it's one of my last remaining issues before submission. Regarding migrating Sign In with Apple users from team PLR8R96VKA to team Y76F338229... I'm following the migration steps at the bottom of https://developer.apple.com/documentation/signinwithapple, in the Transfers Across Teams section. My call to the /auth/usermigrationinfo endpoint results in a 400 error: invalid_request, but my request params all look correct: transfer_sub is set to the the value I got from a successful /auth/usermigrationinfo response. client_id is set to Services ID of the new team's Sign In with Apple service. client_secret was built from the new team's Key ID, Team ID and Services ID. I know it's content and format is valid because it worked fine when calling the /auth/token endpoint. I know my auth token is fine (the one I got from /auth/token)--I'm sure I'd see an auth error if it wasn't. Is there any way I can get more information about what is invalid about the request?

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.