In Xcode 16, even if Objective-C is selected, the Navigator in the documentation viewer displays Swift information. I don't know when this bug was introduced, but it's there in the last Xcode 16 betas at least. I hope as many developers as possible submit this bug to Apple to get their attention. P.S. Yes, I know there's Dash. For many years, Dash was a much better option than Xcode's built-in viewer. However, in version 5, the Dash developer introduced some unfortunate UI changes that made Xcode a better option to view the documentation in certain cases. Unfortunately, the Dash developer doesn't seem to be interested in user feedback anymore. He's been ignoring suggestions and user requests for years by now.

Xcode 14 introduced some ridiculous Info.plist management bugs which are not yet fixed in Xcode 15: The bugs are manifested in the General and Info tabs of target management: -The Build value in the General tab is not in sync with the CFBundleVersion value in the Info tab (that is, changing the value in the General tab won't affect the Info tab and vice versa). -The App Category value in the General tab isn't in sync with the LSApplicationCategoryType value in the Info tab. -Additional document type properties in the Info tab cannot be added: clicking "Click here to add..." doesn't do anything. -Document types in Info tab cannot be deleted: once you added a document type instance (even as a test) there's no way to remove it.

Something is going wrong with Mac App Store. Suddenly, I can't submit an app due to an "Invalid Provisioning Profile Signature" error: Invalid Provisioning Profile Signature. The provisioning profile included in the bundle com.***.*** [com.***.***.pkg/Payload/***.app] cannot be used to submit apps to the Mac App Store until it has a valid signature from Apple. For more information, visit the macOS Developer Portal. (ID: 63ae9290-28e2-4a65-8614-***) I've never seen this error before. This is a macOS app so no provisioning profile is even required. Nothing changed in the signing settings I've been using to submit this app many times before. Also, I have another, semi-pro, version of this app on the App Store. It's just another target in the same Xcode project which uses exactly the same signing settings as the first target. No issues submitting this version. I assume it's a bug in the Mac App Store engine - I did submit it to Apple. Still I wonder if anyone has experienced this error and has any suggestions. macOS 13.2 Xcode 14.2 Thanks, Leo

I wonder if anyone has figured out a way to retrieve ALL available Finder tags on Monterey and later? On pre-Monterey systems, it was possible by reading this file: ~/Library/SyncedPreferences/com.apple.finder.plist However, this file doesn't exist anymore. Other methods (such as reading Finder prefs or fileLabels of NSWorkspace) only return the 8 standard labels - but not any custom tags created by the user. Googling the subject didn't produce any results.   Thanks for any info, Leo

Xcode 14 keeps being unusable on Ventura: any IBOutlet properties created on Ventura won't be recognized in Interface Builder. It also applies to the latest beta, Xcode 14.1 RC2. No issues on Monterey. It's unusual that such a major bug could make it into the final release (of whether Xcode or macOS or both). It's not some kind of a minor obscure issue that's easy to miss. It's a part of core functionality. The bug makes development in Xcode on Ventura pretty much impossible (at least in Objective-C, don't know if it affects Swift).

It appears that Xcode 14 is simply unusable at this point as new IBOutlet properties are not recognized. (Outlets created in pre-14 Xcode versions appear with a warning sign in Xcode 14 with a tooltip claiming that outlet doesn't exist). To reproduce, create a new outlet in the header file of the app delegate class (or any other class instantiated in Interface Builder): @property (nonatomic, retain) IBOutlet NSButton *testButton; then select this class in Interface Builder and open the Connections Inspector. The testButton outlet will NOT appear in the list of outlets. This naturally makes Xcode 14 totally useless at this point. Bug is submitted to Apple. I wonder if there are users who do not experience this behavior? Thanks, Leo

I wonder if others have the same issue on Monterey: Read-write disk images are not opening automatically when double-clicking the .dmg file (that is, the disk image is mounted by its window doesn't open). Sending this command in Terminal does NOT help: defaults write com.apple.frameworks.diskimages auto-open-rw-root -bool true ALL read-write dmgs are affected. There weren't issues on earlier systems. (I did submit a bug to Apple and they asked me for my sample dmgs).

Is it just my luck - or is Xcode 11 unusable?I just upgraded from Mojave to Catalina and installed Xcode 11 from App Store (all latest versions naturally).Xcode 11 is simply unusable.In brief:On attempt to use Interface Builder, Xcode 11 gradually becomes unresponsive and then everything deteriorates completely. Xcode 10 and everything else works normally.In detail:When opening a project and starting working with code everything seems to be normal. But once I open a .xib file things go downhill.In Interface Builder, when I click elements they're not selected right away but after a brief delay. And then it takes several seconds until the info in the inspector updates.Then scrollers stop working. The entire app becomes unresponsive - like I click tab and it takes awhile until it activates. Then several clicks I performed earlier with no effect, suddenly start executing one after another.Same thing in the code editor: everything I type happens after a brief delay. Code completion doesn't work at all.I did the following troubleshooting:-Deleted and re-installed Xcode 11-Restarted Mac-Created a new clean user and ran Xcode there-Restarted in safe modeNothing helps - exactly the same things happens every time in all projects.Once again, Xcode 10 works normally.Xcode 11 cannot be used.Specs:iMac 2017 27" 40 GB RAMmacOS 10.5.4Xcode 11.4.1 [noSwift, ObjC only, only Mac apps]Thanks for any feedback,Leo

Hi Eskimo,Thank you for your reply on https://forums.developer.apple.com/thread/115670As you suggested, I start a new thread here.I finally got to the bottom of the issue (after wasting few more hours)...Here's the situation in brief:-I successfully sign my app for notarization.-I successfully notarize it with altool and successfully staple. Therefore, I now have an officially notarized app.-However, the notarization process creates an invisible ._Info.plist file in the app's Contents folder.Which results in the following outcome when checking the signature with codesign:codesign -vvv --deep --strict appPath--prepared:aFrameworkPath/Versions/Current/.--validated:aFrameworkPath/Versions/Current/.appPath: a sealed resource is missing or invalidfile added: appPath/Contents/._Info.plistLike I mentioned, this notarized app then goes into my custom installer on dmg, which dmg I also notarize.However, the above issue with ._Info.plist file causes error 65 on attempt to staple the dmg (after successfully running altool):Stapling failedProcessing: dmgPathCloudKit query for dmgName.dmg (2/8162101e375e6e3fd1b06cc397f56181b19db60c) failed due to "record not found".Could not find base64 encoded ticket in response for 2/8162101e375e6e3fd1b06cc397f56181b19db60cThe staple and validate action failed! Error 65.SOLUTION:Delete the ._Info.plist file from the app's Contents folder after notarization. It eliminates the error 65 - and dmg with installer can be successfully notarized.CONCLUSION:There's apparently a severe bug in altool (or stapler?) that injects malicious invisible files into the package of notarized apps - which invalidate their signature.I notarize my apps successfully for months - yet this experienced bug only yesterday for the first time. Also, it so far only happens with one of my apps.I also submitted this bug to Apple via Feedback Assistant.Thanks,Leo