“DTiPhoneSimulatorErrorDomain Code 2”

Hi Ziqiao, thank you, both suggestions were worth testing. Unfortunately neither resolves it. Reporting back with results and fresh request IDs you can correlate server-side. Setup: container iCloud.com.luiz.PandaApp, PUBLIC database. Two CKQuerySubscriptions, options: [.firesOnRecordCreation], simple equality predicates (guardianRecordName == %@, requesterRecordName == %@). Visible NotificationInfo (your point #3). Set alertBody, shouldBadge = true, and category; did not set shouldSendContentAvailable. Subscription save still fails: CKError code 12; CKInternalErrorDomain 2006 BadSyntax; ServerErrorDescription: attempting to create a subscription in a production container. Server log: RequestUUID 9BD2E50A-60DF-4DDA-86EF-B91E27192F33 (Op 46EA29B4FF3AFC28), SubscriptionCreate / PUBLIC / USER_ERROR / BAD_REQUEST, ~65–82 ms (20 May 2026 ~15:07 UTC). 2) CKModifySubscriptionsOperation instead of CKDatabase.save(_:). Same failure: Server logs (21 May 2026 ~04:12 UTC): RequestUUID 3276D248-

Hello , Yes, we have been able to reproduce this issue in our office as well, but only 2 times so far on macOS 26.4.1. It appears to be an intermittent issue, and we are not able to reproduce it consistently or quickly. Based on our investigation, this seems to occur in scenarios involving audio playback. We also made changes to ensure sound playback happens on the main thread and shared that build with the customer. However, the customer is still encountering the crash on their end. We are attaching the customer crash log for reference. Please let us know if there are any specific areas in the crash log that we should focus on or if additional diagnostics would help. crash.crash

Thank you for the clarification — but with respect, this answer raises a much bigger problem than it solves. If internal only builds cannot be attached to app versions, why are they shown as selectable options in the build picker in the first place? Your own UI presented build 2 as a valid candidate, let us select it, and then failed silently with a generic 409 error in the network layer. No inline error message. No badge or label on the build indicating it was ineligible. No tooltip. Nothing in the visible UI explaining why the attach was failing. We — and apparently other developers, given that you said thank you all for the reports — spent hours debugging this. We checked export compliance, re-verified processing status, hard-refreshed, cleared caches, re-archived builds, opened DevTools to inspect network traffic, and combed through documentation. All of that time and effort was wasted because App Store Connect surfaced an ineligible build as if it were eligible and then refused to attach it with

Thanks for the careful report and for setting out the four questions clearly — the structure helps. NSURLErrorNetworkConnectionLost (-1005) surfacing through webView:didFailProvisionalNavigation:withError: is a generic outcome that can come from several distinct underlying conditions — TCP-level disconnects, HTTP/2 stream resets (RST_STREAM), idle-connection close races during connection reuse, transient network-path changes, or server-side behavior. Without captured diagnostics from a failure as it happens, there isn't a way to map your reports to a specific cause, and there isn't a known iOS 26.4.x regression we'd identify as a likely match. The most productive next step is to capture per-request diagnostics during a failure and file a Feedback Assistant report: ❏ Web Inspector network waterfall. Three things need to be enabled before this works: iPhone: Settings → Apps → Safari → Advanced → Web Inspector toggle on. Mac: Safari → Settings → Advanced → Show features for web developers enabled. In yo

When an app is transferred between developer accounts, the DeviceCheck state (the two bits and timestamp associated with a device) persists across the transfer. This means that the data previously stored for a device using DeviceCheck will remain accessible and associated with that device, even after the app's ownership changes (assuming the new owner is not changing the Bundle ID). This persistence is designed to help mitigate fraud, as the state is maintained by Apple and survives app reinstallation, device transfer between users, and even device erasure. However, the authentication for communicating with the DeviceCheck service relies on a private key and an iss (issuer) value from your developer account. When an app is transferred to a new developer account, it becomes associated with the recipient's Team ID. Therefore, to continue authenticating requests to the DeviceCheck service for the transferred app, the backend must be updated to use a new DeviceCheck private key generated under the recipi

Yes, the guidance still holds true. Apart from a trivial but non-zero time period around the moment of transfer being completed (due to network propagation and database update times), once the transfer is complete, the credentials of the old team will no longer work, and the new team with their new credentials will need to take over. The only exception is if the old team has already open connections to APNs having used their old credentials, those connections will continue functioning until the connections are closed. For users who already have the app installed and previously opted into push notifications before the transfer: The transfer hands over push server infrastructure authentication from one team to the other. The app itself is not affected at all unless the new team is changing the Bundle ID. Will existing APNs device tokens remain valid after the app transfer? Device tokens will not change as long as the App Bundle ID is the same, and the migration to the new app does not involve deleting the old a

1. Both the P12 and the P8 based JWTs will remain valid: For a trivial but non-zero time after the transfer is complete. if the old team has already open connections to APNs at the time the transfer is completed, they will be able to continue sending notifications until the close the connections and try to reopen them, in which case their authentication will fail 2. Whether the original team shuts down APNs and JWT services or not, will the old P12 certificates and P8 keys become invalid right away, leaving users unable to receive pushes until the new company updates the relevant credentials? Th old certificates will become invalid almost right away, after a trivial but non-zero time has passed. Once the connections are closed the old certificates will no longer work, and the new team has to start using their own credentials.