Since iOS 16.4, a new exception is raised when "the number of sections and/or items returned by the data source before and/or after performing the batch updates are inconsistent with the updates". This post (iOS 16.4.1 - UICollectionViewController crashes) goes into some more detail, with a response from an Apple engineer, but doesn't explain exactly how this mechanism should/could work with NSFetchedResultsController. When using NSFetchedResultsController, its contents could contain unfetched/faulted core data objects in the tens of thousands. As the NSArray returned by NSFetchedResultsController is a reference type, the developer has no control over the point in time it is updated. Further, there doesn't seem to be a way to copy NSFetchedResultsSectionInfo without triggering a deep copy. Therefore, if a developer wishes to play nicely with the UICollectionView batch updates mechanism they are forced to make a deep copy of the results which means faulting a bunch of potentially unused objects and defeating a primary benefit of NSFetchedResultsController. Is there a more performance optimised way of getting UICollectionView batch updates and NSFetchedResultsController to play nicely?

I'm trying to use .scrollEdgeAppearance to effect a similar style to that used in the Reminders app for the 'new reminder' popover on iOS. Here, we can see that when we're at the 'scroll edge' the navigation bar and shadow are transparent. And when the user scrolls they go back to the regular opaque/blur effect style. They don't use large titles. However, when trying to do something similar using .scrollEdgeAppearance I can't seem to replicate the effect. This is strange as it seems to be used quite liberally by Apple. e.g. in the aforementioned Reminders app, and also when a search controller has been added to a view controller's navigation item. Do we really need to scrollViewDidScroll(_:) this?

I'd like to understand the most robust way to record audio to disk using AVAudioNodes installTap(onBus:bufferSize:format:block:) method. Currently, I'm dispatching out the buffers I receive in my AVAudioNodeTapBlock to a serial dispatch queue then writing to disk using some Audio Toolbox methods, but my concern is that if I hold on to the buffer provided in the AVAudioNodeTapBlock for too long (due to disk I/O for example), I'll end up getting issues. What I'm considering is creating my own larger pool of preallocated AVAudioPCMBuffers (a few seconds worth) and copying across the data from the buffer provided by the tap into one of the buffers from this larger pool in the AVAudioNodeTapBlock directly (no dispatch queue). Is there a simpler way of handling this, or does this sound like the best route?

I'm using Core Data and CloudKit together, and so far everything looks great. But one thing that I haven't been able to find much literature on is the interaction between NSPersistentCloudKitContainer and Persistent History Tracking. My assumption is that NSPersistentCloudKitContainer leans on Persistent History Tracking to execute its responsibilities. So if we're using Persistent History Tracking elsewhere – maybe to update an app extension using a process similar to the one outlined at https://www.avanderlee.com/swift/persistent-history-tracking-core-data/ – there's a risk of interrupting that process. Especially with regards to executing a NSPersistentHistoryChangeRequest.deleteHistory(before:) request. Would this run the risk of deleting history that NSPersistentCloudKitContainer requires to perform its roles? Is there a way to synchronise these various responsibilities?