There was a section in the talk about how we can break down migration into smaller changes, and that we have an opportunity to run app-specific code in between migration steps. However the talk didn't touch on how can can achieve this, besides a single sentence, which doesn't give enough detail at least for me to figure out how to do it. Intuitively, an event loop could be built that opens the persistent store with the lightweight migration options set and iteratively steps through each unprocessed model in a serial order, and Core Data will migrate the store. Given the automatic nature of the lightweight migrations, especially in the case where we're using NSPersistentCoordinator, doesn't the automatic system just zoom through all of the migrations from model A --> A' --> A'' -> B? How to we make it stop so we can execute our own app code? Thanks!

My app doesn’t use the local network but it’s presenting this permission prompt. Is there a symbolic breakpoint or another way to find out what call is producing the prompt? I’m assuming it’s buried in one of my third party libraries but need to track down which one.

Are there any recommendations for composing Operations into larger Operations? A couple of example use cases follow: Let's say my app has an operation queue used for sync tasks. I have an Operation subclass for fetching all users, but that's a paged API, so it defines another Operation subclass for fetching one page of users and upserting them into the local database. To date, I've been adding the "fetch all users" operation to a global "sync" OperationQueue in my app, and then creating a new operation queue within that operation (as a property of the Operation subclass) to which I add each of the page operations. As a more complicated example, let's say I have an image processing pipeline for running images across an ML model. The ML inference is the bottleneck of the pipeline so I want to make sure that the ML engine (CoreML or Tensorflow or whatever) is always busy. This means that any pre-processing steps like loading the image, resizing and cropping it, and preparing it to send to the model should be in a separate Operation subclass from the actual inference (or each of those pre-processing steps could be in their own Operations). This approach, however, raises some issues in that if the pre-processing steps are faster than the inference step, I end up with way too many pre-processed images in memory waiting to be run through inference. (Perhaps this use case isn't an ideal use for Operations? 🤷‍♂️)

It's very clear from the session video how we can leverage cell configurations for information that is available synchronously, like titles for rows and locally-available images. Are there recommendations for how to configure cells for asynchronously-loaded stuff, for example fetching a user's profile picture from the internet? In the old style, we could subclass UITableViewCell and add an imageURL property, and then start loading the image immediately, with the ability to cancel the network request when prepareForReuse was called. I can imagine some ways to put this logic into the data source, but I think we'd have to do index-path accounting (or something) to keep track of which network request belongs to which cell, in order to deal with updating the cell's configuration on successful completion, as well as cancelling if the cell is going to be reused before loading completes. Are there better ways to approach this? Thanks!