Your suggestion to look at the raw .plist XML was interesting. I also tried this and manually keyed in a Multi-Value option and it appears to work now? I slowly copy-pasted from an older plist to the new one and was able to get them all working. Unclear if it is a legacy project issue in Xcode or something else, but I can confirm that I was able to get multi-values working by editing the raw file.

Sorry to hear this is also a problem with no multi-item defaults. I have submitted to FB15267454.

Although I cannot be 100% sure this is the or a potential cause, I can reproduce this broken behavior. If you make a new project in Xcode and add a settings bundle, it will work 'out of the box' - and you'll see the sample settings populated in the template. They have String, Checkbox, and Slider. If however you add a multi-value option, the settings bundle will disappear. If you remove the multi-value option, clean the build folder, and redeploy, you should see the sample setting controls again. So this is possibly either a change in how multi-values are supposed to work or a bug. I guess the workaround would be to not have multi-value options in the short term but that seems a little user-unfriendly for a shipping app.

This is the same behavior I am seeing with an app that has worked fine since iOS 14.

I have a similar RealityView crash that originally I was attributing to the # of objects but now I am wondering if this is an issue of programmatically loading / adding a bunch of entities asynchronously. I will have to try what you have done and see if it works better.

So this is probably a bug. Here's two functions that should produce mostly identical results (and at a minimum enable highlighting on any entity that has 'park' in the name): extension Entity { func applyComponentsRecursively() { if self.name.contains("_8_") || self.name.contains("_9_") || // ... additional fifteen clauses ... self.name.contains("_26_") || self.name.contains("_30_") || self.name.contains("parking") || self.name.contains("retail") || self.name.contains("hotel") { self.components.set(HoverEffectComponent()) } // Recursive call for all child entities for child in self.children { child.applyComponentsRecursively() } } } extension Entity { func applyComponentsRecursively() { // Check if the entity's name contains "park" if self.name.contains("park") { self.components.set(HoverEffectComponent()) // Recursive call for all child entities for child in self.children { child.applyComponentsRecursively() } } } Most of the components in the USDZ have names that work with both the first and second if-thens: 'park_1_1','park_9_4' etc. But the top one works, and the bottom one doesn't (I've seen it either highlight every entity or no entity). I don't have time to debug this further but if I can find an easily reproducible case I'll file a feedback item on this.

One small bit of extra info- there are other entities with children in the scene - these don’t highlight, as I would expect.

So if I use .none for ArchiveCompression I do not see the crashing behavior: guard let compressStream = ArchiveByteStream.compressionStream( using: .none, writingTo: writeFileStream) else { throw DocumentError.compressionStreamCreationFailed } // .lzfse, .zlib, .lzma, .lz4 all sporadically fail Is there any compression type that reliably works with a UIDocument uploaded to iCloud?

In looking at this problem, I have determined that the file I have that is the generated archive, the uploaded archive, and the downloaded archive are all the same size. I also was able to determine that the standard Archive Utility can successfully decompress a 'good' archive that doesn't crash the app, and won't decompress a 'bad' archive. Lastly I am compressing and archiving the same data each time, so now I am wondering if there is a nuance in the compression I am missing.

This is great, thanks so much. It will solve my immediate needs and points me to the next right thing to get up to speed on (Actors in general, but this is the second time I have specifically heard about the 'main Actor' so I've got to brush up there).

It would be great to have even the most bare-bone sample code that illustrates this concept for the CLI template. The build setting for the Info.plist is findable and thanks so far for the pointer to that, but it's only the first step. For example, if you take the default @Model from the app template and want to just inspect the context: import Foundation import SwiftData @Model final class Item { var timestamp: Date = Date() init(timestamp: Date) { self.timestamp = timestamp } } let bundleIdentifier = Bundle.main.bundleIdentifier let container = try ModelContainer(for: Item.self) Task { let context = await container.mainContext print(context.autosaveEnabled) // or actually something useful from the ModelContext like real data } This doesn't compile (and is likely architected horribly) and while I'm sure the ModelConfiguration documentation is the right place to start, it's too opaque to string together. Understandable that not everyone wants to use SwiftData this way, but it seems odd that if I want to propagate some test data to a container I have to make up a UI-based app where I don't want the UI.

Typo - ... the expectation is it scrolls inside it's container and has no impact on the parent controller "A"

Unintended typo above. ... the expectation is it scrolls inside it's container (B) and has no impact on the parent controller (A).

I feel like the answer here is proper understanding of the Fetched Properties used in the CoreDataFetchedProperty example, but it's not completely clear in the example.

Just in case people come across this, if you choose a different quality of service when setting up the DispatchQueue in transcribe(), performance is much improved. I set it to .default and it then happily translated over the Internet at near real time on an iPhone 12. It's unclear if this would be the optimal choice in a production application, but for better understanding the transcription capabilities of iOS it seems to be a better choice than .background.