On macOS 26.2 (Tahoe), the Preview app fails to render many USDZ models correctly. The issue appears inconsistent: • Some USDZ files open normally in Preview • Some USDZ files open but the viewport turns completely black (no geometry, no material, no lighting) • All the same files open correctly when opened using “Open With → Xcode” This was not the behavior on macOS 15.7.2, where the exact same USDZ files rendered consistently in Preview without failures.

Hello, We are trying to use the new Background Upload Extension to improve uploads of assets (Photos, Live Photos, Videos) in the background in our application. 1 - We implemented the code to upload still images. We would like to do the same for Live Photos but we are not sure how to proceed since a Live Photo is composed of 2 resources that we would like to upload in the same job so that we keep the association between the 2 resources. Steps: A Live Photo is captured on the device. Our application is notified for new content in the Photo Library and the asset is queued for upload by our application. The system calls the background upload extension and the Live Photo is prepared for upload but we can schedule a job only for one resource (still photo or paired video) so we can not upload both resources in a single job. 2 - Is there a way to synchronise the application and the extension so that the application would not process the same data or execute the same requests than the extension. For example: our application is working with tokens and we would like to prevent those tokens to be consumed by the application and the extension at the same time. 3 - is there a command in xcode or terminal to start or stop the extension, something similar to what exists for processing tasks (https://developer.apple.com/documentation/backgroundtasks/starting-and-terminating-tasks-during-development).

I received my approval for FairPlay Streaming (FPS) and was getting things organized and then my computer crashed. So... Yes, I lost the 32 digit Account Security Key (ASk) that I was warned not to lose repeatedly... I understand that I can't query apple for the existing ASk. I don't see where I can delete the existing cert to request another one. So I assume I'll need to start from scratch either with another FPS approval process. Can someone please direct me on next steps for this boneheaded situation. Thank you

With the help of Claude and Codex, I've tried upgrading a screen magnification, capture, and pixel peeping app (SnoopX, from Stanford's software repository) to be HDR-aware. For images that are truly HDR (displayed in Apple Photos, Google Photos in Chrome, or Mac Preview), and on an HDR monitor with plenty of EDR headroom (Apple XDR display), I should see pixel values well above 1.0. Apple's Digital Color Meter does. However, my app does not. I think the code is doing all the right things with ScreenCaptureKit, but it never returns values above 1.0. Has anybody gotten this to work? Here is what Codex says about the code it helped me build in my app: • Set captureDynamicRange: We set config​.capture​Dynamic​Range = ​SCCapture​Dynamic​Range​HDRLocal​Display (when available). Note: Gemini’s SCCapture​Mode​HDRLocal​Display isn’t a real symbol — the actual API is SCCapture​Dynamic​Range. • Use preset: We try init​With​Preset: ​SCStream​Configuration​Preset​Capture​HDRStream​Local​Display, but your runtime crashes on init​With​Preset: (unrecognized selector), so we fall back to manual config. That means your system SDK headers mention the preset, but the runtime doesn’t implement it. • Pixel format: We explicitly set k​CVPixel​Format​Type​_64​RGBAHalf. Your logs show the stream buffer is 64RGBAHalf. • Enable HDR on display: EDR headroom logs show current=6.40, so HDR is active. • Color space: We set Extended Linear Display P3 for stream, and we forced the screenshot sampler to convert into extended‑linear P3 before reading. The screenshot itself reports Extended sRGB, but conversion doesn’t yield >1.0 either. Despite all of that, the OS is still delivering tone‑mapped values (max 1.0000) for both the stream and the screenshot path. So I don’t think there’s a missing knob here; it looks like a system‑level limitation on Tahoe for desktop capture.