I solved the problem. I had switched on the "Code Review" button (icon left-pointing arrow above right-point arrow) in the top right area of the middle (code) pane.

Me too! It works in most of my projects, but with my 20-year old macOS project which I converted to a workspace a few years ago, clicking on the project name there never shows that "second sidebar", as you call it. It shows me the raw text of the .pbxproj file instead. I'm not sure, this may be the first time I've tried to edit a Target Setting since updating to Xcode 26 beta. Did you ever figure this out? Thank you.

I'm moving on, Quinn. Thank you for the explanation.

Thank you, Quinn. I attempted to run the store-credentials but got a confused. It asked me for the Path to App Store Connect API private key. I didn't have one of those. So I attempted to create a new key here: https://developer.apple.com/account/resources/authkeys/ To make a long story short, this led me down the wrong keygen rabbit hole. After some more poking around I found this page: https://appstoreconnect.apple.com/access/integrations/api Success. store-credentials accepted the key which I created there, and created a new keychain item which works with notarytool submit. Problem solved. Except to understand why. As you can see from my screenshot, the old keychain item wrapped a password (which was 19 characters), with a name. The new keychain item is much more complex. Its Name is com.apple.gke.notary.tool, Account is le.gke.notary.tool.saved-creds.MyName and its Where is appStoreConnect. Most intriguingly, when I click Show password, and enter the keychain password, nothing happens. So maybe the problem was that the current version of notarytool no longer accepts my old-style simple password keychain item. It now requires this fancy item which based on a private key that Keychain Access can't show me. Is that more or less what happened?

Yes, if I change the swift-argument-parser in the Sparkle project to match that in my project, the problem is solved. But my project does indeed need swift-argument-parser version 2.x. I suppose I could test Sparkle with swift-argument-parser 2.x and submit a pull request to Sparkle if it passes. But I kind of think I should file a bug against Xcode or Swift Package Manager: Should these tools not be able to handle different projects in a workspace requiring different versions of the same remote package? Or is there a better way to fix this of which I am not aware?

Eureka, probably. My workspace includes the Sparkle updater (sparkle-project.org), which is in a different project folder, and depends on swift-argument-parser 0.4.3. Maybe updating Sparkle will fix the problem.

Clean Build Folder does not change the error. Nor does trashing the project's DerivedData folder in Finder.

This bug (no user interface to delete Document Types) is still present in Xcode 14 GM :( If anyone from Apple reads this, please consider just removing the "Info" tab in the Target editor. It seems to be a poorly synced and incomplete user interface for the Info.plist file which often causes more confusion than just editing the Info.plist file manually. (To make that easier, try the app Plist Edit Pro from Fat Cat Software.)

For me, the fix was to stop searching, stop reading, stop thinking, take a deep breath and remember the universal Xcode fix: Product > Clean Build Folder, stupid!! (By the way, this happened immediately after I updated from Xcode 14 Beta to Xcode 14 GM. So it looks like a perennial problem with Xcode updates.)

At the Silicon Valley, CA NSCoderNight meeting last night, Brian Webster of Fat Cat Software dug into Xcode and found the answer for me. Short version: In general, Xcode 13 can still link to Apple private frameworks. The issue is the SDK. Brian compared the text-based dynamic library description file… Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari.tbd between Xcode 12 and Xcode 13. In the section objc-classes, in the Xcode 12 SDK there is a class named WebBookmarkList as expected, but in the Xcode 13 SDK that has been replaced with SafariWebBookmarkList. When today I changed the symbol name in my project to the new name, now it builds in Xcode 13. But then, how can my code with the old class name still run in macOS 12? Apparently, for some reason, at least for now, macOS 12 is shipping with both the new and old Safari private frameworks. So now, in the words of songwriters Joe Henry and Rhiannon Giddens, I don't know where I'm going • But I'm on my way • Lord if you love me • Keep me I pray :))

I'm surprised no one else is mee-too-ing this. Just to confirm, I have tried it several more times since yesterday. Build in Xcode 12.5 – no problem. Quit Xcode 12.5, launch Xcode 13, same project, same target, same scheme, have not changed anything. Build – fails as described above.

I forgot to mention that I filed a second Feedback Bug with Apple. To summarize: FB9103124, May 11: macOS Big Sur 11.4 Beta 3 killed Full Disk Access for all non-Apple apps FB9120467, May 27: macOS 11.4 broke more than just switching off Full Disk Access (and the trouble continues with macOS 11.5)

At first, I thought that this issue was fixed in macOS 11.5 Beta, because my background agent was getting Full Disk Access without being listed in System Preferences' Full Disk Access list. But, then, and I don't know what I did other than build another new version of my app the other day with Xcode, my helper lost Full Disk Access. Actually, it is even worse than before, because now throwing the kitchen sink at the Apple does not fix it on my Mac. Also, I have had two users report that throwing the kitchen sink at the Apple does not fix it for them, although, for dozens of users, either just re-enabling Full Disk Access for the parent app, throwing the kitchen sink at the Apple does seem to fix the problem. Mercifully, so far, my computer is the only one which has reportedly had the issue recur after it was "fixed". But I can imagine all hell breaking loose worse this time if Apple releases macOS 11.5 without fixing this, or at least telling developers what they need to change in their apps to make them work again.

Well, on the support page which I created for users experiencing this issue, after explaining how to re-enable Full Disk Access, I said that if it still does not work for you, try throwing the kitchen sink at the Apple, as follows: • Watch for our Agent in Activity Monitor by filtering on its process name. • Command our parent app to switch off our Agent. • If one or more of our Agent processes still appears in Activity Monitor, Quit or Force Quit. • If our Agent process keeps reappearing, restart. • Delete any other copies of our app. • Verify that you've got zero of our Agent processes running. • Quit our app if it is running. • In System Preferences … Full Disk Access, switch the checkbox for our app OFF and then back ON. • Launch our app, command it to start our Agent, and see if it has Full Disk Access now. So far, one user who reported that simply re-enabling Full Disk Access did not fix this issue has said that subsequently throwing the kitchen sink at the Apple fixed it.

Until Full Disk Access was introduced, my app had packaged in it a daemon process, launched intermittently by launchd, with the user's privileges. When Full Disk Access was introduced, after many hours of experimenting blindly (no documentation), I concluded that there was no way for this process to have Full Disk Access. To solve the problem, I discarded it and rewrite its functions into a constantly-running Service Management Login Item.