User Profile

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.

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.

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.)