5 ms·

Apple's Frameworks teams tend to ship two kinds of APIs -- APIs designed around the needs of first-party apps and APIs designed specifically for third-parties t

by panic 6y ago

Apple's Frameworks teams tend to ship two kinds of APIs -- APIs designed around the needs of first-party apps and APIs designed specifically for third-parties to use. Core Data is characteristic of the second kind of API. It sounds cool in theory, but when you try to use it, it never really seems to do what you want it to. Hence the need to "use an abstraction layer" over an API which is itself an abstraction layer (sqlite) over an abstraction layer (file I/O).

ElFitz 6y ago
It’s not just an abstraction layer over SQLite, or any database, for that matter, even though it is even often used and thus thought of as an ORM. It does have a persistence layer, but it is not it’s persistence layer. See https://nshipster.com/core-data-libraries-and-utilities/ 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 ^^’
- sradman 6y ago
  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. [1] https://en.wikipedia.org/wiki/Enterprise_Objects_Framework https://en.wikipedia.org/wiki/Enterprise_Objects_Framework [2] https://github.com/cashapp/sqldelight https://github.com/cashapp/sqldelight
tcldr 6y ago
That suggests that Apple don’t use CoreData internally but my understanding is that they use it quite heavily – Photos for example. If anything I would argue it’s the other way round; the API is designed first and foremost for internal clients which creates quite a burden of complexity and nuance for third-party clients to come up to speed. I think the tough thing for Core Data is that it’s effectively a big caching layer and whilst that brings great performance benefits if you understand how and why it does what it does, it also brings a level of complexity and confusion if you don’t. Having said that, its API is starting to show its age in this new era of type-safety.
- ericlewis 6y ago
  Yeah, they use it a lot. Like a ton internally, even for internal to apple apps.

by panic 6y ago

ElFitz 6y ago

It’s not just an abstraction layer over SQLite, or any database, for that matter, even though it is even often used and thus thought of as an ORM. It does have a persistence layer, but it is not it’s persistence layer. See https://nshipster.com/core-data-libraries-and-utilities/ 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 ^^’

sradman 6y ago
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. [1] https://en.wikipedia.org/wiki/Enterprise_Objects_Framework https://en.wikipedia.org/wiki/Enterprise_Objects_Framework [2] https://github.com/cashapp/sqldelight https://github.com/cashapp/sqldelight

tcldr 6y ago

That suggests that Apple don’t use CoreData internally but my understanding is that they use it quite heavily – Photos for example. If anything I would argue it’s the other way round; the API is designed first and foremost for internal clients which creates quite a burden of complexity and nuance for third-party clients to come up to speed. I think the tough thing for Core Data is that it’s effectively a big caching layer and whilst that brings great performance benefits if you understand how and why it does what it does, it also brings a level of complexity and confusion if you don’t. Having said that, its API is starting to show its age in this new era of type-safety.

ericlewis 6y ago
Yeah, they use it a lot. Like a ton internally, even for internal to apple apps.