So I'm not sure if you want to know how to set up an in-memory store, or if you want to know why we would ever set up an in-memory store.

The first question is easier, at least in theory. Make a custom subclass of UIManagedDocument and override persistentStoreTypeForFileType:. Have it return NSInMemoryStoreType.

Now, I haven't actually tested this. And I wonder what role the fileURL property and the URL arguments in initWithFileURL: and saveToURL:forSaveOperation:completionHandler: play. I assume we can just pass in nil for the arguments--but that we still have to call saveToURL:forSaveOperation:completionHandler: to set up the in-memory store--but I could be wrong.

The second question is a bit tougher. I think in-memory stores may make more sense on the Mac side, where we have more ram and creating an in-memory store working copy may provide improved performance. However, even in iOS there may be some cases where we would want to use Core Data to validate and manage the lifecycle of our objects, but didn't want it to save the data for us. For example, if we don't ever save the data (which seems unlikely), or if we need to implement our own custom serialization. This might be particularly useful if we want to let the user save the data in different ways, but still want to provide a unified interface to our data.

One example might be if we wanted to read and write the data to and from a web service. Of course, we could also build custom atomic store to explicitly do this for us--but I don't think many developers (if any) are writing custom stores yet.

-Rich-