As is possible with beta changes, the sample code no longer compiles. One fix was easy: a button style for prominence was explicitly added in beta 5 -- now it is Button { canvas.startSharing() } label: { Image(systemName: "person.2.fill") } .buttonStyle(.borderedProminent) The other fix I am less sure of: the type alias for Task.Handle was deprecated, and if I use just Task it compiles, but now SharePlay won't start the Group Activity - it instead shows a toast where you have to "Choose Content to Use SharePlay". It's unclear if this is a side effect of the Task change, or if there is an undocumented change in GroupActivities. Has anyone succeeded in running this code lately? Thanks.

Adding some basic print debugging into the recognitionHandler I can see that I was just exiting out of the view too soon - when results are done over the Internet, it just takes a long while to get a result! So if the user ends the scrum too soon, it looks like you lose anything that did not get translated.

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.

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.

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

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

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.

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

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.

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?

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

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.

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.

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

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.