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.

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. :|

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. :]

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

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

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!

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).

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

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.

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.

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

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

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

Ok, I did some digging. According to assetutil it seems like Assets.car contains an iconstack that has all the vector layers, color data etc for the glass icon and the traditional MultiSized Image with all the icon size variants for legacy macOS versions. In beta3 however (probably due to a bug) the MultiSized image variants were not created based on the Icon Composer image (only a single 1024x1024 variant was created). This gave way for the .incs file compiled into the app root to be taken as icon image on legacy macOS versions, which feeds from the proper xcassets icon file provided by the developer, not the Icon Composer generated pngs. In beta4 this was "fixed", so now all size variants 16x16, 32x32...512x512 variants of the Icon Composer based MultiSize Image items are compiled into the Assets.car file - so macOS takes these now. Sadly there is no way to somehow replace these variants with the proper, developer supplied image or remove them (so the .incs file could be taken by legacy macOS versions instead) - the only tool assetutil that is given to manipulate .car files is extremely limited. I really hope Apple will fix this. I don't see why it would be beneficial to entirely disregard the developer supplied App Icon asset and instead render (somewhat oddly looking) variants based on Icon Composer icons meant for glass (it should happen only if the developer does not provide custom App Icons suitable for older macOS versions). An alternate solution would be to improve Icon Composer so it could take icon composition variants for legacy OS versions and the developer (so instead of only "watchOS" and "iOS/macOS" these should be a third "legacy iOS/macOS" option). This could at least enable developers to supply vector and bitmap images that match the legacy icon size/corner rounding. Also there should be a preview option in Icon Composer how the icon would look on older OS versions - the way that Icon Composer now "silently" produces entirely different looking variants for macOS 15 without a developer using Tahoe ever even seeing how it actually looks like is clearly not the right way to go.

Note: I also added an issue about it in case an Apple Developer would kindly look into it and give directions on how to get around this limitation: FB19118531 Thank you!