In addition, if the collection contains collections, you must include the classes for those objects as well. Since this was an array of dictionaries, some containing set objects, this turned out to be pretty annoying.Furthermore, the same rule applies to decoding individual secure objects using -decodeObjectOfClass:forKey: too.So it would all seem to be working now, but gosh it would have been nice if this was documented somewhere.

Sorry for the mix-up on the number. Where do you find these links?

This link doesn't work. The link jumps to the App Store, which then opens Software Update, which then tells me the update isn't available.

Thank you so much for this information. I was using alignment attributes with my pointers and structs, but wanted to make sure that ARM64 would cooperate. I regularly use atomics (atomic_store, atomic_exchange, and so on), but I have a few cases where the code checks a pointer/value and isn't at all concerned about concurrency or race conditions ... but I *am* very concerned about loading only half a pointer/value ;) So that's good to know. Thanks again for the great support.

Thank you all for the excellent information. I knew about "dylib insertion" threats, but our application is signed (DeveloperID), notarized, and stapled, so I couldn't figure out why it wouldn't be trusted. It does use Hardened Runtime, but ultimately that wasn't the problem. As usual, it was our fault. The ancient (circa OS X 10.4) code that installs the copy of the helper app in the Application Support folder was changing some of the access flags on the resource files. This, in turn, invalidated the app package. But until we added Dylibs to the package, this went unnoticed for years. Once we figured out what was going on, the solution was to simply replace the copy hack with a single, modern, copy folder call and now everything works as expected. The installed helper app passes codesign validation, and the Swift libraries load even when run as root. Thanks again, and apologies for the noise...

Similar situation here. New iPhone 13 Pro running iOS 15.4.1. I have a CUPLTag temperature and humidity logger that uses NFC to download the sample data. Before 15.4 update it worked every time. Afterwards, it rarely works at all. In fact, I only think I've gotten it to work this way twice since the update. Yet I can launch the NFC Tools, tap "Read", then move it near the tag and it reads immediately, every time.

I'm running into the same issue. I've looked through all of the NSURL resource keys and none of them will return the size of the original (yet to be downloaded) file. This is frustrating because the Finder seems to know what the size is, and I'd really like to know where it gets that information.

After a little more investigation, I did find a hack. It turns out that .iCloud files are actually property list files, and you can read them using the low-level file API. For example, I have a file named 02.data on my iCloud drive that's 134MB. It's placeholder file (.02.data.icloud) contains this: { NSURLFileResourceTypeKey = NSURLFileResourceTypeRegular; NSURLFileSizeKey = 134210392; NSURLNameKey = "02.data"; } Which is exactly the info I was looking for! No let's hope this doesn't change with the next OS! :P