Sonoma beta - app's dialog buttons grayed out - NSTextField wont allow edits

I have a macOS app built with Xcode 14.1 that works perfectly on Catalina through Ventura. Works on Apple Silicon and Intel machines. When it runs under Sonoma (9/12/23 release and earlier) controls in dialog boxes no longer highlight blue but can be pressed. Text fields can not be edited. Radio buttons can be selected but they all stay gray. This happens to not only the app's custom dialogs but Apple's NSSavePanel() and others. It happens in Sonoma with Apple Silicon or Intel versions under Rosetta. An earlier version built with Xcode 13 works just fine (except WebKit has issues). I made a small app that just tries to do a NSAlert() and it works correctly in Sonoma built with Xcode 14.1. I have not seen any other apps do this under Sonoma.

In order to rule out some sort of byzantine focus problem with the view controllers in the app, I removed everything from applicationDidFinishLaunching() and put an NSAlert() in there. Same thing, the default button comes out gray and not blue.

I've tried bumping up the minimum release to macOS 12.x. No luck.

It's nothing to do with Appearance, I have removed all of that code. Deleted all the prefs.

I've rebuilt the project file in Xcode 14.1 from scratch, same thing - no blue focus buttons. I've tried building it with the latest versions of Xcode and the same problem. Any ideas what in the world can cause this?

Answered by KMacTexas in 764760022

Found it. TL;DR - Assets.xcassets and info.plist needed to be rebuilt for the current shipping version of Xcode (14.x). I’ll type up this debugging expedition for future travelers and aspiring Xcode engineers. As stated above the app running under the beta Sonoma release (9/12/23 and earlier) had a problem where none of the default controls in dialog boxes would be their default color blue. Even on Apple’s dialogs like NSAlert(). The buttons worked, they just did not have the correct color. NSTextFields could not be edited. The app works perfectly under Mojave through Ventura. No warnings in the build or in the console at run time. After exhausting every reasonable attempt at debugging this, I rebuilt the app from scratch starting with a new project in Xcode 14.1 and copying the files over from the existing project. After the app was built, same problems. To find the culprit I started taking source code out all the way down to just AppDelegate.swift was left and all it was doing was opening an NSAlert() in the applicationDidFinishLaunching() function. Problem still existed. Then I deleted the info.plist file and the problem went away. This opened a whole new can of worms. It appears that in Xcode 13 and later, the way Xcode interacts with info.plist changed.

This is from the release notes for Xcode 13 -

Projects created from several templates no longer require configuration files such as entitlements and Info.plist files. Configure common fields in the target’s Info tab, and build settings in the project editor. These files are added to the project when additional fields are used.

And from “Developing a Document-Based App” -

Apps must use Xcode’s Document Types editor to define the types of documents they can open. When Xcode builds your app, it places the document type information in your app’s information property list (Info.plist) file.

Using the target’s Info tab I was able to add the Document Types and Exported Type Identifiers. This editor sure seems to be a work in progress. I think the engineers working on this got pulled off mid way to go make everything at Apple be carbon neutral. Here’s a tip - in the Exported Type Identifiers editor there is a field that says “Click here to add additional exported type identifier properties”. Clicking on that or anywhere near it does nothing at all. There is a very narrow invisible box on the far left side, to the left and below the “Key” label you have to blindly click to add type identifier properties.

Added all of those and sure enough Xcode generated a info.plist file with everything in it. And boom the problem with the default buttons came back. Adding Document Types and Exported Type Identifiers seems to have caused the problem. Taking them out fixed the problem with the app. (There is no delete function in the target Info tab editor, so you have to delete them manually from info.plist). To make a lot of these edits take effect you have to stop and restart Xcode. I’m sure when everyone at Apple gets done making new emojis they will get back to working on the target editors.

Next I started adding bits of Document Types one bit at a time until the problem came back. Bingo. Adding icons to the Document Types caused the problem. At this point you must be as puzzled as me as to why adding icons to the Document Type causes default buttons to not show blue, their default color. Try and draw a straight line between that cause and effect? I looked at the JSON inside Assets.xcassets and didn’t see anything malformed - or any garbage characters.

