What do the equatable and hashable methods of your ITEM look like?

Well, I thought I saw something, but maybe not... I do want to call something out, though: private let identifier = UUID() If you are ever reconstructing these items more than once, the diffableDatasource will see them as new items EVERY time. It could be wise to use something naturally unique to your "item" like the URL, for example. Also because your equatable looks like: static func == (lhs: AlbumItem, rhs: AlbumItem) -> Bool {     return lhs.identifier == rhs.identifier   } DiffableDatasource will not re-create a cell if cell if a property of the item changes. One way I think about it is this: -HashID identifies the existence of a cell in the collectionView." -If HashID and Equals match between snapshots, the collectionView will visually keep that cell consistent. For example, you'll see move animation if the item's index changes. -If HashID matches, but equality does not, then diffableDatasource will dequeue a new cell and call the configuration method. (In iOS 15 you can also nominate Items for a reconfigure instead of a full-on dequeuing.) In your case, for short term debugging, I would try using the URL as the "unique identifier" of your item. Long term, you may also need to incorporate a "modification date" into the equality method because a URL's contents can change and require a redraw the cell.

This doesn't seem resolved in beta 3 either... Fruta has the same "bug" too. FB9330740

Seeing the same thing. Thank you for posting the code example.

Not sure what the "right answer" is, but This is how I set mine up. let url = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "APPGROUPID")?.appendingPathComponent("NAME.sqlite")         let description = NSPersistentStoreDescription(url: url)         description.shouldMigrateStoreAutomatically = true         description.shouldInferMappingModelAutomatically = false // yours should probably be true if you're not manually migrating between schema versions         description.shouldAddStoreAsynchronously = true         description.isReadOnly = false         let options = NSPersistentCloudKitContainerOptions(containerIdentifier: "MY IDENTIFIER")         description.cloudKitContainerOptions = options         return description

Update: It appears that the main reason I'm getting this error is because one of my dependencies is failing to clone. This dependency is located in a private repository also hosted on GitHub, and I've granted authorization to this additional repo. Could this be because Xcode-Cloud is trying to look in keychain for my normal git authentication info (username and token), but it's not available on the host?

Yeah, this is a known bug where sidebars styling is not fully supported in SwiftUI catalyst. See this sample project by STS that has work around: https://github.com/steventroughtonsmith/CatalystSwiftUISidebar?ref=swiftobc.com

Oh man, this could be almost anything. Are you using storyboards or Xib files? Are all your IBOutlets and IBActions connected? Does your app run if you remove some components, or try rendering with zero rows? Is your UITableViewCell properly registered on the table before you try to dequeue it?

Well, I'm a dork. The thing that I expected to see in my ARWorldMap was an AnchorEntity, not an ARAnchor. AnchorEntities, while containing an ARAnchor internally, may not actually be getting persisted to the ARWorldMap? It's something that I will be investigating more tonight, but I wanted to add this additional information.

Sending a single image works, so I’m guessing it’s an undocumented or overlooked limitation.

Does this impact all AnchorEntities created with an ARAnchor? What other behaviors have you seen with this?

Hey, me too! My guess is it's a passing validation bug with the beta. Could be worth submitting a feedback for, though.

I've had problems where the project had types that matched SwiftUI types and the preview would never really finish loading. Things like "Coordinator" "View" or "Button", despite being in the namespace of your project and not the swiftUI namespace, seem to confuse the preview compiler.

Discovered using a negative spacing in the VStack+HStack technique that matches the relative shape inset works well enough: HStack(spacing: -3) {                     VStack(spacing: -3) {                         ContainerRelativeShape()                             .inset(by: 3)                             .fill(.yellow)                         ContainerRelativeShape()                             .inset(by: 3)                             .fill(.yellow)                     }                     VStack(spacing: -3) {                         ContainerRelativeShape()                             .inset(by: 3)                             .fill(.yellow)                         ContainerRelativeShape()                             .inset(by: 3)                             .fill(.yellow)                     }                 }

Have you gotten any of this stuff to work for you? I started experimenting with accepting drops from outside my app, and it's been brick wall after brick wall.