Several app developers are struggling with the inability to provide a separate app icons that looks nice on older macOS versions while at the same time provide Icon Composer icons that look great on macOS Tahoe 26. An ability to provide separate icons is super important to those who have app icons that follow the curvature of the default icon borders (as the corner rounding radius is different for Sequia and Tahoe). Take a look at this for example: https://github.com/ghostty-org/ghostty/issues/7564#issuecomment-3042061547 Question: Is there a definitive/recommended way to address this issue? How can a developer add a glass icon variant that looks good on Tahoe and provide a bitmap icon for older macOS versions? Some background info: Prior to Xcode 26 beta 4, one could add an App Icon to Assets to be used as app icon for legacy macOS versions (Sequia and older) and use a new Icon Composer icon (placed in the project root) for macOS Tahoe 26. Enabling "Include all app icon assets" under target settings ensured that older macOS versions would use the old app icons while Tahoe the new Icon Composer glass one. Since Xcode beta 4 this technique no longer works. Xcode instead insists on populating Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. Although the App Icon in Assets makes its way to a .incs file in the app bundle's Contents/Resources folder, but that is not used by macOS anymore and is there for some compatibility purposes. The Assets.car file (which matters) only contains the variants generated by Icon Composer and does not contain the png icons provided in the Assets.

If there are multiple virtual displays connected when an app starts using SCStream, then if there is any change in the configuration of connected virtual screens (one of them gets disconnected, reconnected, etc), a new SCStream will always stream the content of the last connected virtual screen, no matter which virtual screen is intended to be streamed. This happens despite the fact that the SCContentFilter is properly configured for the stream, with the filter's content having the right displayID with the proper frame in the global display coordinate system and the filter also confirms that it knows the proper contentRect size and pointPixelScale. When all virtual displays are disconnected and reconnected, things return to normal - it's as is SCStream somehow gets confused and can't properly handle or internally reenumerate multiple virtual screens until none is connected. This issue does not normally come up, as most users will probably have only one virtual displays (like a Sidecar display) connected at most. However some configurations (like systems using multiple DisplayLink displays or apps using the undocumented CGVirtualDisplay to create virtual screens) encounter this issue. Note: this is a longstanding problem, has been like this from the first introduction of ScreenCaptureKit and even before, affected CGDisplayStream which similarly confused virtual screens.

Whenever there is any change in Localizable.xcstrings, XCode 16 simply crashes. This happens since early betas and continues even through the latest XCode 16.2 beta. The issue is probably due to some obscure character somewhere in the now monolithic Localization.xcstrings file which now contains all (sometimes rather exotic) localizations - thus making pinpointing the offending character basically impossible. The issue seems to happen when the Commit UI tries to produce the delta in the Localizable.xcstrings source code. The crash in question is this: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 SourceEditor 0x132c33b04 SourceEditorDataSource.contentRangeForLineRange(_:) + 244 1 IDEDelta 0x362349768 specialized Collection.map<A, B>(_:) + 212 2 IDEDelta 0x362346198 SourceCodeGalleryExhibitEditor.delta_collapseToSuggestedLineRanges(for:) + 796 3 IDEDelta 0x362310e7c ComparisonContext.sessionDidScrapeDiffResults(_:) + 276 4 IDEDelta 0x3623111f8 @objc ComparisonContext.sessionDidScrapeDiffResults(_:) + 52 5 DeltaFoundation 0x1444bd4e8 -[DESession _notifySessionDidScrape] + 212 6 DeltaFoundation 0x1444bcf3c -[DESession _scrapeResults] + 400 I posted a FB about this way back then (FB14906558) and sent numerous reports but the issue is just not getting resolved.

For whatever reason SwiftUI sheets don't seem to be resizable anymore. The exact same code/project produces resizable Sheets in XCode 15.4 but unresizable ones with Swift included in Xcode 16 beta 2. Tried explicitly providing .fixedSize(horizontal false, vertical: false) everywhere humanly possible hoping for a fix but sheets are still stuck at an awkward size (turns out be the minWidth/minHeight if I provide in .frame).

XCode 16 beta1 and beta2 hangs whenever I try to open Localizable.xcstrings. The localization screen appears but afterwards XCode becomes unresponsive until I kill it. To make matters worse, upon restart the last window, Localizaton is reloaded, instantly causing a hang again (I need to be super quick as I have about half a second to try to click elsewhere like crazy). The same localization strings file works fine on XCode 15.4. I tried to export all localizations in 15.4, empty the file, re-generate localization strings, re-import languages one by one in 16, starting with different languages (thinking maybe a weird exotic character causes the issue with one of the languages, this happened previously crashing XCode 15 until I found the offending character and replaced it with something else). But generally even after just adding a single language there is a serious slowdown - after adding the second one, XCode hangs again. Note: the app in question has a lot of localizable strings - I had no issue creating a simple project with only a few strings. Just hoping a fix - I really wished the issue was fixed in beta2 but now I am a bit concerned that maybe it's a rare problem and might not get fixed as I saw no similar reports so far.