Despite it's flaws, I have found Core Data to be quite necessary when working with iOS database driven apps, as it provides some rather crucial functionality th

Despite it's flaws, I have found Core Data to be quite necessary when working with iOS database driven apps, as it provides some rather crucial functionality that would otherwise be lost (or need to be manually recreated) when working with raw SQLite. Concurrency support (as mentioned) is one such example. Another important function is the support it provides for object change tracking. As your objects are modified, Core Data will dispatch the relevant notifications so you can keep your views updated with the latest changes. If your objects can be updated from multiple places (say, multiple areas of your UI, plus changes occurring in a background thread if you're importing in bulk, or syncing data to a web service), you'll need some way to react to these updates efficiently. This is something that Core Data provides out of the box that you would otherwise have to handle manually, and refreshing the UI in real-time to database changes is something that is mandatory in any modern app. NSFetchedResultsController takes this one step further by determining which changes are relevant to your table view or collection view and inserting/removing/updating the correct cells as necessary. And it does so efficiently which is incredibly relevant on mobile devices. (Note that ContentProviders on Android have similar capabilities for notifying you when a particular object is inserted/updated/deleted. I prefer the Core Data approach as it actually tracks specifically what has changed.) That said, Core Data is not without it's flaws. I find it somewhat overengineered in some areas and rather lacking in others. For example, the 'abstraction' of Core Data backends is a weakness rather than a strength. In practice, I would wager that 99% of people using Core Data are using it with the SQLite backend. Having to cater to the existence of an alternate XML backend means that certain actions can't assume (and hence take advantage of) SQLite specific features. For example: - The inability to issue bulk updates or queries. Instead of doing a DELETE FROM x WHERE y, you have to iterate through all the objects you want to delete or update. This can be slow. - If you need to do anything custom in a migration, it would be great to be able to write a SQL level migration script instead of going through the extremely cumbersome manual migration process. Additionally, the recently added concurrency options are still missing support for a very common use case: running your initial fetch on a background thread, and then populating a table view with the objects you just fetched. This is technically possible to do but not very easy, as you can't safely pass managed objects between thread boundaries without a bunch of extra work, and not supported by the native NSFetchedResultsController so you lose the ability to use that. (Again, to compare to Android, their loader framework makes doing background queries very easy to implement.) Overall I think Core Data is a huge plus for iOS/Mac developers but there is definitely lots of room for improvement.