Great points. I agree with some of them, but disagree with others. > The structure of the API encourages passing the entire context around everywhere, which ba

Great points. I agree with some of them, but disagree with others. > The structure of the API encourages passing the entire context around everywhere, which basically turns all of these objects into global variables. I don't see it that way. In many cases, you don't need to pass around a context, you can directly pass the objects that you need to work on. And even when you do pass the context, its not as if you go through its -registeredObjects. You would usually get your objects using a fetch request -- how is it different from fetching your objects directly using SELECT over a db connection? > For example, ObjectiveRecord[1] adds class methods for looking up objects using a predicate. Modularity? Separation of concerns? Perish the thought. I really don't see how this is bad for modularity or separation of concerns? Can you please elaborate? > At the large scale, you don't want to load everything into memory so you need a better scheme, but then you need something like SQLite so you can avoid the slowness and gain more control. But Core Data does support SQLite as a backend, and it allows you to easily load only a subset of your data. Just create a fetch request with the appropriate predicate and you can work with just the objects you need. One of the things that is definitely slow though is if you want to mass update or delete a significant number of your objects. In that case you would have to load all the objects in memory and update or delete them one by one, which can be a pain if you need to do this a lot (whereas with SQLite a simple UPDATE or DELETE statement would have sufficed). Another reason for slowness historically has been that if you use two different contexts (say for multi-threading reasons), then in order to transfer updated information from one context to another you had to first save the information to disk, and only then could you fetch the updated info on the other context. The alternative to this is to lock the context and objects explicitly which has its own problems. However, with the introduction of parent contexts and new concurrency types in iOS 5, it is not a problem anymore. If a context has its parent context set, then when it saves its changes, they won't got to disk -- the changes are only registered in the parent context. Core Data is not perfect at all, but I don't think it is completely unusable either.