Core Data manages object lifetimes the same way the rest of Cocoa manages object lifetimes: NSManagedObject instances in a managed object context are retained in memory as long as the managed object context or any other object retains ownership of them (via -[NSObject retain]
. By default, the NSManagedObjectContext
does not retain instances, so they are released as soon as any other owners (i.e. your NSFetchedResultsController
instances or other instances in your program) release them. You can change this default behavior of the managed object context to retain instances, but you rarely want to. The managed object context has to retain instances that are updated until the next save. There's no way to preserve these changes except in the object instance until the context is saved. So, to minimize memory usage of Core Data objects, follow the standard rules: release them as soon as you can. If you find that your context memory usage is growing (use Instruments' Core Data instruments to track this), save the context more frequently if you are updating instances and hence keeping them alive in the context until the next save even if you've otherwise released them.
Using NSFetchedResultsController
makes all of this easier. In fact, the reason NSFetchedResultsController
exists at all is to make batch fetching in a low memory environment (like the iPhone) easier for the programmer.
As Louis mentioned, the NSPersistentStoreCoordinator
maintains a row cache to cache instance data in memory instead of having to go back to disk when an object is faulted into the managed object context. This is a Core Data implementation detail, however (though cache misses are a performance hit; you can track cache misses in Instruments). Core Data manages the cache memory and you shouldn't have to worry about it.