Last week, I listed in my blog the changes I hoped to see in SwiftUI at this year’s WWDC. This week, I want to continue sharing my expectations for Core Data.
Swift Remake
Urgency: 3 Feasibility: 0.5 (Total score: 5)
In the past two or three years, whenever WWDC is approaching, there are always developers predicting (more of expecting) that Apple will release a Core Data implementation completely based on Swift. However, rationally speaking, the conditions in all aspects are not yet mature. On the one hand, as an object graph management framework widely used with persistence capability, Apple’s adjustments to it must be very cautious. On the other hand, although the implementation of Core Data is somewhat outdated, it can still be stably used with many new frameworks and services, and Apple lacks the motivation to make revolutionary adjustments to it. Finally, the current Swift language and other frameworks used in conjunction with Core Data still lack the ability to support the creation of pure Swift implementations.
From the experience of SwiftUI, when Apple intends to launch the Swift version of Core Data, we will inevitably see clues from the proposals in the Swift community.
Nevertheless, I still have a strong desire for Core Data implemented based on Swift and look forward to the day when it comes. Maybe the Swift remake can give it cross-platform capabilities.
Refactoring some APIs with Swift
Urgency: 5 Feasibility: 4.5 (total score of 5)
Although I don’t think Apple will Swiftify Core Data in the short term, work on Swiftifying the associated frameworks and APIs has been ongoing for several years.
Currently, implemented APIs based on Swift include FetchRequest (in the SwiftUI framework) and SortDescriptor.
In the recently released swift-foundation, Predicate has already been mentioned, and it is expected to be implemented in the second half of the year. If Apple can also implement other APIs (such as NSExpression) with Swift, and then make targeted enhancements to the Swift language, a Swift-based implementation of Core Data will emerge.
Support for more SQLite new features
Urgency: 4 Feasibility: 3.5 (total score: 5)
Although Core Data currently supports four storage modes, most developers still prefer SQLite as their preferred storage type. Apple is also aware of this situation, so some new features developed for Core Data in recent years only support SQLite.
However, Apple has not enhanced its support for Core Data’s SQLite for a long time. Personally, the full-text search and native JSON query capabilities that SQLite can provide are both urgently needed by me.
I hope that the above features can be adopted by Core Data in the next one to two years.
Better Model Editor Experience
Urgency: 4 Feasibility: 4 (Total score: 5)
In recent years, Apple has basically given up on improving the Model Editor in Xcode, except for adding necessary support for some new features. Especially in Xcode 14, Apple removed the relationship graph editor for data models, which has left me very confused.
Although I don’t use this feature often, the biggest advantage or feature of Core Data compared to other persistence frameworks is its ability to manage relationships. This is also one of the main reasons why Core Data is considered an object graph management framework rather than just a persistence framework.
Even if the Model Editor cannot be strengthened, its original advantages should not be erased.
I still sincerely hope that the Xcode team will not give up on the Model Editor and further enhance its functionality and improve its user experience.
Improving some APIs in Core Data with CloudKit
Urgency: 5 Feasibility: 4 (Total score: 5)
In the first three years after the release of Core Data with CloudKit, Apple has been advancing the development of this framework at a steady pace, introducing many features such as private and public database syncing, and data sharing. Compared to the Core Data framework itself, Apple’s achievements in promoting Core Data cloud syncing are impressive.
However, it is regrettable that there was no continuation of this development trend last year. No new features were introduced, and there was no improvement of some of the issues that arose previously.
In particular, the data sharing feature has not been widely adopted by developers due to some API imperfections.
Core Data with CloudKit is now a powerful tool in the Apple ecosystem, and applications developed based on it have considerable platform exclusivity. Apple should make good use of the advantages it has created to further enhance this feature, at least to ensure that all current features can be used normally.
Improving Sync Performance of Core Data with CloudKit Urgency: 5 Feasibility: 3.5 (Total 5 points)
As more applications adopt Core Data with CloudKit, the amount of user-generated data also increases rapidly. Therefore, the issue of poor network synchronization efficiency becomes more and more apparent.
As a developer, I understand that cost considerations have led to Apple intentionally controlling the frequency and quantity of data synchronization. However, considering that so many applications have adopted Core Data with CloudKit as their synchronization framework, can Apple consider providing more choices for developers or users?
For example, allowing developers or users to obtain better and faster synchronization services by paying extra fees.
Of course, if Apple could upgrade the overall performance of iCloud services to allow all developers and users to benefit for free, that would be the best outcome.
Conclusion
As the saying goes, “the deeper the love, the stronger the responsibility.” As a heavy user of Core Data, I sincerely hope that Apple can continue to develop this framework with a long history and bring about its second spring.
