Why I wish I'd never used Magical Record

The first time I used Core Data I thought it was amazing. However, I got it all very wrong. I had "helper" functions in the App Delegate, I didn't use any relationships in the data model, etc... All very wrong.

Then I learned more about it and did it all myself again, this time it was excellent! I understood how the relationships worked, I was using NSFetchedResultsController. Merging changes from background contexts, syncing changes up to a server, everything.

Then I found Magical Record... this is awesome! (I thought).
It makes everything to do with Core Data so easy! (I thought).

It puts hundreds of different functions in to one line of code. Creating fetches becomes so easy, saving is easy, NSFetchedResultsController creation is now one line of code.

I went to town. Completely integrated it into my app.
Then I migrated my app from Xcode 4 to Xcode 5.

Ran the app... everything is fine! Woop!
Wait... the UI isn't responding, I can't press any buttons, no exceptions thrown either, what's going on?!

I paused the app and the first line in the stack trace looked a bit odd.


Looks like something to do with Core Data is blocking the main thread. Time to put my debug hat on...

Right, CoreData, where could the error be?

Wait... I have no idea. Something in Magical Record is doing something that looks like it's causing a deadlock between threads.

Do I know where it is? Nope, I didn't write it.
Do I know where to start looking? Nope, this code is alien to me.
Do I wish I could pull Magical record out of the project? Absolutely.

Is this blog really just a rant?

OK, let me get to my point.

I doubt that Magical Record is fully to blame for this. I'm guessing that somewhere I used it in the wrong way that caused this error. I guess...

But that's just it. I can only guess at what is wrong.

Because I've relied so much on someone else's code there isn't really anything I can do to work out how to fix it. I don't know the inner workings of my app when the inner workings is what I'm building.

I've since started a couple of other projects using CoreData and networking and neither of them use AFNetworking or Magical Record. Not because I think they are bad or don't work, but because I know that I can do everything I need just as easily and just as well. In fact, in both cases, my own code worked better for what it needed to do than either of these frameworks could do for me.

Of course, I'm not suggesting that everyone should stop using Magical Record and AFNetworking. Just make sure you know how and why they work before diving in head first. There will come a time when you need to know why something is acting in a particular way and you'll need to know the fundamentals.

I'm stuck with two options at the moment.

1. Try and work out what is happening that is causing this deadlock. I have no idea if it's my code or Magical Record code.
2. Try and remove Magical Record completely from my app. This is no mean feat. There are uses of it all over the place.

::Sigh:: back to work πŸ™


  1. I can understand the author's frustration here. As a consumer of other open source frameworks, I have been hesitant to also dive in and invest my time to understand the code fully. I just want something to work, as advertised and be done with it.

    But, the flip side of this is that MagicalRecord, along with almost everything other 3rd party library I've used, is that it's fully open source. You have full access to everything. Nothing is pulled over your eyes. I spend an enormous about of time and effort to make sure classes, methods, functions and variables are named properly and that the code is easy to read and follow. I know MagicalRecord isn't as documented as it could be, but that's one way I had hoped more people would contribute, as a learning exercise.

    Either way, I don't want to post a followup rant myself here. I do applaud the fact that you've now realized that MagicalRecord isn't a "cure" for understanding how Core Data works. When you're ready, the MagicalRecord project will gladly listen to feedback or issues you're having, and most of all, review and accept any pull requests.

  2. oliverfoggin

    Thanks for the reply.

    Magical Record is great. I could just have easily put AFNetworking or any other framework in the title.

    It is without doubt one of the most complete third party frameworks available for iOS.

    My post is more about relying on other people's code. Because I had used a third party framework I had no real idea about how things were working.

    And you're right, by taking a look at the code I was able to find how to fix the problem I was having. It was to do with calling something from a notification that was on a BG thread that then did something else on a BG thread.

    However, I don't fully understand why it was doing this.

    Anyway, please continue updating Magical Record. It is a great tool. Maybe if I was able to understand the way it worked more and how to use it I might come back to it in the future.


  3. Ron

    I understand what you are saying completely. I, like you, always do it the hard way without the helper classes first and then use frameworks like Magical Record later. That way I know I understand it.

    I ran into a limitation of Magical Record and it caused me great stress until I dove into their code. I need to use configurations in Core Data and Magical Record doesn't support this. I had to reimplement their initialization methods. I think I'm stuck with version 2.7 forever as a result.

    I'm still glad I use Magical Record but when I look back at my code without it it doesn't seem that bad.

  4. oliverfoggin

    Not at all. In fact, I eventually found the cause of the problem and it was something to do with it sending messages between foreground and background threads.

    My issue is that the fact I had to debug it at all was entirely down to using a library of code that I didn't write.

    I could have done all the core data (or networking) myself and in the past (and since this) I have done. I had heard good things about using these particular libraries and yes they are really well written and well implemented. However, the problem I had was down to the fact that the developer of the library had intended for it to be used in one way and I had assumed it worked in another way.

Leave a Reply

Your email address will not be published. Required fields are marked *