> Contrary to popular belief, Core Data is not an Object-Relational Mapper, but rather an object graph and persistence framework [...] Using Core Data as an ORM necessarily limits the capabilities of Core Data and muddies its conceptual purity. But for many developers longing for the familiarity of an ORM, this trade-off is a deal at twice the price!
Edit: should have read the post before replying to comments ^^’
Core Data traces its roots over 25 years with NeXT's Enterprise Objects Framework (EOF) [1]:
> Many of the core concepts of EOF re-emerged as part of Core Data, which further abstracts the underlying data formats to allow it to be based on non-SQL stores.
Apple also released CloudKit which synchronizes with FoundationDB’s Record Layer making Core Data an alternative to Google Firebase and Amazon’s GraphQL based AppSync.
It is an object oriented approach to data access which many developers prefer while others dislike. SQLDelight [2] is a YeSQL-like alternative for the anti-ORM and anti-Vendor-Lock-In folks but it relies on Multiplatform Kotlin to support both Apple and Android ecosystems.
Engineering is about managing trade-offs given a set of constraints. Core Data is sometimes a fine choice.
It does have a persistence layer, but it is not it’s persistence layer.
See https://nshipster.com/core-data-libraries-and-utilities/
> Contrary to popular belief, Core Data is not an Object-Relational Mapper, but rather an object graph and persistence framework [...] Using Core Data as an ORM necessarily limits the capabilities of Core Data and muddies its conceptual purity. But for many developers longing for the familiarity of an ORM, this trade-off is a deal at twice the price!
Edit: should have read the post before replying to comments ^^’