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?

Does anyone know if Apple has posted a technical comparison or summary of the differences between Intel and ARM processor capabilities/limitations? Specifically, I have code that de-serializes a custom stream of data. Right now, this can result in non-word-aligned fetches and stores of word and double word values. 68K CPUs used to choke on this, but all modern 64-bit Intel processors handle it just fine. What about ARM? Also curious to know if 64-bit fetches and stores are always atomic.

Subject says it all: where do I download the Mojave installer? I've tried to be good about capturing and saving installers for each OS, since Apple is now in the annoying habit of hiding installers for older OSes, but I seem to have lost my copy of the macOS 10.15 installer. I searched developer.apple.com, and the developer download area, and the app stores, and everywhere else I could think of and ... nothing.

I have an app that recently started building/running under Catalina and its simple state preservation/restoration code has suddenly stopped working.The code archives an array of custom objects into an NSData blob that gets saved somewhere. Later, that data is decoded back into the array which is used to restore the state.Distilling the problem, I've created the following example:#define SECURE 1 #if !SECURE // The unsecure example UnsecureObject* bonnie = [UnsecureObject new]; bonnie.property = @"Bonnie Elizabeth Parker"; UnsecureObject* clyde = [UnsecureObject new]; clyde.property = @"Clyde Champion Barrow"; NSArray<unsecureobject*>* rootObject = @[ bonnie, clyde ]; #endif #if SECURE // Secure example SecureObject* francis = [SecureObject new]; francis.property = @"Francis Crick"; SecureObject* james = [SecureObject new]; james.property = @" James Watson"; NSArray<secureobject*>* rootObject = @[ francis, james ]; #endif // Encode an array of objects into a data blob NSError* error = nil; NSData* data = [NSKeyedArchiver archivedDataWithRootObject:rootObject requiringSecureCoding:SECURE error:&error]; if (error!=nil) @throw error; // Decode the data back into an array NSArray* roundTrip = [NSKeyedUnarchiver unarchivedObjectOfClass:NSArray.class fromData:data error:&error]; if (error!=nil) @throw error;This works fine in Mojave. In Catalina, the unarchivedObjectOfClass method results in an error:(lldb) po error Error Domain=NSCocoaErrorDomain Code=4864 "value for key 'NS.objects' was of unexpected class 'SecureObject'. Allowed classes are '{( NSArray )}'." UserInfo={NSDebugDescription=value for key 'NS.objects' was of unexpected class 'SecureObject'. Allowed classes are '{( NSArray )}'.}I thought it might be a new "secure coding" requirement, but as you can see the problem occurs regardless of whether the objects in the graph support secure coding or note.Any suggestions?(And BTW, where did the documentation for secure coding go? I distinctly remember, years ago, an extensive guide on secure coding describing exactly how to use it and its coding requirements. Now, no matter what I search for, I can only find the legacy "archive and serialization" guide that makes no mention of NSSecureCoding. And, of course, the NSSecureCoding API page explains almost nothing.)