I'm now using Xcode 14.2 (14C18) and I'd like to the documentation features working again. The integrated documentation used to work in Xcode 13, but sporadically stopped working when I upgraded to Xcode 14. I recently noticed that there is now an explicit Product > Build Documentation command. When I run that, I get a bunch of failures. (Note that this is a large project with many targets, all of which build and archive OK.) The problem seems to be that all of the files (specifically some .h files) are getting compiled/scanned separately. Even ones that aren't included anywhere (for historical reasons). So I end up with failures for lines like this one: #error class unimplemented /* the sockets interface was never used */ This error doesn't occur during regular compilation, because the .m file that includes it is not included in any targets. Now some of these I could clean up, but the next error has me completely stumped. I have a simple "version.h" file that defines the following symbols: #define PRODVERSION_MAJOR 3 #define PRODVERSION_MINOR 0 #define PRODVERSION_FIX 0 #define PRODVERSION_BUILD 73 #define PRODVERSION_NUMERIC 3.0.0.73 The last line fails with the error "invalid suffix .0.73 on floating constant" Which makes me think that the preprocessor used by the document compiler is trying to interpret this symbol as a floating point number and failing. So is there away around this? I'm specifically wondering if there are preprocessor symbols defined by the documentation compiler that can be used (i.e. #ifndef __DocC__...) to exclude code from the documentation build.

I have a helper app that must, occasionally, run as root. I've spent the last year added a bunch of functionality in Swift and testing it on Big Sur without any problem. I just now tried installing it on High Sierra (10.13.6), and when the helper is launch as the regular user is runs just fine. But when launched as root, I get dyld: warning, LC_RPATH @executable_path/../Frameworks in /Users/USER/Library/Application Support/MyApp/Helper.app/Contents/MacOS/Helper being ignored in restricted program because of @executable_path dyld: Library not loaded: @rpath/libswiftCore.dylib   Referenced from: /Users/USER/Library/Application Support/MyApp/Helper.app/Contents/MacOS/Helper   Reason: image not found Abort trap: 6 So what do I need to do to get the Swift runtime libraries to load?

Big Sur finally retired the (depreciated) hdiutil flatten and hdiutil unflatten commands. In its place is the hdiutil udifrez which writes legacy resources to a UDIF disk image. However, no matter what I've tried, it breaks our distribution disk images. Specifically, what our release scripts used to do was this (simplified version): This process starts with the application to release (PRODUCT_CLIENT_APP) and an existing Disk Image file (PROTO_IMAGE_SRC) that's all pretty (has a custom background, window size, ...). The prototype disk image is duplicated, mounted, and the release app is copied onto it: cp -f "${PROTO_IMAGE_SRC}" "${PROTO_IMAGE_WORK}" hdiutil attach "${PROTO_IMAGE_WORK}" cp -R "${PRODUCT_CLIENT_APP}" "${PROTO_VOLUME_DIR}" The image is then unmounted and compressed hdiutil detach "${PROTO_DEVICE}" hdiutil convert "${PROTO_IMAGE_WORK}" -format UDCO -o "${DMG_RELEASE_SIGNED}" Here's where the license was attached. The disk image was converted to a forked disk image file, the resource file was compiled and attached, and then converted back to a flat disk image file. hdiutil unflatten "${DMG_RELEASE_SIGNED}" Rez -a "${BUILD_TOOLS_DIR}/software_license.r" -o "${DMG_RELEASE_SIGNED}" hdiutil flatten "${DMG_RELEASE_SIGNED}" The completed disk image is then signed and uploaded for notarization: codesign --sign "${DMG_SIGN_IDENTITY}" --verbose=3 "${DMG_RELEASE_SIGNED}" xcrun altool --notarize-app --primary-bundle-id "${PRIMARY_BUNDLE_IDENTIFIER}" -f "${DMG_RELEASE_SIGNED}" ... After noterization is complete, the signed image is stapled and verified: cp "${DMG_RELEASE_SIGNED}" "${DMG_RELEASE_FINAL}" stapler staple --verbose "${DMG_RELEASE_FINAL}" spctl --assess --type open --context context:primary-signature --verbose=2 "${DMG_RELEASE_FINAL}" This all used to work just fine, until the flatten and unflatten commands went away. Since the hdiutil udifrez -rsrcfork option is either unimplemted or broken, we tried using the hdiutil udifrez -xml option. Since the XML file for this command isn't documented anywhere, we created one using the udifderez command using the license resources from a previous release. Armed with this XML file, I replaced the (unflatten/Rez/flatten) license attachment step with this: hdiutil udifrez -xml "${BUILD_TOOLS_DIR}/software_license.xml" '' "${DMG_RELEASE_SIGNED}"  (note the extra, blank, argument because there's apparently another bug—or documentation failure—in udifrez, and if omitted the command fails) Everything proceeds swimmingly, through the signing and stapling, except the resulting file is broken. When you open the disk image the SLA appears. Agree to the license, you're presented with a failure dialog: 									Warning The following disk images couldn't be opened Image							Reason release_2.2.3.dmg	image data corrupt If I leave out the single hdiutil udifrez -xml ... step, everything works (except that there's no attached license agreement). I can't attach the license before the disk image is compressed, because it's the wrong format. I can't attach the license after the disk image is signed or stapled, for obvious reasons. So we're stuck. I can't find any way of attaching a SLA to a signed and notarized distribution disk image, using the current set of tools, without breaking the disk image.

Before Big Sur, there was a property list at /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist that contained a list of all of the standard files/locations that Time Machine would exclude from a backup. That file seems to have disappeared and I have been unable to find an equivalent. Furthermore, the tmutil isexcluded (i.e. NSURLIsExcludedFromBackupKey/CSBackupIsItemExcluded) does not reliably report these locations as excluded. So is there still a publicly accessible way of discovering the standard locations excluded by Time Machine?