I took an empty Assets.xcassets file from a newly created empty project and copied that to the project and then added the icons back one at a time. This compiled and everything worked as expected. Default controls are blue again in Sonoma.

The best reason for this nightmare scenario I can come up with is the app was originally written in Xcode 11.x. It’s plausible that so much water has gone under the bridge with info.plist and Assets.xcassets with Xcode 13 and 14 that Xcode 14.1 built something that Sonoma could not dissect and caused this weird problem.

A little more info... The first NSAlert() is the app that does not work correctly with Sonoma. This NSAlert() has focus. Notice how the blue folder behind the button does not bleed through the button. The button is active, just not blue.

The second NSAlert() is the simple test app that only has the NSAlert(). It does not have focus, and the blue folder behind it does bleed through. (If this one has focus the button is blue).

Both apps were compiled with Xcode 15 beta (the problem happens with Xcode 14.1 as well) .

Accepted Answer

Found it. TL;DR - Assets.xcassets and info.plist needed to be rebuilt for the current shipping version of Xcode (14.x). I’ll type up this debugging expedition for future travelers and aspiring Xcode engineers. As stated above the app running under the beta Sonoma release (9/12/23 and earlier) had a problem where none of the default controls in dialog boxes would be their default color blue. Even on Apple’s dialogs like NSAlert(). The buttons worked, they just did not have the correct color. NSTextFields could not be edited. The app works perfectly under Mojave through Ventura. No warnings in the build or in the console at run time. After exhausting every reasonable attempt at debugging this, I rebuilt the app from scratch starting with a new project in Xcode 14.1 and copying the files over from the existing project. After the app was built, same problems. To find the culprit I started taking source code out all the way down to just AppDelegate.swift was left and all it was doing was opening an NSAlert() in the applicationDidFinishLaunching() function. Problem still existed. Then I deleted the info.plist file and the problem went away. This opened a whole new can of worms. It appears that in Xcode 13 and later, the way Xcode interacts with info.plist changed.

This is from the release notes for Xcode 13 -

Projects created from several templates no longer require configuration files such as entitlements and Info.plist files. Configure common fields in the target’s Info tab, and build settings in the project editor. These files are added to the project when additional fields are used.

And from “Developing a Document-Based App” -

Apps must use Xcode’s Document Types editor to define the types of documents they can open. When Xcode builds your app, it places the document type information in your app’s information property list (Info.plist) file.

Using the target’s Info tab I was able to add the Document Types and Exported Type Identifiers. This editor sure seems to be a work in progress. I think the engineers working on this got pulled off mid way to go make everything at Apple be carbon neutral. Here’s a tip - in the Exported Type Identifiers editor there is a field that says “Click here to add additional exported type identifier properties”. Clicking on that or anywhere near it does nothing at all. There is a very narrow invisible box on the far left side, to the left and below the “Key” label you have to blindly click to add type identifier properties.

Added all of those and sure enough Xcode generated a info.plist file with everything in it. And boom the problem with the default buttons came back. Adding Document Types and Exported Type Identifiers seems to have caused the problem. Taking them out fixed the problem with the app. (There is no delete function in the target Info tab editor, so you have to delete them manually from info.plist). To make a lot of these edits take effect you have to stop and restart Xcode. I’m sure when everyone at Apple gets done making new emojis they will get back to working on the target editors.

Next I started adding bits of Document Types one bit at a time until the problem came back. Bingo. Adding icons to the Document Types caused the problem. At this point you must be as puzzled as me as to why adding icons to the Document Type causes default buttons to not show blue, their default color. Try and draw a straight line between that cause and effect? I looked at the JSON inside Assets.xcassets and didn’t see anything malformed - or any garbage characters.

I took an empty Assets.xcassets file from a newly created empty project and copied that to the project and then added the icons back one at a time. This compiled and everything worked as expected. Default controls are blue again in Sonoma.

The best reason for this nightmare scenario I can come up with is the app was originally written in Xcode 11.x. It’s plausible that so much water has gone under the bridge with info.plist and Assets.xcassets with Xcode 13 and 14 that Xcode 14.1 built something that Sonoma could not dissect and caused this weird problem.

Sonoma beta - app's dialog buttons grayed out - NSTextField wont allow edits
 
 
Q