Core Data is a fantastic framework and I love using it. I agree that Core Data has a learning curve, but isn't this true for many other frameworks? Because of Core Data's learning curve, developers often turn to third party libraries that make working with the framework easier.
Over the years, I have played with several Core Data libraries. While I don't have any objections against third party libraries, my stance on Core Data libraries is more nuanced.
Dependencies
By using a Core Data library, you automatically add a dependency to your project. There's nothing inherently wrong with dependencies. Every project has dependencies. If you use Swift to develop a Cocoa application, then Swift is a dependency of your project.
You don't need to reinvent the wheel. If a proven solution is available, then it makes sense to use it and save time and money. But it's important to consider every dependency you add to a project. A project that uses Core Data has a dependency on the Core Data framework. By using a Core Data library, you add another dependency to your project.
A few years ago, Mattt Thompson listed the most popular libraries for working with the Core Data framework. I've worked with a few of these libraries, MagicalRecord and Objective Record. Unfortunately, many of these libraries haven’t been updated for quite a while. This doesn't mean that you can no longer use these libraries, but using an outdated library always poses a risk. It also means that you probably won't be able to take advantage of the newest features and improvements of the Core Data framework, such as query generations.
Why Do You Use a Dependency
Why do you want to use a Core Data library? Do you find it challenging to work with Core Data? Or do you have trouble wrapping your head around the many concepts and classes of the framework? If that's the reason for choosing a Core Data library, then you're using a level of abstraction for the wrong reasons.
If you decide to use Core Data in a project, you need to make sure you understand how the framework operates. For example, you need to know what a Core Data stack is, how it works, and how it should be used.
If you don’t understand the ins and outs of the framework, then don't use a Core Data library. That's not the solution to the problem you're having. Set aside some time to learn the fundamentals of the framework.
What if You Run Into a Problem
At some point, you will run into a Core Data issue. Debugging the problem will drag you into the bowels of the Core Data library you're using. This means you need to become familiar with the internals of the Core Data library and that implies that you need to have a solid understanding of the Core Data framework.
There's no way around it. If you want to use Core Data in a project, you need to understand how the framework does its magic. Don't take shortcuts.
Before you decide to use a Core Data library, learn the basics of the framework first. After learning the basics, you can still decide to use a third party library.
Convenience Library
Many developers use a third party library to avoid the verbose APIs of the Core Data framework. I can assure you that Core Data has evolved quite a bit over the years. If you're using Xcode 9 and Swift 4, you'll be surprised by how elegant the Core Data API has become.
If you still feel that the API is verbose and clunky, then consider creating a lightweight convenience library. This is a common solution many developers use. You don't need to rely on a third party to create one for you. Creating a lightweight convenience library is easier than you might think.
My suggestion is to learn the basics of the framework, use it in a project, and create a lightweight library as you go. This is a natural and intuitive process. You don't need to spend hours or days creating a library. Build one as you go. That works best.
Core Data Has Matured
It's true that the Core Data API used to be verbose and hard to use. But Core Data has grown up over the years. It's now a mature framework and, with Swift 4, the API has become elegant and concise. There's still room for improvement, there always is, but we're at a point where third party libraries should no longer be the default option when working with Core Data. Give it a try and let me know how it goes.
