I was going to give a point-by-point on why this article is just plain wrong, but then I came across this gem:
> It’s a corner case. Corner cases exist, and if you’re in one, don’t use Core Data.
The problem here with Core Data is that it's not a piecemeal solution. You either use it or you don't, so when you run into something the Core Data doesn't do properly (like bulk delete, or bulk anything really), you're stuck.
I'm appalled by this article, as explained in my comment not two minutes ago. I wonder if this is just a terrible article of the mindset of a whole industry. I have first hand experience with iOS developers doing exactly what the article describes. Is XCode/Cocoa development the next PHP?
Wouldn't Objective-C's "library management" be the same as C's? Wouldn't you include the source files in your project, add the header files to the proper path somewhere and be done with it? People developing software in C and C++ have been doing this for decades without much of a problem, I can't understand how all of a sudden this is a "dependency nightmare".
Recommending to roll your own solution for every new problem goes directly against the last 20 years of evolution in the software development industry. It's like the other conclusion some iOS developers seem to arrive to: "you should debug by logging because XCode's debugger sucks". Another 20 year regression.
I'm just confused. Is XCode singlehandedly messing up the minds of a whole generation of developers?
> Is XCode singlehandedly [messing] up the minds of a whole generation of developers?
No. I think the situation is more that there are a LOT of people jumping into iOS development without a programming background (let alone a strong background in Objective-C).
Core Data works great in apps where you're dealing with a limited number of entities and displaying them in table views full of repeated cells (NSFetchedResultsController FTW!).
Once your entity graph gets fairly complex, however, things start to fall apart rather quickly. Child contexts? In theory, they're awesome. But we've ran into a number of nasty cases where objects were getting over-released on cleanup of the context. Error messages are less than helpful, merging model changes is a nightmare, batch deletion sucks, splitting data into multiple stores is way too complex - the list goes on.
The biggest problem I have with Core Data is that there is just not enough "best practices"-type documentation out there. The WWDC videos and everything else from Apple do a good job of getting people to get in the pool. But then you have a pool full of people who don't know how to swim and are now drowning.
Two weeks ago, I rewrote a third party library, because it didn't account for the fact that the app itself might be using Core Data as well (shock!). Among many other things, it was grabbing any model files it could find in the whole app bundle instead of specifically searching for its own, causing migration issues.
The sooner Apple admits that Core Data is a mess and moves on, the better off the ecosystem will be.
> Child contexts? In theory, they're awesome. But we've ran into a number of nasty cases where objects were getting over-released on cleanup of the context.
This is a known ARC bug. Implement -dealloc and nil out the managed object ivar (or property) and MOC ivar (or property), in that order.
> The biggest problem I have with Core Data is that there is just not enough "best practices"-type documentation out there.
This halfway-in,halfway-out implementation is what frustrates me. Those people who are drowning get the same answer "Well, Core Data isn't a relational DB so you shouldn't treat it like that." But yet all of Apple's nomenclature screams RDBMS.
7 comments
[ 2.9 ms ] story [ 27.5 ms ] thread> It’s a corner case. Corner cases exist, and if you’re in one, don’t use Core Data.
The problem here with Core Data is that it's not a piecemeal solution. You either use it or you don't, so when you run into something the Core Data doesn't do properly (like bulk delete, or bulk anything really), you're stuck.
Recommending to roll your own solution for every new problem goes directly against the last 20 years of evolution in the software development industry. It's like the other conclusion some iOS developers seem to arrive to: "you should debug by logging because XCode's debugger sucks". Another 20 year regression.
I'm just confused. Is XCode singlehandedly messing up the minds of a whole generation of developers?
EDIT: removed profanity.
No. I think the situation is more that there are a LOT of people jumping into iOS development without a programming background (let alone a strong background in Objective-C).
That's a pretty broad stroke (that I'm, admittedly, unfairly singling out).
Core Data works great in apps where you're dealing with a limited number of entities and displaying them in table views full of repeated cells (NSFetchedResultsController FTW!).
Once your entity graph gets fairly complex, however, things start to fall apart rather quickly. Child contexts? In theory, they're awesome. But we've ran into a number of nasty cases where objects were getting over-released on cleanup of the context. Error messages are less than helpful, merging model changes is a nightmare, batch deletion sucks, splitting data into multiple stores is way too complex - the list goes on.
The biggest problem I have with Core Data is that there is just not enough "best practices"-type documentation out there. The WWDC videos and everything else from Apple do a good job of getting people to get in the pool. But then you have a pool full of people who don't know how to swim and are now drowning.
Two weeks ago, I rewrote a third party library, because it didn't account for the fact that the app itself might be using Core Data as well (shock!). Among many other things, it was grabbing any model files it could find in the whole app bundle instead of specifically searching for its own, causing migration issues.
The sooner Apple admits that Core Data is a mess and moves on, the better off the ecosystem will be.
This is a known ARC bug. Implement -dealloc and nil out the managed object ivar (or property) and MOC ivar (or property), in that order.
> The biggest problem I have with Core Data is that there is just not enough "best practices"-type documentation out there.
I wholeheartedly agree.