Thank you. The .car file is full of icons, including a variety of sizes of PNG versions of the app icon. It looks like all of this is intended and will presumably melt away as I remove support for older versions of macOS. It's very useful knowing how to examine the contents of a .car file for future reference too. I will close this support case now, your timely and specific answers have been invaluable.

I have read elsewhere that it is possible to keep the older icon for previous versions of macOS. However, I see that a .icns file has been created inside the app containing a single bitmap rendering of the glass icon. Presumably this is what Apple intends to be used so I shall stay with that. I still have the issue of the Assets.car file that has grown from my last (pre v.26) build - now 2.9MB vs 749KB previously. I have no catalogues in my project now. Any clues on where this may have come from? Is there an "official" way to inspect its contents? Thanks again for your help that has got me to a working, albeit large, Tahoe version of my app. I hope this thread may help others also having problems with including a glass app icon in older projects.

I followed the steps suggested above and they made no difference: still no icon when launched. However, after I tried quitting/restarting Xcode and cleaning the Build Folder the app icon showed correctly. Excellent - thank you. My intention is to keep the older app icon for legacy macOS versions so I reinstated my Assets.xcassets and inserted the various resolutions of the original app icon. Emboldened, I also set (to YES) the 'Include All App Icon Assets' build switch. Sadly the old icon does not show in testing on Ventura 13.7.8, only the new one. I repeated this with the build setting as NO with the same result. In the meantime, my app size has ballooned as the Assets.car file has grown to 3.4MB vs 749KB in my last build on the previous version of Xcode (the latest pre-V.26). How should I include the older icons? What has changed to inflate the .car file - all I have done is add the new icon and fiddle with the build settings as described in this thread?

Thank you for the quick response that seems to have moved me forward quite a lot. Sadly it still doesn’t work. My project had an asset catalogue containing the old icon files (called images.xcassets) that I deleted. I created a new one, with the default name and inserted it at the top level of my project. I was then able to import the icon file that I called IconFile. That name is consistent with the name in Project > General; I did not tick “Include all icon assets”. This didn’t work, even after a restart the old icon was still displayed. I then found that the icon file entry in my …-info.plist file still referred to the old icon (that I had removed) so I changed that to AppIcon.icon. That didn’t work either. I cleaned the build folder, the app still runs but has a blank icon (being the outline containing the glass template in white on a pale grey background). Assets.xcassets contains one item being the AppIcon. This is displayed as its three layers plus icon.json that references these and looks credible as the icon file. Any pointers on where to go next would be greatly appreciated. I haven’t seen any diagnostics that seem relevant except a message that I think is long-standing at build time: “cannot open file at line 51040 of [f0ca7bba1c]” - I don’t see enough information there to follow it up. Observation: The page you pointed me to in Xcode Help does not appear when searching on “icon”. Presumably why I didn’t find it. Observation: the process described for creating an asset catalogue is out of date in https://developer.apple.com/documentation/xcode/managing-assets-with-asset-catalogs.

I have also just seen the "height is way too big" issue on Tahoe 26.0. I had recreated all my icons as all-vector PDFs with a large size and the toolbar grew to a huge depth (I presume the same size as the icon's files). Changing the "page" size of the PDFs to 32 (expressed in pixels in Affinity Designer) calmed this down but the icons are scaled to different sizes (mostly too small) if the sizing is left as Automatic. I had just changed them all from explicit sizes of 24-32 pix and it was all perfect on Sequoia/15.6. I though explicit sizes were deprecated so I had changed them as derisking action for Tahoe :-( Has anyone found any up-to-date documentation on NSToolbar? The only docs I have are very old.

Thank you, your first "guess" solves the problem - excellent! For anyone using the Noodlesoft version, the actual code I've added is related to the creation of the NoodleLineNumberView using initWithScrollView:(NSScrollView *)aScrollView. After sending that, I just tweak the custom view as suggested; this is also backwards-compatible which is helpful (at least to me). Note that the line numbers actually live in a vertical ruler. lineNumberView = [[NoodleLineNumberView alloc] initWithScrollView:scrollView]; [scrollView setVerticalRulerView:lineNumberView]; [scrollView setHasVerticalRuler:YES]; [[scrollView verticalRulerView] setClipsToBounds:YES]; // This defaults to NO as of macOS 14 (Sonoma), we need YES to contain its drawing // etc This seems to be a complete fix. I don't remember seeing the AppKit Release Notes, they're very useful although I may not have made the connection without some help. Hopefully there will be some along soon for macOS 15. Thanks again to Ziqiao Chen for the help.

In reply to The Eskimo, 6 days ago: Sorry for the delay in replying, I've been away. OK, I thought I had pressed the disclosure triangle to show the 8 identical errors but I've found it now (below). Note that I have changed my CIImage code and am now using CGImage but with the same issue. Xcode is 14.2, I have no earlier reference as it's new code. As you can probably see, the code is in a method run from a block invoked by a Save panel when the user clicked on 'Save'. Since the backtrace does include my code, Perhaps I can't just ignore it; it seems to be CGImageDestinationFinalize causing the issue. Odd that I get 8 copies of the report though.

Here's another datum. I propose to follow the "it’s likely that this isn’t your problem and you should feel free to ignore the issue" advice but this is an occurrence not involving WKWebView. I get no less that 8 occurrences of the warning from a use of UIContext. Though I may agree it would be better not to use it on the main thread, 8 warnings seems a little excessive. I did try obtaining the NSURL separately into a variable fed into this statement but (unsurprisingly) that made no difference. Xcode 14.2, macOS Ventura 13.2, targeting macOS 10.14.