Hello, I'm hitting a persistent CKQuerySubscription save failure on the public database in my Production CloudKit container. I want to flag this is NOT the iOS 26.4 silent-push regression resolved in 26.4.1 (I've confirmed it manifests differently and on devices that predate that bug). App: Win 10 Min (com.luiz.PandaApp) Container: iCloud.com.luiz.PandaApp Current shipping version: 3.2.1 build 420 (approved 2026-05-19) Public database THE ERROR (captured from CKError.userInfo) CKErrorCode 12 (badRequest) CKInternalErrorDomain code 2006 ("BadSyntax") ServerErrorDescription: "attempting to create a subscription in a production container" Execution time per failed attempt: 45-90ms (gateway-level rejection, not data validation). CODE let subscription = CKQuerySubscription( recordType: "GuardianRequest", predicate: NSPredicate(format: "guardianRecordName == %@", me), subscriptionID: "guardian-incoming-(me)", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true subscription.notificationInfo = info try await container.publicCloudDatabase.save(subscription) The .save() throws every time. REPRODUCES ACROSS iPhone on iOS 26.4.2 (i.e., has the 26.4.1 CloudKit regression fix) iPhone on iOS 18.6.x (predates the 26.4 regression entirely) Multiple distinct Apple IDs / userId hashes Fresh installs via TestFlight Updated installs from production CONSISTENTLY: USER_ERROR / BAD_REQUEST. Same error every time. WHY THIS ISN'T THE iOS 26.4 REGRESSION (Thread 820562) That regression caused silent notifications to be DROPPED client-side AFTER successful subscription creation. Our failure is SubscriptionCreate itself being rejected by the CloudKit server before any subscription exists. Different layer, different symptom. iOS 18.6.x devices also fail (they never had the 26.4 token-validation regression code). CLOUDKIT CONSOLE LOGS (sample request UUIDs Apple engineers can lookup) EB30E9D0-8C97-4685-BD16-3E79B3328D6F (2026-05-17 8:08 UTC) EEAA0606-5B50-4640-A950-EEA33B790B8E (2026-05-17, captured in-app) EB4C90CE-9172-4942-B00F-DE4A28388FBA (2026-05-19 7:18 UTC, iOS 18.6.x) F2DF69D9-2339-437A-B59B-7FBD4D57442F (2026-05-19 7:51 UTC, iOS 26.4.x) CloudKit Console → Production → Subscriptions: 0 entries despite 70+ attempts since 2026-05-11. WHAT I'VE VERIFIED / TRIED Schema: GuardianRequest.guardianRecordName and GuardianResponse.requesterRecordName both have QUERYABLE indexes in the Production schema (confirmed in Console). Field types: all STRING. aps-environment entitlement: "production" (changed from "development" in build 420; no change in error pattern). Push Notifications capability: enabled on App ID in Developer Portal AND in Xcode Signing & Capabilities for the main app target. UIBackgroundModes: includes "remote-notification". Re-deployed Production schema from Development on 2026-05-19 (Console reported "no changes"; failure pattern unchanged). Tried with and without info.desiredKeys = []. RecordQuery operations on the same fields and record types in the same container succeed consistently. QUESTIONS Is there a known infrastructure issue affecting public database CKQuerySubscription creation that is distinct from the iOS 26.4 regression (thread 820562)? Is there a per-container configuration that may be in an unexpected state, and if so what should I check? Are there workarounds beyond schema redeployment that have helped other developers in similar situations? Thanks for any guidance.

We're experiencing the same CLMonitor.init crash described in thread 771001, but our initialization timing is different from the original poster's - we do NOT initialize at library load time or during didFinishLaunchingWithOptions. Our CLMonitor is created lazily as a singleton on first access, after UIApplicationMain() has completed. Our setup: iOS 17+ deployment target, Swift 6, strict concurrency CLMonitor is created as a singleton, lazily, on first access — triggered by either a location update (recentering the geofence via setFence) or the geofence event loop starting when the app enters background (didEnterBackground -> startGeofenceMonitoring) We use one CLMonitor.CircularGeographicCondition for geofencing (exit detection only) The CLMonitor singleton is @MainActor-isolated What we've tried: Pinned the Task that creates CLMonitor to @MainActor (Task { @MainActor in await CLMonitor("GeofenceMonitor") }). This didn't help - the crash still occurs because CLMonitor.init itself executes on the cooperative thread pool regardless of the calling task's actor isolation. Our current code: extension CLMonitor { @MainActor static var geofenceMonitor: CLMonitor { get async { @MainActor struct Static { static var task: Task<CLMonitor, Never>? } if let task = Static.task { return await task.value } let task = Task { @MainActor in await CLMonitor("GeofenceMonitor") } Static.task = task return await task.value } } } Questions: Since the crash is entirely inside CLMonitor.init's internal synchronous dispatch to the CoreLocation shared queue, and there doesn't appear to be a Swift-level way to control which thread the ObjC-bridged initializer executes on - is there a recommended workaround? Would migrating to the deprecated CLLocationManager.startMonitoring(for: CLCircularRegion) API avoid this crash path entirely? Our use case is simple (one circular geofence, exit-only detection) and we'd prefer a stable solution while this issue is being investigated. Is this a known framework issue being tracked internally? Should we file a Feedback for it? 2026-05-01_02-03-18.8762_-0500-6a1f312b81e187d820d5a2e60ab9368178a6c1e8.crash

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

My auto-renewable subscription products are approved in App Store Connect, but fetchProducts() returns 0 products when testing in Production & Testflight. Debug output shows: "products.size is 0 - no products fetched! Expected 6 products." All my business agreements are active. Has anyone faced this before? What do you recommend? Thank you.

Hi everyone, Just recently we started having issues in our integration environment with publicly available well known files not being fetched properly by the Apple CDN. The CDN keeps returning an SWCERR00301 Timeout fault. I noticed a very similar thread around the same time it went wrong with us as well: https://developer.apple.com/forums/thread/821908 However, the fault is ever so slightly different. Note that for security reasons, the actual domain has been redacted and replaced by the generic "domain.com" When calling the command curl -i https://app-site-association.cdn-apple.com/a/v1/domain.com The following is returned HTTP/1.1 404 Not Found Server: AppleHttpServer/2caa77a6bc2e755fca0e0f63e4d67e53390f9184 Date: Thu, 21 May 2026 10:44:08 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://domain.com/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: eb38e1901a83ad9b Strict-Transport-Security: max-age=31536000 Expires: Thu, 21 May 2026 10:44:18 GMT Age: 712 Via: http/1.1 defra2-vp-vst-004.ts.apple.com (acdn/302.16436), https/1.1 defra2-vp-vfe-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-lx-007.ts.apple.com (acdn/302.16436), https/1.1 nlams2-edge-bx-021.ts.apple.com (acdn/302.16436) X-Cache: hit-fresh, hit-stale, hit-stale, hit-stale CDNUUID: 859e620c-7e2c-438c-a43d-68b6344e890c-1593129103 Connection: keep-alive Not Found Where other issues on the forum specifically target "waiting on headers", it does not in our case. We checked our internal infrastructure, we clearly see incoming requests from the ASAA-bot requesting the well known file. These requests hit our backends as they should and return a 200 OK. All within a couple of milliseconds. Again - nothing changed here. After this validation, I read the Tech notes: TN3155: Debugging universal links | Apple Developer Documentation but it does not provide anything we did not already check. Besides on our side, hosting wise and content-wise, nothing changed. This is not new material. I ultimately enabled developer mode on my test device, pushed the Integration app version causing the issues. When keeping the entitlements asis, the apple CDN is called from the iOS device (verified through ProxyMan) but the redirects do not work (as the CDN contains 404 Not Found) When changing the entitlements, and adding "?mode=developer", the CDN is of course skipped and our backend is called directly (as verified through ProxyMan). Now the redirects work as intended, the universal links were fetched properly. (the embedded universal link tester on the iOS device in settings - Developer still did not validate the universal link correctly though. But this seems an issue in the tool. The working production universal link also does not validate while it definitely works) To make sure our backend is not too 'slow' (internal logging shows requests are handled within 100 ms), I checked against UAT. Same processing times, there no issues with CDN. We conducted a very thorough investigation on our side and I do not see any reason as to why the CDN should be throwing timeout exceptions. As we cannot flush the CDN cache and do not see issues on our side, there is no way for us to validate why this is going wrong. Does anyone have any clues on what else I can do? Thanks

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding Apple App Site Association (AASA) and Universal Links behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. We currently support Universal Links through our Apple App Site Association (AASA) configuration. Could you clarify the following: After the app transfer, will existing Universal Links continue functioning for users who already have the app installed? Will we need to update our AASA file to include the recipient account’s new Team ID in order for Universal Links to continue functioning properly? If so, is there a recommended transition strategy for supporting both existing installed app instances and newly installed versions during the migration period? Any clarification on the expected Universal Links and AASA transition behavior during and after an app transfer would be greatly appreciated. Thank you.

Hello, I'm an iOS developer currently working on an application in Xcode. I submitted a Capability Request for Family Controls (Distribution) through App Store Connect, but the status has remained "Submitted" with no approval to date. My oldest request was filed on April 21, 2026, so it has now been almost a month. Approval of this request is essential for releasing my application, and the length of this review process has become a significant source of stress. Based on what I've seen from other developers, most requests are approved within four weeks at the latest. I would like to know when I can expect a decision on my requests. The Request IDs in question are the following five: AS9LZVLSRX, 2UB9RY7AJF, LJ5TWZ6HH3, DGA3UBV6W9, ANZD3T8X23 Please note that some of these are duplicate submissions for the same identifier, so I'd appreciate it if you could check and consolidate them as needed. Thank you in advance for looking into this. Best regards, Tomo

We are using Live Activities in our iOS app to show real-time flight information on the Lock Screen and Dynamic Island. Our implementation currently works as follows: The Live Activity is created using the push-to-start token. After the Live Activity is started, our backend receives and uses the Live Activity update token to send updates to the Live Activity through APNs. The Live Activity content is updated through push notifications from our backend. These updates include flight status changes such as check-in status, boarding status, gate changes, delay updates, arrival status, and other journey-related states. We are observing an issue where some Live Activity state updates are not reflected on the device. From our backend logs, the APNs request is successfully sent, but in some cases the update does not appear to be received by the device, and the Live Activity remains in an older state. We understand from Apple documentation and platform behavior that Live Activity push updates may be subject to system-level throttling or delivery limitations. We would like to confirm the expected behavior and understand the recommended approach. Could you please help clarify the following? Are Live Activity update pushes subject to throttling by iOS/APNs even when the backend sends the update successfully? If APNs accepts the request successfully, is there still a possibility that the update may not be delivered to the device or may not update the Live Activity because of system-level throttling, device state, power conditions, network conditions, or Live Activity limits?

Hi everyone, I submitted my Family Controls (Distribution) entitlement request on April 19 and it's been stuck on "Submitted" for over 4 weeks now, no approval, no rejection, nothing. My app is an anti-doomscrolling app that uses the Screen Time API to block distracting apps until the user completes a workout. Individual use, not parental control. I have Family Controls (Development) approved on all targets, but Distribution is still stuck on Submitted for all of them: com.kmgzora.replock com.kmgzora.replock.MORADeviceActivityMonitor com.kmgzora.replock.MORAShieldAction com.kmgzora.replock.MORAShieldConfig The app is fully ready to ship, this is my last step. I've seen a few threads here where DTS engineers helped people in similar situation, hoping someone can take a look. Thanks in advance.

Hello, I am working on a DLP system for macOS. The application must analyze and potentially block network traffic. Currently, I am using NETransparentProxyProvider for traffic analysis and looking for the best solution to block network traffic. I believe the blocking can be implemented by capturing the flow and choosing not to proxy/forward it further (dropping it). However, I am unsure how the OS and other applications will react to this approach. As far as I know, macOS provides a dedicated NEFilterDataProvider (Content Filter) specifically designed for traffic filtering and blocking. I have two questions regarding the architecture: Is it safe to block flows directly using a Transparent Proxy? Will dropping/ignoring the flow without forwarding it cause any unexpected system behavior, socket hangups, or performance issues? Or is it highly recommended to strictly use a Content Filter (NEFilterDataProvider) for the blocking aspect? Can a single container app install and manage more than one Network Extension in the system? For example, if the best practice dictates separating the logic, can my single DLP macOS application bundle and install both a Transparent Proxy (for analysis/routing) and a Content Filter (for blocking) simultaneously? Thank you in advance!

I’ve developed a virtual machine manager application using the macOS Virtualization framework. The application currently supports both NAT and bridged networking configurations. I’m now looking to implement host-only networking, where the guest VM can communicate with the host but not with external networks. Is this networking mode supported by the Virtualization framework, and if so, what is the recommended approach to set it up? Additionally, I would like to implement port forwarding from the host to the guest (e.g., redirecting traffic from a specific port on the host to a port on the guest). Is there a way to configure port forwarding using the built-in APIs of the Virtualization framework, or would this require a custom networking solution? Any guidance or best practices for implementing these features within the constraints of the framework would be greatly appreciated.

There’s a general UTI category for archives. Does an archive type HAVE to compress the file data, or can the data be stored 1:1? I’m asking because some of the descriptions suggest the category is for compressed archives, but my archive type is 1:1.

Hello, We are currently developing a macOS application and evaluating Managed Background Assets for delivering additional downloadable content. Our preference is to rely on Apple-hosted asset delivery as much as possible, rather than maintaining a separate CDN or server infrastructure. While reviewing the documentation and forum discussions, we found a few areas that are still unclear and would appreciate your guidance. 1. Scope of the 200GB Apple-hosted asset pack limit Some documentation and discussions seem to describe the 200GB limit as applying per Apple Developer Program team/account, while others suggest it is a per-app bundle limit. Could you clarify the exact scope of this limit? Is the 200GB quota applied per individual app bundle ID? Or is it shared across all apps under the same Apple Developer Program account? References: [LINK1] [LINK2] [LINK3] 2. Storage expansion and hybrid hosting Are there any plans to expand the Apple-hosted asset pack limits in the future, or is there an official process to request additional hosting capacity? If an app eventually exceeds the Apple-hosted limit, is it acceptable or technically possible to use a hybrid approach (i.e., using Apple hosting for some assets while self-hosting the rest)? 3. Recommended strategy for older macOS versions As we understand, Managed Background Assets are only available starting from newer OS releases. However, our application also supports older macOS versions, and we would ideally like to avoid maintaining a completely separate asset delivery backend for them. From Apple’s perspective, what is the recommended strategy in this situation? Is it expected that developers continue using Unmanaged Background Assets for older OS compatibility? Is it acceptable to support Managed Background Assets only on newer systems, while older OS versions simply do not receive the same downloadable-content functionality? Or is there another recommended migration/compatibility approach for apps supporting both newer and older macOS versions? Thank you in advance for your clarification!

APP被下架后是否会影响之前已经订阅了自动续费产品用户的定期扣费

This is a long post, so let me start with a summary: I am attempting to implement what "ought to be" a simple SwiftData migration, and am receiving the following fatal error from the ModelContainer initializer: NSCocoaErrorDomain Code=134504 "Cannot use staged migration with an unknown model version." The crash occurs both in the Simulator and on a physical device. Both the original schema and the new schema load and run as expected if loaded from scratch — so I conclude the Models are OK; it is the migration from the original schema to the new schema which is the issue. I have reported this as FB22652791 and Technical Incident Case # 19893980. I have two model projects available — one contrived, the other using my actual SwiftData models. Now the Details I am developing a SwiftUI/SwiftData app. I am (currently) using Xcode 26.5-beta-3. I set up an alpha-test build using the following approach: public class DatabaseSchema { public let dbSchema: Schema = Schema([ Model1.self, ... , Model16.self ], version: Schema.Version(0, 9, 0)) public var modelContainer: ModelContainer { let container: ModelContainer let modelConfiguration = ModelConfiguration(schema: dbSchema, isStoredInMemoryOnly: false) do { container = try ModelContainer(for: dbSchema, migrationPlan: nil, configurations: [modelConfiguration]) } catch { fatalError("Failed to creae model conainer") } return container } This defines database version 0.9. For version 1.0, I made three changes to the database: added an attribute of type String to Model2. added three attributes of type [Struct], where Struct conforms to Codable, Equatable and Hashable to Model3, and added a new model (which I'll call Model17) I define two schemas: public enum Schema090: VersionedSchema { public static var versionIdentifier = Schema.Version(0, 9, 0) public static var models: [any PersistentModel.Type] = [ Model1.self, Schema090.Model2.self, Schema090.Model3.self, ... ] } and public enum Schema100: VersionedSchema { public static var versionIdentifier = Schema.Version(1, 0, 0) public static var models: [any PersistentModel.Type] = [ Model1.swift, Schema100.Model2.self, Schema100.Model3.self, ..., Model16.self, Schema100.Model17.self ] } For models that changed, I use the following approach: public typealias Model3 = Schema100.Model3 extension Schema090 { @Model final class Model3 { ... } public init() { ... } } extension Schema100 { @Model final class Model3 { ... <added attributes, initialized> } public init() { ... } } The DatabaseSchema class was modified as follows: public class DatabaseSchema { public let dbSchema: Schema = Schema([ Model1.self, Schema100.Model2.self, Schema100.Model3.self, ... , Model16.self, Schema100.Model17.self ], version: Schema.Version(1, 0, 0)) public var modelContainer: ModelContainer { let container: ModelContainer let modelConfiguration = ModelConfiguration(schema: dbSchema, isStoredInMemoryOnly: false) do { container = try ModelContainer(for: dbSchema, migrationPlan: MigrationPlan.self, configurations: [modelConfiguration]) } catch { fatalError("Failed to creae model conainer") } return container } where the migration plan is the trivial custom migration that makes sure that all added attributes of existing records are properly initialized. enum MigrationPlan: SchemaMigrationPlan { static var schemas: [any VersionedSchema.Type] = [ Schema090.self, Schema100.self ] static var stages: [MigrationStage] = [version090ToVersion100] static let version090ToVersion100 = MigrationStage(fromVersion: Schema090.self, toVersion: Schema100.self, willMigrate: { _ in }, didMigrate: { context in let models = try context.fetch( FetchDescriptor<Schema100.Model3>()) for model in models { < initial the added attributes > { try context.save() }) } This is all simple stuff. Nothing particularly fancy here. But running this code always crashes in the ModelContainer initializer. In my two sample projects, I get two different error messages — in the contrived example, the error message is Code=134110 "An error occurred during persistent store migration." reason=Cannot migrate store in-place: Validation error missing attribute values on mandatory destination attribute, ... and in the sample project that uses my actual data model, I get NSCocoaErrorDomain Code=134504 "Cannot use staged migration with an unknown model version." My Thoughts Since obviously most folks are doing SwiftData migrations without the problems I am experiencing, the obvious possibilities are I'm doing something stupid that I just don't see. There is a problem because the original schema was given a version value of Schema.Version(0, 9, 0). (i.e., major version number was 0) There is a problem because I am adding an attribute of type [Struct] where Struct is Codable, Hashable, and Equatable. I.e., migration isn't working properly with attributes which are stored as their codable representations. Or maybe something else? In any case, any help you can offer would be greatly appreciated.

I’m trying to understand the intended macOS File Provider behavior when unsynchronised local files exist inside a provider volume that gets deleted. Scenario: A local file is moved (not copied) from a normal filesystem location into a File Provider-backed cloud volume. The provider is disabled/offline or upload is pending, so the file has not yet synchronised to the cloud. The File Provider volume/domain is then deleted from Finder and the deletion is confirmed. In this situation, the unsynchronised file appears to be lost entirely instead of being moved to ~/.Trash. My question is: Why doesn’t macOS preserve unsynchronised local content by automatically moving it to Trash before removing the File Provider domain? From a user perspective, Finder presents the provider volume as a normal filesystem hierarchy, so deleting the volume feels equivalent to deleting a local folder or mounted drive, where local-only files would normally be recoverable via Trash. Is the current behavior expected because: File Provider storage is treated as provider-managed cache rather than canonical filesystem data? Finder delegates deletion semantics entirely to the provider extension? The backing files may not exist as normal files at deletion time? Or are providers expected to implement their own recovery/trash logic? More generally: Is there an Apple-recommended pattern for preventing loss of unsynchronised files during domain removal? Are providers expected to retain pending uploads somewhere recoverable? Is there any supported API for preserving unsynced local items before deleting a domain? I’m asking because this behavior can easily lead to unexpected data loss when users assume Finder trash semantics apply to File Provider volumes.

I’m trying to understand the intended macOS File Provider behavior when unsynchronised local files exist inside a provider volume that gets deleted. Scenario: A local file is moved (not copied) from a normal filesystem location into a File Provider-backed cloud volume. The provider is disabled/offline or upload is pending, so the file has not yet synchronised to the cloud. The File Provider volume/domain is then deleted from Finder and the deletion is confirmed. In this situation, the unsynchronised file appears to be lost entirely instead of being moved to ~/.Trash. My question is: Why doesn’t macOS preserve unsynchronised local content by automatically moving it to Trash before removing the File Provider domain? From a user perspective, Finder presents the provider volume as a normal filesystem hierarchy, so deleting the volume feels equivalent to deleting a local folder or mounted drive, where local-only files would normally be recoverable via Trash. Is the current behavior expected because: File Provider storage is treated as provider-managed cache rather than canonical filesystem data? Finder delegates deletion semantics entirely to the provider extension? The backing files may not exist as normal files at deletion time? Or are providers expected to implement their own recovery/trash logic? More generally: Is there an Apple-recommended pattern for preventing loss of unsynchronised files during domain removal? Are providers expected to retain pending uploads somewhere recoverable? Is there any supported API for preserving unsynced local items before deleting a domain? I’m asking because this behavior can easily lead to unexpected data loss when users assume Finder trash semantics apply to File Provider volumes.

I am using SCScreenshotManager.captureImage to capture image of an app window. i have the sleep settings that sleeps the display but not the system. when the display sleeps taking screenshot using SCScreenshotManager.captureImage does not work. Is there a way i can take screenshot of window when the display sleeps? Thanks

Filing this for engineering visibility and to ask whether the observed behavior matches expected M5 Pro DCP architecture. FB22701284 contains full sysdiagnose and supporting data. Hardware Configuration MacBook Pro 16-inch (Mac17,8) M5 Pro chip, 18-core CPU 64GB unified memory (highest M5 Pro memory tier) 1TB SSD macOS Tahoe 26.4.1 (build 25E253) AppleDCP-1041.100.97~429-t605xdcp.RELEASE Display Configuration Two identical LG UltraGear 27GM950B monitors: 27" Mini LED panels, native 5120x2880 DisplayPort 2.1 UHBR20 (80 Gbps capable) 165Hz native refresh, HDR-capable Connection topology (all third-party display software removed for clean test): Mac TB5 port 1 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #1 USB-C input Mac TB5 port 2 → Silkland DP80 USB-C cable (VESA-certified) → Monitor #2 USB-C input DisplayLink Manager fully uninstalled No dock, no MST hub, no signal converters Apple Specification Context Per the MacBook Pro user guide, M5 Pro supports dual displays at 5K@120Hz (support.apple.com/guide/macbook-pro/apd8cdd74f57/mac), with the documented instruction to "connect the display with the highest resolution first." Observed Behavior Solo connection (either monitor) Either monitor in isolation: 5120x2880 @ 144Hz, Maximum Source Bandwidth 27,400 Mbps, 10-bit, HDR enabled. Dual connection (BetterDisplay 4.3.3 diagnostic) Monitor on dispext0@B0000000: 5120x2880 @ 144Hz, Maximum Source Bandwidth: 27,400 Mbps, HDR enabled Monitor on dispext1@90000000: Degraded from native 5K, Maximum Source Bandwidth: 13,700 Mbps, HDR disabled The 27,400/13,700 split is deterministic and follows connection order. Hardware substitution (cables, ports, monitor positions) confirmed the allocation follows position in connection order, not specific hardware. Each monitor achieves full 27,400 Mbps when solo. Per-pipe budget structure exposed in BetterDisplay 4.3.3 Recent BetterDisplay versions expose allocation limits in display reports: Allocation limits - horizontal: 3360, 3840 pixels HiDPI (6720, 7680 pixels LoDPI) Allocation limits - vertical: 2304 pixels HiDPI (4608 pixels LoDPI) This matches the per-sub-pipe budget structure documented in third-party M5 Max DCP firmware analysis, where M5 Max shows MaxSrcRectWidthForPipe = (6720, 7680, 7680, 7680). M5 Pro appears to expose only two values (6720, 7680). WindowServer assertion failure WindowServer crash on 2026-05-16 with assertion failure in the function calculating per-pipe maximum source rectangle widths: Thread 16 Crashed: com.apple.coreanimation.render-server CA::WindowServer::AppleDisplay::max_src_rect_width_by_pipes(unsigned char) const + 92 CA::WindowServer::AppleDisplay::max_src_rect_pixels() const + 60 CA::WindowServer::Server::get_display_info() + 1812 Exception: EXC_CRASH (SIGABRT), Abort trap 6. This is the same function third-party DCP firmware analysis identifies as governing the per-sub-pipe budget calculation. Reference to Existing Thread Apple CoreOS DTS Engineer Kevin Elliott in thread 814201 (https://developer.apple.com/forums/thread/814201) described M5 MacBook Pro display architecture: "Driving the display at 240Hz require both of the two display 'pipes' and the system ends up allocating both pipes to the first monitor it discovers. That prevents it from lighting up the second monitor, as there isn't currently any way for software to shift allocations of display pipes between machines." That thread addressed a single-display 4K@240Hz scenario where the second display failed to initialize. The underlying allocation mechanism (first-come-first-served pipe assignment, no dynamic reallocation) appears consistent with the dual-display configuration I'm observing, with the manifestation differing (both displays initialize but the second is bandwidth-constrained rather than absent). Specific Technical Questions Is the 27,400/13,700 Mbps asymmetric allocation observed on dual 5K configurations the expected manifestation of the two-pipe architecture described in thread 814201, or a distinct allocation policy specific to dual-display scenarios? The advertised dual 5K@120Hz capability requires approximately 28 Gbps per stream. The observed allocation appears insufficient to drive both displays at this specification simultaneously. Is there a configuration approach that allows both displays to receive adequate bandwidth allocation? Multiple sources document that M5 Max has more display engine output channels than M5 Pro. Is the architectural difference between M5 Pro and M5 Max sub-pipe count (per the BetterDisplay allocation limits and third-party firmware analysis) the underlying explanation for the differential dual-display capability? The WindowServer assertion failure in max_src_rect_width_by_pipes() — is this a known edge case for dual high-bandwidth display configurations on M5 Pro, or should this be filed as a separate issue from the bandwidth allocation behavior? Supporting Data Available BetterDisplay 4.3.3 diagnostic reports for both monitors WindowServer crash report (2026-05-16) ioreg output showing DCP unit assignments sysdiagnose attached to FB22701284 Happy to provide additional FB tickets with focused diagnostic captures if specific data would help engineering investigation.

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding APNs continuity and behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. I’ve done some due diligence on this topic within the forums and found related guidance here: https://developer.apple.com/forums/thread/744468?answerId=776692022#776692022 My understanding from that thread is that the existing push notification credentials will become invalid after a short delay following the transfer, and that we would need to update our backend to use newly generated credentials from the recipient account. However, since things can evolve over time, I wanted to confirm whether that guidance is still accurate for the following scenarios. For users who already have the app installed and previously opted into push notifications before the transfer: Will existing APNs device tokens remain valid after the app transfer? Will these users continue receiving push notifications without interruption, assuming our provider infrastructure remains unchanged? For users who newly install the app after the transfer: Will we need to migrate to a new APNs authentication key or certificate associated with the recipient Apple Developer account in order to successfully register for and send push notifications to those users? For users who restore or migrate the app to a new device (for example, via iCloud Backup restore or device-to-device transfer): Will push notification registration continue to function normally after the app transfer? Will those app instances need to re-register and obtain new APNs device tokens associated with the recipient account? To support this scenario, would our provider infrastructure need to migrate to and use a new APNs authentication key associated with the recipient account? Any clarification on the expected APNs transition behavior during and after an app transfer would be greatly appreciated. Thank you.