Tim Roadley, author of Learning Core Data for iOS: A Hands-On Guide to Building Core Data Applications and the upcoming book "Learning Core Data with Swift" discusses Apple's Core Data Framework with Pearson Senior Acquisitions Editor Trina MacDonald. They talk about the challenges developers face when trying to learn how to use the framework and how Apple's Swift programming language makes those challenges easier.

From the author of

Trina MacDonald: Apple’s Core Data framework seems designed to take a lot of the effort and tedium out of coding, specifically when dealing with data objects. Yet it seems a lot of iOS programmers struggle with learning how to use it, and some avoid it altogether. Why do you think that is?

Tim Roadley: I think part of the reason some programmers avoid Core Data is the perception that it’s more trouble than it’s worth. They just want to save a few objects to disk and don’t have time to learn a whole new framework. It’s tempting to instead save data to a file like JSON or XML because it’s easy. Don’t get me wrong, there is a place for that; however, it’s not scalable and can introduce memory pressure down the road.

For those who struggled to learn Core Data, I think this can historically be attributed to the lack of quality step-by-step learning material. When I first started learning Core Data I was frustrated that there wasn’t a clear path beyond examining existing apps and deciphering class references. Particularly having come from a traditional database background I felt that Core Data obscured areas that I was used to controlling directly. What I understand now is that I don’t have to worry about that stuff any more. Just focus on designing a good data model and let Core Data handle the rest.

Trina: What, if anything, does Swift bring to the table that might make Core Data more accessible to programmers?

Tim: I think Swift code is easier to understand because it’s easier to read. Once developers have a handle on Swift, this will help minimize distraction and make learning new frameworks easier. That said, at this point in time Swift is new to everyone so will take a bit of getting used to. Thankfully Swift is pretty simple to pick up for an Objective-C programmer once they understand optionals and a handful of other day-to-day changes.

Trina: Apple’s announcement of Swift has changed the game for iOS application development in general. But traditionally working with Core Data has required some fairly deep knowledge of Objective-C. So, how has Swift impacted working with Core Data?

Tim: Fortunately the introduction of Swift hasn’t impacted working with Core Data much at all. NSArray has taken a back seat to typed swift arrays; however, for the most part everything else is the same. There are a few gotchas with syntax and NSManagedObject subclasses to be aware of; however, converting from Objective-C to Swift has been pretty straightforward.

Trina: How is your upcoming book "Learning Core Data with Swift" any different from your previous book “Learning Core Data”?

Tim: I was overwhelmed with the positive feedback for the Learning Core Data title, so I wanted to hold true to that winning formula. Of course, everything will be updated for Swift using the latest versions of Xcode and iOS. The Groceries application (built from scratch in the book) will use CloudKit instead of StackMob. This will demonstrate how you can now share data between iCloud accounts, in this case to share a common shopping list. I’ll also be refactoring the helper classes to make them even easier to reuse in to your own projects.

Trina: With Apple continuing to innovate at a fairly rapid pace, and given the likelihood that more exciting developments will be announced at the 2015 Worldwide Developer’s Conference, what changes or improvements would you like to see made to Core Data in the coming year?

Tim: I would like to see a set of convenience classes developed by Apple to replace what readers build with my upcoming book "Learning Core Data with Swift." There are so many things common to every application that could be made boilerplate code to save developers time. For example, in my book readers develop a reusable class that sets up the whole Core Data stack in one line of code. As another example, a reusable Core Data Table View Controller class is created that provides an NSFetchedResultsController backed UITableViewController with only few lines of customization code needed. Apple could extend this to UICollectionViews, UIPickerViews etc.