Thank you for the update! Hopefully, it's a quick one to fix.

Apologies. Attached both the above image and one from Xcode 26 (both on macOS 27). Both are configured to use the same font, but I don't think that's the issue. For posterity, here is how it looks in 26:

Device Hub sucks. At least in its current iteration. Simulator rotation is bugged (issue doesn't exist when controlling the same iOS 27 runtime with Xcode 26's Simulator app) Debug menu—gone Device list in Dock icon context menu—gone Many menu shortcuts are missing Importing files into the gallery or file system—gone That's on top of the plethora of windowing bugs this application still experiences. Used to be that AppKit developers got that aspect of development right. Now it seems there are very few AppKit developers left, even at Apple. It's clear that whoever is implementing or vibe-coding this is not a power user of the simulator. Or Mac apps in general. Most of the features mentioned above are still supported by the simulator runtime just fine, as evident, again, by targeting the same runtimes with the old Simulator app. So skipping a debug menu is a choice, not a necessity. I get it, you had to ship the resizable simulator feature … for iPhone mirroring wink wink. But the situation is dire.

🙂 Hi Quinn My personal machine. I think every personal device is now on 27. Once I figures I can change the version number of Xcode 26 in the Info.plist to fool the OS to let me run it from the icon, I just upgraded. But ended up not needed, as reported above. Work machine is Tahoe, but I seperate the two lives. If I have time this weekend, I'll see if I can install a VM and quickly try to build.

Thanks for reaching! Unfortunately, I have updated my Mac to Golden Gate beta. This issue only occurred on macOS 26.0 with Xcode 27.0 betas. I am unable to verify.

Would attaching just the Xcode project (.xcodeproj) + a build log that includes the above error assist?

Unfortunately, the issue persists with Xcode 27 beta 3.

FB23420382

@Rastafabi Your suggestion does not answer the question, nor does it do what was asked; that sips command creates an 8-bit PNG, not 16-bit.

It’s UIActivityViewController with private API: https://developer.limneos.net/index.php?ios=17.1&framework=SafariServices.framework&header=UIActivityViewControllerObjectManipulationDelegate.h @protocol UIActivityViewControllerObjectManipulationDelegate <NSObject> @optional -(BOOL)_customizationAvailableForActivityViewController:(id)arg1; -(id)customActionViewControllerForActivityViewController:(id)arg1; -(id)customLocalizedActionTitleForActivityViewController:(id)arg1; @required -(id)_customizationGroupsForActivityViewController:(id)arg1; @end

The joke that is Apple development tooling, Apple quality assurance, and Apple in general. How embarrassing for the richest company in the world.

For posterity, the issue still exists in iOS 17, and it’s by Apple’s assumption that a split view controller is always a window’s root view controller. You can workaround this by overriding the trait collection of the split view controller when the parent tab bar controller’s collection changes: override func willTransition(to newCollection: UITraitCollection, with coordinator: any UIViewControllerTransitionCoordinator) { super.willTransition(to: newCollection, with: coordinator) coordinator.animate { _ in if let split = viewControllers?.first as? SplitViewController { setOverrideTraitCollection(newCollection, forChild: split) } } }

I now see that PHImageRequestOptions has the following private properties, which you can use to obtain and fine-tune HDR images using all image loading APIs: @property (nonatomic) BOOL includeHDRGainMap; @property (nonatomic) BOOL includeHDRGainMapInIntermediateImage; @property (nonatomic) BOOL preferHDR; @property (nonatomic) double targetHDRHeadroom;

Have you, by any chance, added amfi_get_out_of_my_way=1 to your boot-args? It is known to interfere with the TCC permission system, and the OS stops displaying the permission dialogs to users. You can remove the amfi_get_out_of_my_way argument, reboot, run your app once so the OS displays the alert and you accept, and you can add the amfi_get_out_of_my_way=1 argument back.

For images, use the requestImageDataAndOrientation(for:options:resultHandler:) method to obtain a photo’s data, which contains the HDR information. Then you can use CGImageSource, UIImageReader with prefersHighDynamicRange, CIImage, etc. to obtain a UIImage that will correctly display on HDR screens. For live photos, it’s more complicated. The PHLivePhoto object obtained from requestLivePhoto(for:targetSize:contentMode:options:resultHandler:) does not contain an HDR image. You can use requestImageDataAndOrientation(for:options:resultHandler:) to obtain the HDR version of the image, as above, but displaying it in a PHLivePhotoView is not as simple. There is private API you can use, which I’ll post below, but it’s up to you to decide if that’s risky for you. All private API can be hidden, if the only thing you fear is App Store submission. fileprivate static func fudgeLiveView(_ liveView: PHLivePhotoView, with image: UIImage?) { if let image { liveView.setValue(image, forKeyPath: "playerView.overrideImage") } guard let view = liveView.value(forKeyPath: "playerView.subviews.@firstObject") as? UIView else { return } for subview in view.subviews { if let imageView = subview as? UIImageView { imageView.preferredImageDynamicRange = .high } } }