Most iOS devs fail to realize that CoreDate was originally created for managing data in desktop apps, but many of the advantages it offers for Mac development d

Most iOS devs fail to realize that CoreDate was originally created for managing data in desktop apps, but many of the advantages it offers for Mac development don't exist on mobile. For example, iOS has no bindings. On the Mac you can bind your UI elements to data objects backed by Core Data so that as the data changes everything stays in sync. (Yes, like modern JS libraries.) For simple use cases you can do a surprising amount of development with very little code, although for complex use cases it can sometimes get ugly. Also, I believe an SQL-based approach is more appropriate for the smaller screen sizes with iOS. The master-detail approach on iOS typically works out to showing a master list with a few labels describing each object, then drilling into to the object's details. In many cases all the labels on a master list (plus an associated object id) can fit into a single in-memory array, and an SQLite query works great to pull these labels strings off disk when the view loads. There's little reason to have CoreData manage faulting/loading entire data objects as users scroll up and down the master list just to view the titles. Of course the SQL data access should still be abstracted, but CoreData is overkill in cases like this.