I posted this as a new separate question, maybe an Apple engineer will respond: https://developer.apple.com/forums/thread/794485

It would be great to have a simple way to enforce alternate icons for older macOS versions in XCode while using the Icon Composer generated ones for Tahoe. Prior to Xcode 26 beta 4, one could add an App Icon set to Assets for legacy macOS versions and use the an Icon Composer variant in the project root for Tahoe. Enabling "Include all app icon assets" under target settings also helped according to some. This option is now gone, Beta 4 insists on populating the Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. The App Icon variant 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 png variants generated by Icon Composer. Several app developers (especially with icon designs that try to follow the curvature of the standard icon size) are struggling with this issue.

This no longer seems to work with Xcode 26 beta 4, at least for macOS. Beta 4 insists on populating the Assets.car with Icon Composer generated variants, disregarding the App Icon provided in Assets. :( The App Icon variant 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 png variants generated by Icon Composer. Since the default icon rounding radius is different, I can't use the Icon Composer generated icon for older macOS versions (the icon design needs to follow the curvature of the icon background) as that would look super-ugly. Icon Composer has no option to add variants for older macOS versions, so I need to use custom icons. Xcode 26 beta1-beta3 at least gave the option to do so with this workaround.

Yeah, this does not seem to work even with Xcode 26 beta2.

Of course, thank you! FB17797423 I also added some more details and info about how to reproduce the issue quickly with the app BetterDisplay which contains the feature of both creating virtual screens and showing their content in Picture in Picture windows. One can consult this GitHub issue/discussion about reproducing the problem quickly (and get a bit more info): https://github.com/waydabber/BetterDisplay/issues/4405 Quick steps to reproduce the issue with BetterDisplay installed: Steps to reproduce: (0. Enable Screen Recording permissions for the app.) Set up two virtual screens (app Settings - gear icon - > Displays > Overview > Create New Virtual Screen), name them ("Virtual 1" and "Virtual 2"). In the app menu, connect the created virtual screens (toggle in the header), and then launch a Picture in Picture window (this uses SCStream) for both screens (see the Picture in Picture menu item in the app menu for the virtual screens). Show some content on the virtual screens or use "Identify Visually" (quick way: OPTION + Click on the header in the virtual screen’s header in the menu block) to confirm that all is well at this point. Disconnect "Virtual 1" (using the toggle in the menu header) Reconnect "Virtual 1" (using the toggle in the menu header) Reopen the PIP window for "Virtual 1" Confirm that the PIP window "Virtual 1" shows the content of "Virtual 2" I am happy to provide more info and share the relevant code or the app is using to reproduce the issue in XCode (but regarding SCStream, everything is done according to the book, so there is not much to share). I think the root cause is that whatever SCStream (and previously CGDisplayStream) relies upon ends up working with the wrong framebuffer (?) in certain cases when virtual screens are involved (note: interestingly, if confused virtual screens have different dimensions/resolutions, the streamed content is clipped, so the dimensions reported by SCContentFilter is properly taken into account - the native macOS Screen Sharing menubar extra item also shows the wrong, clipped content - to me this shows that the ScreenCaptureKit API at some higher lever tries to do the right thing).

Hi there, thanks again for fully fixing the hang/slowdown issue in the latest versions of XCode 16. :) The SourceEditorDataSource.contentRangeForLineRange(_:) + 244 issue/crash when trying to commit a localization change still persists. I am sure there is an offending character somewhere in the project's Localizable.xcstrings, but since this is now such a monolithic file with all languages combined, it is simply not possible to pinpoint where the issue is + the issue would just reintroduce itself as translators submit new translations. Would it be possible to somehow escalate and fix this issue as well? I am sure others encounter similar issues. I posted a new thread about it so the issue is not conflated with the hang issue which is now fully fixed: https://developer.apple.com/forums/thread/767230?page=1#811224022 Thank you!

Here is a crash log for the current XCode 16.2 beta (16B5100e) for reference. Xcode-2024-10-27-092154.ips.txt

Still, even with the latest 16.1 beta2 I experience some of these issues. The long delays on compile is mostly gone, which is a welcome improvement! :) Opening Localizatble.xcstrings still cause some temporary hang. Any commit that involves Localizable.xcstrings however still crashes XCode at SourceEditorDataSource.contentRangeForLineRange(_:) + 244 (issue described in FB14906558): Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 SourceEditor 0x1172202e4 SourceEditorDataSource.contentRangeForLineRange(_:) + 244 1 IDEDelta 0x372d9d768 specialized Collection.map<A, B>(_:) + 212 2 IDEDelta 0x372d9a198 SourceCodeGalleryExhibitEditor.delta_collapseToSuggestedLineRanges(for:) + 796 3 IDEDelta 0x372d64e7c ComparisonContext.sessionDidScrapeDiffResults(_:) + 276 4 IDEDelta 0x372d651f8 @objc ComparisonContext.sessionDidScrapeDiffResults(_:) + 52 5 DeltaFoundation 0x1313dd4e8 -[DESession _notifySessionDidScrape] + 212 6 DeltaFoundation 0x1313dcf3c -[DESession _scrapeResults] + 400 7 DeltaFoundation 0x1313dc940 __38-[DESession performDiffAsynchronously]_block_invoke_3 + 68 8 libdispatch.dylib 0x184dc68f8 _dispatch_call_block_and_release + 32 9 libdispatch.dylib 0x184dc8658 _dispatch_client_callout + 20 10 libdispatch.dylib 0x184dd6f68 _dispatch_main_queue_drain + 980 11 libdispatch.dylib 0x184dd6b84 _dispatch_main_queue_callback_4CF + 44 12 CoreFoundation 0x1850a0bb4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 13 CoreFoundation 0x185060930 __CFRunLoopRun + 1996 14 CoreFoundation 0x18505fae8 CFRunLoopRunSpecific + 572 15 HIToolbox 0x1905e9f64 RunCurrentEventLoopInMode + 292 16 HIToolbox 0x1905efd54 ReceiveNextEventCommon + 636 17 HIToolbox 0x1905efeb8 _BlockUntilNextEventMatchingListInModeWithFilter + 76 18 AppKit 0x188ba0e2c _DPSNextEvent + 660 19 AppKit 0x1894dae2c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 20 AppKit 0x188b93e80 -[NSApplication run] + 480 21 IDEKit 0x107d60ee0 -[IDEApplication run] + 60 22 AppKit 0x188b6a750 NSApplicationMain + 888 23 dyld 0x184bf8274 start + 2840

