Core Data Caveat #1

Fair warning, this is a post about coding. Specifically, Core Data. Yes, after years of holding out and getting by with the simplicity and comfort of NSUserDefaults, I jumped in just like I did with iOS development in the first place: I bought a book and starting monkeying around.

Core Data is a funny thing, conceptually. It’s like a layer between you and your data storage that takes a little more work to understand and implement than most Apple frameworks do. You’re much better off designing an app around it than working it in later, and it can be inflexible if your needs change.

There’s something about it, though, that really just feels right. I’ve literally spent years working my way around it, cooking up complex caching schemes and fine-tuning my methods to an almost unreasonable extent. I just replaced 85 lines of code with 10—that’s proof right there that I should’ve done this from the start.

To be honest, though, I couldn’t have appreciated what Core Data does without having gone through all of that first. I respect it, I understand the problems it solves, and I embrace it.

Uh oh, not so fast. There are some peculiarities that anyone getting into this stuff should really know about, so I’m doing my part to highlight them. Today: NSOrderedSet.

Check the “ordered” button for a relationship and you’ll be using NSOrderedSet. It sounds easy enough, and Core Data generates a nice convenience method for you so you can add things later. If your relationship is to something called “item”, then you’ll get addItemsObject:(Item *)value which all seems reasonable, right? It doesn’t work. Not at all. It crashes your app and makes children cry. Instead, use one of the workarounds described here.

Hey, someone should tell Apple, right? I mean, they’re the only ones who can fix this! Yep, it’s been done. Over and over again. For more than a year. So, until then, you’ve been warned.