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'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?