“DTiPhoneSimulatorErrorDomain Code 2”

(part 2 of 2) — continuing from my response above. The following performance considerations and progressive-loading techniques apply to both the SwiftUI path and the UIKit path described in part 1. PhotoKit performance tips (apply to both paths) A few details from the PHCachingImageManager and PHImageManager header comments that are easy to miss and matter for smoothness: Use PHImageRequestOptionsDeliveryModeOpportunistic (the default for async requests) — your result handler may be called multiple times: first with a fast, lower-quality result, then with the final high-quality image as it becomes available. This is what lets the grid feel instant even while the real thumbnails are still being prepared. From the header: client may get several image results when the call is asynchronous. Match your caching options exactly to your request options. From the startCachingImagesForAssets header comment: The options values shall exactly match the options values used in loading methods. If your targ

Thanks for the positive observation about the Photos app's grid zoom — it is genuinely smooth, and wanting to replicate that in your own app is a reasonable aspiration. I spent some cycles putting together the following summary of APIs you may wish to explore pursuing this goal. A framing note before getting to the substance: I can't share the specifics of how Apple's Photos app is implemented internally, since that's not something DTS can detail. What I can do is point you to the public APIs and techniques that let you build similar grid-zoom behavior in your own app. The good news is that the public surface includes a class for the interpolated-zoom effect you're after. The SwiftUI path For a photo-library-backed grid with smooth pinch-to-zoom in SwiftUI, the building blocks are: LazyVGrid for the grid container (iOS 14 or later). MagnifyGesture (iOS 17 or later) for pinch input. MagnifyGesture replaced the now-deprecated MagnificationGesture; the gesture's value gives you the magnification factor to drive

Thanks for the detailed report. The symptom you're describing — App ID with MusicKit capability shows as enabled, but the Media Services key creation says no identifiers available — is a clear sign that the Developer Portal has two different identifier paths for MusicKit, and the path you took isn't the one the Media Services key flow uses. The two paths: App ID with MusicKit capability — for native iOS/macOS apps that link the MusicKit framework on-device. The App ID enables MusicKit usage for the app build chain. Documented on the MusicKit Services help page. Media ID — for server-side use of the Apple Music REST API via developer tokens. This is the identifier the Media Services key picker requires. Documented on the Create a media identifier and private key help page. Your server-to-server use case (developer token for catalog search, charts, artist endpoints) is the Media ID path. The fix: Go to Certificates, Identifiers & Profiles → Identifiers → click the (+) button Select Media I

Adding a data point that should help narrow this down. I'm hitting the same nil-objects assertion described in this thread -[IBICAbstractPlatformAdapter selectCatalogIconComposerItemsFromCollection:...] on Xcode 26.5 (17F42), macOS 26.5 (25F71). Two findings from local testing: The crash is content-independent. I tested 13 .icon variants: bare {} icon.json with no Assets/, empty groups: [], single layer with no glass, sRGB instead of display-p3, watchOS removed, --platform macosx instead of iphoneos, etc. All 13 produced the identical backtrace. Standalone repro (no project required): mkdir /tmp/foo.icon && echo '{}' > /tmp/foo.icon/icon.json mkdir -p /tmp/out xcrun actool /tmp/foo.icon --compile /tmp/out --platform iphoneos --app-icon foo --output-partial-info-plist /tmp/p.plist --output-format human-readable-text The crash fires before actool parses the icon content. The mere presence of a .icon directory as input is enough. The regression was introduced after Xcode 26.4.1. I side-instal

Thanks for the precise reproducer — pinning the failure to tap before thumbnail appears, confirming that waiting for the thumbnail makes the tap work, and identifying that the delegate callback never fires in the failing case characterize the timing race. Looking at the public surface of VNDocumentCameraViewControllerDelegate (https://developer.apple.com/documentation/visionkit/vndocumentcameraviewcontrollerdelegate), the delegate has exactly three callbacks: documentCameraViewController(_:didFinishWith:) — successful scan completion documentCameraViewControllerDidCancel(_:) — cancellation documentCameraViewController(_:didFailWithError:) — scan failed or capture unavailable There's no intermediate-state callback (no scan captured but still processing, no ready to commit). The VNDocumentCameraViewController class itself exposes only delegate and the class property supported — no observable property that would signal when the internal processing pipeline has finished. So your reading of the public API is corre

Thank you, yes that FB was submitted earlier today. Two new pieces of data from a tester conversation today that I wanted to put on the record here, because they suggest the asset-accumulation theory may not be the whole story. 1. Cliff transition, not gradual degradation. I just spoke with one customer and he described the failure as one second the screen was fine, the next it was gray boxes. Not a slow boil where one icon becomes the placeholder, then a few more, then most. Sudden onset, every visual at once. 2. Both CPListItem icons and CPListImageRowItemRowElement images fail. I have several list-row icons (connection status, adapter status) and the row-element images on my Driving and Charging tabs (which are CPListTemplates built with CPListImageRowItem rows). The CPListItem rasterized SF-symbol icons are quasi-static. They're gated behind state-change snapshots and only re-rasterized on actual state transitions (connectionDisplay returning a different (symbol, tint) pair, or the adapt

Thanks for the post. Looks like you do not provide me a link to your AASA so I can check the error. If you like to discuss this privately. I'd like you to submit a code-level support request so we can discuss this further privately. When you create the request, indicate that you were referred by Albert Pascual at Apple and make sure to include a link to this thread. Thanks Albert
  Worldwide Developer Relations.

Quick follow-up on point #2 (Security Roles): checked Schema → Security Roles. GuardianRequest and GuardianResponse grant Read via _world, Create via _icloud, Write via _creator — a standard public-DB config. The Read permission query subscriptions need is present, so Security Roles don't appear to be the cause.

Thanks for your new post. I thought I have covered those scenarios on my previous post, I guess I missed something. I would recommend you to look at the documentation and see how AASA files works and how you register the different appIDs do that will give you the knowledge that the most important is to have multiple AppID into the AASA file so you can have 2 apps that will use a unique AASA file. Because the App Store is still distributing that original binary, any brand new user downloading the app for the first time is installing an app signed with the original Team ID. When iOS installs the app and fetches the Apple App Site Association (AASA) file from your server, it will be looking for a match with the original. As long as your AASA file still includes the original and new App ID, Universal Links will continue to function completely normally for these new users during the interim period. This exact behavior is why it is highly recommended to host an AASA file that contains both the original and