Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Core Data
- Thread starter grandM
- Start date
- Sort by reaction score
depends on the application. Core data is an object graph storage, so good for storing structured data but not so good for relational. If i just need to store info about say, Staff members I would consider Core Data. If the data is more complex, for example products, stock levels, transactions I would go with sqlLite.
But how do you keep it synced then with the cloud then?
[doublepost=1559616599][/doublepost]
Would you then just leave CoreData entirely out? Or implement it and sync it with Realm in the cloud?
I've used Realm on the device. It would be instead of Core Data or sqlite. Storing data in the cloud is another story.
I use and know Core Data pretty extensively and have deployed it in several apps, so my take is that it today's Core Data is pretty good.
It has an great concept for managing entities, some nice magic with the runtime to make things easier, and is pretty straight forward. It can be verbose, but this generally allows for the ability to break components apart and overall I've found that leads me to be better organized with my model structure and setup. Besides that, you can easily find or make your own wrappers to reduce code redundancy if that's a problem. It's core (ha) focus is tracking objects and imo it does that well.
It handles relational data just fine... and is a relational database (not just an ORM or graph database) so I'm not really sure why that was mentioned as a negative - I think that's worth expanding on if you can because I'm curious. The example you noted can be easily achieved in CD and I've modeled some pretty intense graphs before.
The single biggest drawback and one that is a deal breaker for most is going to be data portability. There is no Core Data iCloud API anymore, so it is up to the developer to manage iCloud, CloudKit, or other service storage and synchronization (it can be done and there are some 3rd party frameworks out there for this). The default format Core Data stores in is not very portable, even though it's a SQLite file, so translating even just the database to something standardized is going to be some effort unless you want XML or to write your own adaptor.
It has an great concept for managing entities, some nice magic with the runtime to make things easier, and is pretty straight forward. It can be verbose, but this generally allows for the ability to break components apart and overall I've found that leads me to be better organized with my model structure and setup. Besides that, you can easily find or make your own wrappers to reduce code redundancy if that's a problem. It's core (ha) focus is tracking objects and imo it does that well.
It handles relational data just fine... and is a relational database (not just an ORM or graph database) so I'm not really sure why that was mentioned as a negative - I think that's worth expanding on if you can because I'm curious. The example you noted can be easily achieved in CD and I've modeled some pretty intense graphs before.
The single biggest drawback and one that is a deal breaker for most is going to be data portability. There is no Core Data iCloud API anymore, so it is up to the developer to manage iCloud, CloudKit, or other service storage and synchronization (it can be done and there are some 3rd party frameworks out there for this). The default format Core Data stores in is not very portable, even though it's a SQLite file, so translating even just the database to something standardized is going to be some effort unless you want XML or to write your own adaptor.
Last edited:
indeed, using sqlLite directly would exclude if from iCloud sync's. When I have use sqlLite for enterprise clients I used custom API's to Rest Web Api's that integrated with back end systems. iCloud integration wasn't even in the picture.