Bill Bumgarner, on CoreData's design goals:
There are actually four different specific technical issues that have been discussed concretely or alluded to:
(1) object graph management -- managing a bunch of objects with relatively complex connectivity between, including ability to do validation, undo tracking, user interface bindings, change propagation, grouping/filtering/organizing of subgraphs, etc...
(2) persistency of the object graph; could be to memory, to permanent storage atomically, or to permanent storage incrementally.
(3) client/server style interaction with a remote store for pushing/pulling bits of object graph to some server with multi-user access that includes ability to do conflict management, change integration, stale data detection, etc...
(4) mapping between the object graph and a schema that is defined outside of the framework that offers (1), (2), and (3).
Currently, Cocoa has (1) and (2) in the form of Core Data. Cocoa has that in spades. Having worked with many different object persistency management layers over the years (including designing & implementing a few), I'm pretty sure Cocoa has the best quality (1) that isn't a highly specific solution within a limited problem domain.
(1) is also one of the most difficult problems to solve, especially when aiming for a general purpose solution widely applicable to many different styles of applications.