Thanks, @numist, for your response. Ideally, I'd use the NSDiffableDataSourceSnapshot API but it has a couple of limitations that mean it won't work for my use case: It's a NSDiffableDataSourceSnapshot and not a NSDiffableDataSourceSectionSnapshot so it can't be composed very well. It tightly couples Core Data to the view which isn't ideal for those of us who like to modularise our code. Ideally NSDiffableDataSource(Section)Snapshot would by lazily mappable which would perhaps go some ways to facilitating de-coupling Core Data from the View. For the adapter example, if I get time I'll put one together but it's pretty easy to see for your self: Within a NSFetchedResultsControllerDelegate, add/remove some items from a section and then check the section counts in controllerWillChangeContent(_:) (storing the sections within the delegate for later) then check the stored section counts again in controllerDidChangeContent(_:). For NSFetchedResultsSectionInfo to be usable as a collection view data source, you would expect the section counts of the sections stored in controllerWillChangeContent(_:) to stay constant. However, by controllerDidChangeContent(_:) the section counts have changed. In other words, there's some 'spooky action at a distance' occurring which means NSFetchedResultsSectionInfo can't effectively be stored for use as part of a UICollectionViewDataSource and performBatchUpdates specifically. Reproducible code: final class SomeController: NSObject, NSFetchedResultsControllerDelegate { private var willChangeSections: [NSFetchedResultsSectionInfo]? func controllerWillChangeContent( _ controller: NSFetchedResultsController<NSFetchRequestResult> ) { print(#function) if let sections = controller.sections { print("sections will change: \(ObjectIdentifier(sections as NSArray))") for (i, section) in sections.enumerated() { guard let objects = section.objects else { return } print("\t\(ObjectIdentifier(objects as NSArray)) - section \(i) count: \(section.numberOfObjects)") } } self.willChangeSections = controller.sections } func controllerDidChangeContent( _ controller: NSFetchedResultsController<NSFetchRequestResult> ) { print(#function) if let oldSections = willChangeSections { print("sections did change (old): \(ObjectIdentifier(oldSections as NSArray))") for (i, section) in oldSections.enumerated() { guard let objects = section.objects else { return } print("\t\(ObjectIdentifier(objects as NSArray)) - section \(i) count: \(section.numberOfObjects)") } } if let newSections = controller.sections { print("sections did change (new): \(ObjectIdentifier(newSections as NSArray))") for (i, section) in newSections.enumerated() { guard let objects = section.objects else { return } print("\t\(ObjectIdentifier(objects as NSArray)) - section \(i) count: \(section.numberOfObjects)") } } } } // EXPECTED: // controllerWillChangeContent(_:) // sections will change: ObjectIdentifier(0x0000600001019020) // ObjectIdentifier(0x0000600001347c00) - section 0 count: 10 // // controllerDidChangeContent(_:) // sections did change (old): ObjectIdentifier(0x00006000010187a0) // ObjectIdentifier(0x0000600001347aa0) - section 0 count: 10 // <--- count the same as in willChange ✅ // sections did change (new): ObjectIdentifier(0x0000600001018660) // ObjectIdentifier(0x0000600001347b20) - section 0 count: 11 // ACTUAL: // controllerWillChangeContent(_:) // sections will change: ObjectIdentifier(0x0000600001019020) // ObjectIdentifier(0x0000600001347c00) - section 0 count: 10 // // controllerDidChangeContent(_:) // sections did change (old): ObjectIdentifier(0x00006000010187a0) // ObjectIdentifier(0x0000600001347aa0) - section 0 count: 11 // <--- count has updated since willChange ❌ // sections did change (new): ObjectIdentifier(0x0000600001018660) // ObjectIdentifier(0x0000600001347b20) - section 0 count: 11

Running some tests, it looks like installTap(onBus:bufferSize:format:block:) manages its own buffer pool and will automatically create new buffers if you need to hold onto them for some duration. So no need to create your own buffer pool.

AFAICT it's actually just a one step process. You can add to the target via General -> Target(s) -> Frameworks, Libraries and Embedded Content, and you're good to go. I don't think you need the add via General -> Project -> Package Dependencies -> "+" step at all. Perhaps this is for local packages that have a local git repo but aren't part of the existing project.

Wow – that must have been incredibly frustrating. I've contacted support, also. This feature should be disabled in its current state. I'm also getting reports that existing users who update – not just new users – are receiving the Icon treatment under test. With your results, It's crystal clear to see that you're having daily fluctuations on the graph you share. The chance that the Treatment and Baseline would have the exact same fluctuations day-to-day is next to impossible. Clearly, either the value displayed for either the Baseline or Treatment under test is wrong and they're comparing either the baseline-to-baseline, or treatment-to-treatment. I'm curious to hear Apple's justification that this 'works as expected'.

Did you get an update on this? My baseline and update are showing as identical on Day One – which seems pretty unlikely when the difference is calculated with fraction of a percent precision. Looking at your results, I'd say it's even more unlikely as that would require identical fluctuations each day. What seems strange is that the table only shows a line for the test treatment, not the baseline treatment. If I were to guess, the dashboard is calculating the difference based on that same line item which, of course, will always show a zero difference.

Right, so it's iOS 15 only – that would explain it. Very good to know. I'm targeting iOS 14 so I'll have to figure some workaround for pre iOS 15. Thanks for your help.