I know this post isn't going to give a lot of details, but what I experienced tonight was so completely weird that I wanted to get it posted here in case others run into it: FIRST: All was well until I made a trivial change to a large Objective-C++ module. I suddenly got the idea to look at that line in the code review pane, to see if that area of code had ever had recent modifications. But, the entire module showed up as modified -- one giant change bar, with nothing on the right side of the code review pane, no matter what commit I selected. Then I noticed that the two lines of code which had all of 4 characters edited were no longer showing any change bars. Yet, the file showed up as "modified". Still, the exact line changes were not showing in the source code navigator, even though other files showed their changes. Note I'm connected to our remote repo on github. I did some command line git checks of the local repo, and the changes were there (as yet unstaged). So -- I figured, I'm gonna ask the Apple Coding Assistant what's up. And it gave some fantastic advice, especially on how to confirm the changes really were in the repo ready to stage and commit and push. Which I did. But despite following a couple hours of wonderful suggestions, I could never get the change bars back -- for this one specific file! (yes, the file was in the repo, and in the project -- everything seemed OK with the file itself -- nothing had changed in the project, which compiled and ran perfectly with my changes). SECOND -- suddenly, the AI assistant seemed to crash Xcode. When I went to re-run Xcode, it just crashed exactly the same. The crash log indicated "Xcode is crashing inside the IDEIntelligenceChat plugin while it’s trying to “apply changes” to a Source Editor buffer". Ultimately, I needed to restart Xcode holding down the SHIFT key. I could open other projects, but not the one I had been working on. So I turned OFF apple Intelligence (thanks, ChatGPT). That allowed me to launch. It sounds like some sort of corrupt Apple Intelligence chat logs and/or caches, which ChatGPT has given me extensive suggestions for deleting. I don't have the energy to attack that tonight -- I did an additional Time Machine backup and hope to take a closer look tomorrow. Ideally -- I'd rather NOT lose all my on-going coding assistant chats for this project -- I had some ongoing suggestions I was working on. But more concerning is the weirdness with changebars affecting this one 7,000 line .mm file. It doesn't seem like there's anything that should affect those change bars for ONE FILE that is in the repo and where changes can be seen from a git diff command line operation. If it's a bug -- I can live with it. But it's worrisome. Other than that, Xcode 26.2 has been running great! Unlike 26.1, which insisted on re-compiling all 600 files in my project every time I ran/debugged, 26.2 just does the 2-6 modified files -- a perfect incremental compile. I've saved HOURS of wasted unnecessary compilation since 26.2 was released.

I noticing that Monterey defaults to the NSWindowToolbarStyleAutomatic / NSWindowToolbarStyleUnified toolbar style, which suppresses the "use Small Size" menu item and customization checkbox. So I've set the window to use NSWindowToolbarStyleExpanded. However, the toolbar will no longer change to a smaller icon size, as it did in MacOS 10.14, 10.15, and 11.0. I've tried to set the toolbar item sizing to "Automatic" for all of our toolbar icons, but that results in bad positioning in both Regular and Small Size mode -- the height is way too big. The native size of the icon .png files are 128 x 128. What's odd is that if I resize the window with the toolbar to be wider, the NSToolbarItems in the overflow area will be displayed in the toolbar are 128 x 128, where the rest of the toolbar icons get displayed as a 32 x 32 icon. The only way to get it to layout remotely correct is to make the NSToolbarItem to have an explicit minimum size of 24 x 24 and maximum size of 32 x 32. And that USED to allow "small size", but on Monterey, it no longer does. Anyone had any success with small size icons on Monterey?

Something has happened to our users that are running MacOS Sonoma: our app's main window (NSView ) is no longer getting the NSResponder deleteBackward "bindable command" message when the user presses the DELETE key, and is connected to an Apple Extended Keyboard. (it DOES work on a laptop, however) Similarly, laptops that have updated to MacOS Sonoma no longer send the previously-accepted unicode key code for the FORWARD DELETE key: "\u007F". Both these keys worked PERFECTLY on all earlier versions of MacOS (Mojave 10.14 through Ventura 13.x). Any insights?

Sometimes while drawing from my main thread I have error conditions that I need to relay to the user, and often need to get the user to interact (enter text, press a button, etc) -- and then CONTINUE from inside the main thread drawing process that was interrupted. However, the main thread doesn't like it when you try to draw while already drawing from within the main thread (I think it even throws an exception if you try). Is there a canonical approach to handling errors that occur during drawing that require more sophisticated error handling?

On MacOS 12.0 (Monterey), no attempt to use tccutil (with sudo or otherwise) works. All cases returned an error: mbp16inch2021:/ Stephen$ sudo tccutil reset com.mycompany.AppName tccutil: Failed to reset com.mycompany.App mbp16inch2021:/ Stephen$ tccutil reset AppName tccutil: Failed to reset AppName DTS confirmed it didn't work for them, too. I'm about to submit a bug, but maybe I have the syntax incorrect?