Thank you! I posted two additional feebacks: FB14906558 about the crash on commit with crash log included. Issue happens with probably some offending character somewhere in the huge Localizable.xcstrings file which Xcode might have issue processing changes to show diff on the Commit tab. Crash consistently happens at SourceEditorDataSource.contentRangeForLineRange(_:) + 244 FB14906651 is about the hang/wait on end of most builds or sometimes opening Localizable.xcstrings. During this the CPU is at 100% and Xcode is indicated as not responding by Activity Monitor. Most of the activity causing the hang seems to be happening in IDEXclocNavigableRep.respondToXclocChange(_:) (in IDELocalizationCatalogEditor) + 256. This however usually takes only 5-15 seconds, so much better than the initial issue. Still, this wait adds up, especially if one needs to build regularly. Thank you for looking into these issues, I really appreciate your work and sorry for the grumpy tone of my earlier comment. :]

Sadly localization still causes a 5-15 seconds complete freeze (with the Build Succeeded bezel notification stuck on the center of the screen) after a compile when changing any SwiftUI source - even in the latest beta6. I guess this won't be fixed now, but this is something truly disrupting and slows things down especially if one needs to recompile a lot. Somewhat unrelated, but Xcode still tends to crash on commits due to some character issue somewhere in localization. With the huge, monolithic Localizable.xcstrings it is almost impossible to figure out what character and where offends XCode and whenever translators change something and a new translation is imported, the issue reemerges anyway, so we gave up hunting for these issues and instead switched to using GitHub Desktop to commit and push as Xcode is basically useless for this task. While all the improvements are truly appreciated, things are very half-baked still, it would be great if Localization support could be improved, it's now a huge pain. :|

Things improved vastly in beta4. There is still a hang when opening Localizable but it only takes 6-7 seconds (MBP 16" M3 Max), which is much better than the minutes it took previously. The same delay happens on completion of a build. CPU usage is 100% and even the Bezel notification ("Build succeeded") on build completion stays locked on-screen for this period of time (as previously, but for a much shorter time). An other huge improvement is that the delay does not happen every time I open Localizable or rebuild the project - whatever is happening, the results are now remembered for a while, which is great. With this XCode 16 is now usable for me, so I am happy. Thank you! Note: I think whatever XCode is doing with the strings during these times, it still should be doing it asynchronously and give a feedback to the user it's working on something instead of making the UI fully unresponsive.

This problem is still present in Xcode 16 beta3. :( I was hoping I could transition to the new Xcode but this prevents it. it seems like XCode is in some kind of death spiral around IDEXclocNavigableFileRep.respondToXclocChange(_:) and IDEXclocNavigableRep.respondToXclocChange(_:), but I see many more mentions of localization related stuff. I really hope this will be fixed. I had a fair share of issues with Localizations in Xcode 15 as well but those at least had workarounds (mostly various crashes on commit or push because of certain offending characters which I had to hunt down manually, sometimes spending hours to figure out what offendeds Xcode), but this is an issue I can't seem to find the workaround for.

Right, that makes sense. Thanks for the insight and the code, much appreciated! :)

I see, thank you for pointing to this! :) Minor note: I always have a somewhat mixed feeling when a change retroactively reinterprets existing code like this (also: no warning given by Xcode about any possible ambiguity or change in interpretation), especially when a modifier that is required to restore existing behavior is available only in the latest version of the OS and therefore will make us live with a lot of #if available() blocks for years to came. It would be great at least to have the #available attribute for single modifiers - now one either needs to create a custom modifier to deal with this issue or put large chunks of SwiftUI codes into if #available() blocks because of a single version specific modifier.

Hi there, thanks for the response. To clarify, XCode only hangs - as it turns out, eventually (after about 5 minutes of intense work with 100% CPU load) it responds again and I can navigate the Localizable file. The crash log was generated only after (initially) I thought the hang is permanent and killed XCode. Sorry about the inconsistency, it is an xcstrings file, mentioning xcloc was just an old habit. :) I attached the xcstrings file to the Feedback report - however as I mentioned, XCode can open the xcstrings file as an individual file (when not treated as part of the project) without problem, only opening it as part of a project the hang happens. EDIT: I sent the feedback with all the requested info (FB14108294) + added some more context/observations in the description.