{"id":45397,"date":"2024-10-16T14:05:21","date_gmt":"2024-10-16T18:05:21","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=45397"},"modified":"2025-03-17T11:29:09","modified_gmt":"2025-03-17T15:29:09","slug":"returning-to-core-data","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/10\/16\/returning-to-core-data\/","title":{"rendered":"Returning to Core Data"},"content":{"rendered":"

Fatbobman<\/a>:<\/p>\n

\n

However, the release of iOS 18 cast a shadow over this beautiful vision. A year after its first appearance, SwiftData underwent a major underlying refactoring. Although this adjustment was aimed at shifting from a strong coupling with Core Data to supporting more flexible multi-persistence solutions—a direction undoubtedly correct—it seems that the significant changes led to considerable impact on the new version’s stability.<\/p>\n

Disappointingly, a large amount of SwiftData code that ran well on iOS 17 encountered various problems in the new version. For a data persistence framework that shoulders heavy responsibilities, these issues are undoubtedly fatal. What’s more worrying is that the complexity of these problems means they may not be thoroughly resolved in the short term. It is foreseeable that throughout the iOS 18 cycle, developers choosing to use SwiftData will have to continuously grapple with these challenges.<\/p>\n

[…]<\/p>\n

SwiftData’s performance on iOS 18 put me in a dilemma. For an application centered on data management, stability and reliability are non-negotiable. After repeated deliberation, I had to make a tough decision: abandon the thousands of lines of SwiftData code I had completed and return to Core Data.<\/p>\n

[…]<\/p>\n

When rebuilding the Core Data project, I decided to integrate the modern thinking I learned from SwiftData, using a more innovative approach to harness this time-tested framework.<\/p>\n<\/blockquote>\n

Personally, I think the sweet spot is using mature frameworks like Core Data and Cocoa from Swift. Apple hasn’t done as much as I’d hoped to make this ergonomic, but there’s a lot you can do yourself. I actually go further than the example here and make all managed object initializers take the required attributes plus<\/em> the context<\/code> as arguments.<\/p>\n\n

Previously:<\/p>\n