The Deprecation of iCloud Core Data
In March 2013, I chronicled the problems developers were having with Core Data iCloud syncing. Many concluded that the basic NSPersistentStoreUbiquitousContent design was flawed. Bugs could be fixed, but it would never be able to do what people wanted. Apple didn’t give the impression that it thought there were major problems. It kept reporting minor improvements and bug fixes. When CloudKit was announced in 2014, it had no official Core Data story. As far as I know, there is still isn’t one. Meanwhile, Drew McCormack built the Ensembles framework, which fixes just about all the problems with Apple’s design and works with both CloudKit and Dropbox.
Fast forward to WWDC 2016. When installing the Xcode 8 beta, I noticed that all of the symbols related to iCloud Core Data were marked as deprecated in macOS 10.12 and iOS 10, with the comment “Please see the release notes and Core Data documentation.” Strangely, the Core Data release notes and What’s New in macOS 10.12 documents make no mention of this. What’s New in iOS 10 simply says that “Several NSPersistentStoreCoordinator symbols related to ubiquitous content” have been deprecated.
I asked on Twitter what was up, and no one seemed to know. No one had anything nice to say about iCloud Core Data, either, though no doubt many developers still rely on it. I hoped that all would be explained in today’s WWDC Session 242: What’s New in Core Data. Alas, reports are that absolutely nothing was said about iCloud in the session. A key technology that underpins apps is (apparently) to be removed, and Apple didn’t tell anyone at its own developer conference. In my view, this is shameful. The issue is more acute than with a normal deprecation because the APIs rely on cloud services, which could conceivably stop working even for older OS versions where they are not deprecated.
It seems clear that the way forward is Ensembles, unless you want to write your own sync engine or wait for Apple to announce one. I hope that the deprecation will spur more of the community to coalesce around Ensembles.
On a more positive note, it looks like there are a lot of great developments in Core Data this year, including the integration of a mogenerator-like tool into Xcode and, apparently, the end of NSObjectInaccessibleException, which doesn’t play well with Swift.
Update (2016-06-18): Drew McCormack:
If you move to Ensembles now, you not only get the usual support, documentation, and source code, you also get it all at half the standard price. The sale will continue until macOS Sierra is released later this year.
Update (2016-06-19): See the comments on Hacker News.
Update (2016-06-22): Apple’s Ben Trumbull:
Apps will continue to work for the foreseeable future. Aside from the deprecation warnings, there are no changes to or removal of the functionality in iOS 10. We don’t have any specific time line to announce now, but traditionally deprecated symbols on our platform remain functional for a considerable period of time before removal.
Only the client Core Data iCloud API symbols are deprecated. Core Data with iCloud is built on top of the iCloud Drive service. The service pieces are not effected in any way and will continue to work. If and when the deprecated APIs are disabled in some future OS version, applications running on iOS 9 or 10 will continue to work.
However, App Store Review Guidelines say that apps cannot use deprecated technologies.
Update (2016-06-27): Daniel Pasco:
Last time I dove in to iCloud I lost a year of schedule and an evangelist eventually called me a masochist for continuing to try.
7 Comments RSS · Twitter
While Ensembles look promising, I don't expect the community to coalesce around a project that "is not available under an open source license" (quote from the Ensembles web site).
And for the mogenerator like tool in Xcode, it is barely broken in the Xcode 8 beta. It's almost impossible to choose what you want to generate reliably, and event once you managed to get what you want, it generate code that does not work well with the included swift compiler version. For instance, you can't use #keyPath() on a @Managed property generated by Xcode, as the compiler will raise an error telling that you can't do that on a property without the @objc attribute…
@Jean-Daniel
Ensembles 2 is indeed a commercial product, but it is source available. People who take a support license get the source code, and can keep an use that source forever.
Ensembles 1 is completely open source, and available here (https://github.com/drewmccormack/ensembles).
Far from being a weakness, I think having a commercial element in Ensembles was essential to its success. I have been able to put much more time into it than I otherwise would, and the project is much more likely to continue being supported than your average open source project.
@Jean-Daniel: Why would Ensembles 2 need a "community to coalesce" around it? It's a product that provides individual developers with an off-the-shelf solution to a common problem. They buy it or they don't according to whether they have that particular problem or not. The benefits to having an established user base around the product are that it gives newcomers a sense of confidence in the usefulness and durability of the product and its vendor, and more experienced users will often provide advice and assistance to newcomers which takes some of the advertising and support workload off the vendor, but that's not a prerequisite to the product successfully doing its job for those that choose to use use it.
@Drew: Yep, altruism and vanity are all well and good while they last, but nothing beats putting bread and butter on the table for maximizing the chances of long-term survival. That said, does the E2 licence also include a "dead man's switch", so that if you cease development and support and it's not sold on to another vendor, after a certain length of time the code will automatically revert to an appropriate OSS licence? That would give existing and future users the freedom to maintain and update the code and redistribute it along with those updates, without which neither the software nor its user base has any long-term chance of survival.
Confess I have not heard of such a clause before. Sounds like a good addition.
The individual users have a license to keep using and developing their copy of the source, but it wouldn't automatically become open source.
That said, should I stop development without having another take it over, I would make it open source. But you just have to take my word for that at this point.
