People often ask us what the difference between Core Data and Data Abstract is, and why they should choose one over the other.

The answer to that second question frequently is “it depends”, because while on first glance Core Data and Data Abstract might seem like technologies that solve the same problem (“database access”), they are actually quite different technologies, and designed with very different goals.

Core Data is, in essence, a local data access technology and ORM. It is designed around the concept that your application has a certain data model, expressed as a suite of objects, and wants to persist that data between runs (or to save runtime memory footprint), locally. As such, Core Data is largely a front-end for SQLite (although it supports other storage options) that abstracts the developer from dealing with the actual database storage, table structure, and SQL queries, and exposes data as regular in-memory objects that magically persist.

Don’t get us wrong, that is an awesome feature for many scenarios, and Core Data is a great solution in that space.

Data Abstract on the other hand is designed around the concept of data stored on a “big” server somewhere on the network, off your iDevice or Mac, or “in the cloud”, and that the database on this server (or these servers) contains data that is shared between many users of the application (which of course does not mean that each user cannot have their own private set of data).

These servers could be anything, from an existing database in a large Oracle cluster that already provides the backbone for an enterprise, to a fresh database you just designed solely for your iOS app. The target application could be anything from — say — a view into said enterprise’s customer relations system, over an iOS front-end to your web site, to the client app for the next Social Network you are building.

To achieve this, Data Abstract is build around the so-called Multi-Tier concept, where the client applications you build using Data Abstract talk to a “middle tier” server that enforces data consistency and access restrictions.

The central difference between Core Data and Data Abstract is that the former is focused around simplifying how an app can persist its application state locally, while the latter is designed around accessing, presenting and working with data that exists elsewhere, usually (but not necessarily) in a context that is much larger than an individual application and an individual user.

So Core Data and Data Abstract aren’t really that much in competition, but target pretty different scenarios. In most cases where Core Data is a good solution, Data Abstract would be overkill or even useless, and in the cases where you need what Data Abstract provides, Core Data won’t do much good.

But What About Core Data in iCloud?

On first glimpse, it might seem as if the new Core Data Syncing via iCloud expands Core Data onto Data Abstract’s turf. And to a certain degree that is true; iCloud certainly expands what you can do with Core Data, but there are still some pretty severe limitations.

When Steve Jobs took the stage at WWDC in 2011 to announce iCloud, he gave the reason why iCloud was going to be better than previous syncing technologies: Rather than syncing information between devices he said that with iCloud the “truth, is in the cloud”, and each device — iOS or Mac — syncs against a well-known set of data in that single location.

That is the right way to do it, and that is how iCloud works in general, but: it is not how Core Data syncing via iCloud works, unfortunately.

At the time of this writing, Core Data syncing via iCloud consists of each client storing change logs in the cloud and these diffs getting transferred between devices. In other words, iCloud syncs Core Data between devices, without a single truth “in the cloud”. As Drew McCormack has outlined in his excellent series of articles on the topic, this comes with a myriad of problems, caveats and corner cases to look out for.

This is, of course, in sharp contrast to how data access with a multi-tier solution such as Data Abstract is handled. Data Abstract’s model (or any other database-centric multi-tier architecture) does put the truth in the cloud, just as Steve Jobs suggested it should be.

Another crucial limitation of Core Data is that any data it stores in iCloud is still an island: it can only be accessed by the applications that created it, and is isolated per user. That is fine for many scenarios (e.g. in cases where you’re 100% focused on in-app presentation), but imposes some serious limitations, such as:

• not being able to provide a web-based front-end to user’s data outside of their iOS apps.
• not being able to provide access to the user’s data on iOS/Mac on the one side, and client applications on other platforms (be it Android, Windows, or even just non-App Store Mac) on the other.
• not being able to offer options for users to share data among themselves, or share data publicly.

Also, the fact that data is self-contained within each user’s store means that as the application developer, you have no access to it, for example to investigate if users are reporting problems. On the one hand, this is a win for user privacy, as users only need to trust Apple with their data, not you as the App Vendor, but on the other, it severely limits what apps can do and how you as an app developer can trouble-shoot or assist users when they have problems with their data.

So, Which Option Should You Choose?

Indicators that Core Data is the right solution would be:

• You have a fairly straightforward data model and not more data than can easily it on the device.
• Your data is internal to the application, and you never want to use it outside of the app (aside from, say, letting the user explicitly export it).
• Your entire data is tied to a single user and you have no need to share (part of) the data between different users of your app.

Indicators that you might want to use Data Abstract include:

• You are building a front end to already existing data managed in a database (e.g. an app for your Enterprise database).
• Your app’s data is part of a larger data infrastructure shared (in parts) by all or some users of your app.
• Your app’s data should be accessible (in parts) outside of the application itself, for example via a web site.
• Your app’s data should be available on platforms not covered by iCloud, for example Windows or Android clients.
• Users of your app should be able to share (parts of) their data, whether explicitly or implicitly.
• Your application contains shared data common to many or all users.
• You want or need full control and access to the data and how it is stored.

The one advantage of Core Data, of course, is that it works “out of the box” with just the user’s devices, and (optionally) iCloud, and you do not need to worry about setting and maintaining any database and server yourself.

If your application can live within these constraints, that can be a significant saving in both cost and management effort. But in most cases, you either need the extra flexibility of hosting the data yourself, or you don’t — and if you do, Core Data and iCloud give you absolutely no wiggle room and hosting your own data will be the only solution.

Data Abstract makes that easy and cost efficient too, and with our free Relativity Server that can be hosted on just about any co-located server and on many cloud services, such as Amazon EC2, you can be up and running with your own hosted middle-tier quickly.

Interested?

If this got you interested, please check out some of our other resources on Data Abstract for Xcode (and for our other platforms) to see what DA can do for you and how to get started.

In particular, i recommend reading the first available chapters of our “Data Abstract for Xcode Book” and to check out the videos on RemObjects TV, especially Introduction to Data Abstract for Xcode narrated by yours truly and Relativity Server Overview.

And of course we have a free 30-day trial versions of Data Abstract for all platforms.

We hope you will find Data Abstract useful — and don’t hesitate to contact me directly or our support team if you have any questions.

— marc