“DTiPhoneSimulatorErrorDomain Code 2”

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.

OK. So what you're describing isn't about the kernel. More specifically, this ONLY works: After forcing HiDPI 5K on Monitor 2 via BetterDisplay 4.3.3: Monitor 2 transitioned to: 5120x2880 @ 60Hz HiDPI (VRR 48-60Hz), HDR10 RGB Full Range, 13,700 Mbps allocation. So the dual 5K HiDPI configuration is only achievable when a third-party utility (BetterDisplay) overrides the default macOS mode selection on the secondary display. ...because the kernel's pipe configuration allowed enough bandwidth to support that configuration. What IS being caused by the kernel is that you're not able to take the second monitor to 120Hz. I believe that's a side effect of the display configuration the first monitor is presenting, notably: Maximum Source Width: 7680 The documented architectural difference (M5 Max showing four entries in MaxSrcRectWidthForPipe vs M5 Pro's two) suggests M5 Max may have additional sub-pipes available, Yes, it does. but the underlying kernel allocation logic you described would

Thank you for the post. The question is indeed dependent on the specific application being used and whether the machine is in sleep mode. If the machine is in sleep mode, it means that the Mac Catalyst or macOS application is not running, and consequently, the code will not execute. https://developer.apple.com/documentation/screencapturekit/scscreenshotmanager/captureimage(in:completionhandler:) So, there is no direct way to capture a screenshot of a window using ScreenCaptureKit (SCScreenshotManager) while the display is asleep. Albert
  Worldwide Developer Relations.

@kamilochel Thanks for the post, any chance you can create a new thread with those images, description and provide the full code of your view as I only see the children code .glassEffect only applies the shape mask and edge highlights to the glass material itself. The interactive highlight (the surface hover effect) calculates its own boundary based on the view's hit-testing shape, which often defaults to a capsule or standard rectangle if it encounters highly rounded corners without an explicit content shape. But I would appreciate if in a new thread you can provide the full code for SwiftUI engineers to help you with that effect. Thanks Albert
  Worldwide Developer Relations.