databaseScope lead to dyld: Library not loaded on xcode13-beta with simulator 14.5

Question

Hey!

recently I did some changes to my apps to fit iOS 15 and noticed that the import of CloudKit is now require for some iCloud CoreData functions like description.cloudKitContainerOptions?.databaseScope = .private or CKFetchRecordZonesOperation.fetchAllRecordZonesOperation(). This works fine until I change the Simulator to iOS 14.5, which leading to the follow crash:

dyld: Library not loaded: /System/Library/Frameworks/_CoreData_CloudKit.framework/_CoreData_CloudKit

  Referenced from: /private/var/containers/Bundle/Application/DBD9242D-A85E-4957-948A-D770C6C6D6B5/CoreDataTest.app/CoreDataTest

  Reason: image not found

It's also replicable on real devices. I also set CloudKit.framework under the Generals-Tab and set it to optional in Build Phase. Still not working. What do I missing?

3.2k

Posted by

JoschuaWeidner

Reply

Add a Comment

Answer 1

You cannot mix applications built against the iOS 15 SDK with iOS 14.* devices or simulators.

Posted by

Frameworks Engineer

My iOS Deployment Target is 14.0 as I want to support both 14.* and 15.0 as well as under my Targets in developement Info. Thought that, in combination with conditional code via @avialable/#available, should be enough to support both, right?

—
JoschuaWeidner
That's not my understanding in this case. We made a number of changes to Core Data this year to isolate CloudKit classes from non-cloudkit clients and one of those introduces this new module. You will need to continue to build against iOS 14 SDKs if you want to deploy to iOS 14.

—
Frameworks Engineer
I don't get it. Please clarify what you meant exactly with "build against iOS 14 SDKs" as I'm sure I'm doing it...

—
JoschuaWeidner

Answer 2

Hi did you ever find a fix for this? I'm having the same issue. I am using Xcode 13 beta 5, deployment target is set to 14.0.

Posted by

mike_at_helium

Add a Comment

Answer 3

Has anyone found a solution here? or the root cause of the problem?

This thread was initially commented by a "Frameworks Engineer" and then left unanswered with multiple people having the same problem.

Posted by

andreimatei

can be reproduced with this GitHub repo: https://github.com/andreimateiro/ios15sdkbug

—
andreimatei

Add a Comment

Answer 4

Not an answer I’m afraid, but perhaps a related problem. They’ve definitely changed something deep at the OS level which is even affecting the CloudKit syncing of apps built with the iOS 14 SDK many months ago (ie. my app!) if run on an iOS 15 device, let alone apps built with the iOS 15 SDK!

This failure of syncing started to occur when iOS 15 beta 4 was released - prior to this it was all working normally, as it did in iOS 13 & iOS 14. From beta 4 the entire structure of the console log outputs for NSPersistentCloudKitContainer changed, so something fundamental changed with CloudKit at this time.

In my case, it seems it has trouble syncing Core Data relationships and NSPersistentCloudKitMirrorringDelegate gets stuck in a loop causing CPU & RAM consumption to rise uncontrollably, with the OS killing the app shortly afterwards. No syncing occurs. My Core Data structure has not changed since iOS 14 and my app synced (and still does) just fine on iOS 14 devices.

Other than a reply from a ‘Frameworks Engineer’ briefly, I’ve had no communication from Apple, nor an acknowledgement that this is even an issue, including in my Feedback report - nobody from Apple has replied there. It’s extremely disheartening particularly as they’ve released the Release Candidate and it’s still broken. I’m going to have many very upset users (medical professionals) in a few days.

If it didn’t affect Apps built 6 months ago with the iOS 14 SDK I wouldn’t really be that concerned as I could just hold off my iOS 15 release until this is fixed, but it’s breaking existing apps which is totally unacceptable.

Here’s my thread on it: https://developer.apple.com/forums/thread/687877

I’ve submitted a Technical Support Incident (at my expense) now that iOS 15 is ‘final’ in the hope that someone will acknowledge this!

Posted by

nitramluap

that's awful. I had lost of problems with CoreData + CK in the past, now this is truly disturbing :o

Home you get something back from TS, I will monitor your thread as well

—
andreimatei
This is worse than "awful" -- I have limited time to work on my ios14 app, which was working fine --- now I am stuck with some sort of "dyld: Library not loaded: /System/Library/Frameworks/_CoreData_CloudKit.framework/_CoreData_CloudKit"

I did not give permission to Apple to upgrade my XCODE, now I get this run time error with NO guidance how to fix.

The lame Cloudkit architecture is fragile enough, without the Cloudkit/CoreData folks constantly mucking around with the underlying code. It is bad enough they are using design patterns we proved untenable way back in the early 80's, I can see why serious apps use 3rd party persistent storage and avoid this nightmare Apple has created.

Just an FYI -- since Apple uses this same flawed architecture for the MAIL app, the MAIL app is way too dangerous to use for business/commercial purposes. Constantly getting emails where some or all of the email content is irrevocably missing -- and with the change notification architecture it is impossible to get those email messages repaired. So, Apple happily (Naively) considers all the emails sync'd between devices, even when Apple MAIL has delivered damaged email content. Totally Unprofessional. They need to quit following some theoretical design pattern from some college professors and get back to the reality of real-world use cases AND need cases. Ugh. Kids these days....

—
CharlesK

Add a Comment

Answer 5

I’ve not found a solution either. Since I switched to the Xcode 13 RC, all of my beta testers are now crashing! This is holding up a release.

Posted by

badepaz

I don't recall upgrading to Xcode 13, but unfortunately that is what I am now stuck with -- ruined my window to work on my app -- once again, dead in the water dealing with very unprofessional handling of the Cloudkit/CoreData eco-system. They need a total re-write of the persistence architecture and/or get better management over their Cloudkit and CoreData teams.

—
CharlesK

Add a Comment

Answer 6

At the moment, you'll need to remove this line:

description.cloudKitContainerOptions?.databaseScope = .private

since .private is the default, it isn't doing anything. If you need to use .public, you'll have to set it from an ObjC thunk. If you file a feedback assistant issue, ADC will contact you directly when it's fixed, or get you some assistance to work around it.

Posted by

Frameworks Engineer

Add a Comment

Answer 7

To use the private database scope, you can work around this issue by deleting the code to set the databaseScope property on the NSPersistentCloudKitContainerOptions object since it is the default value.

To use the public database scope, you can work around this issue with KeyValueCoding:

let options = NSPersistentCloudKitContainerOptions(containerIdentifier: id) options.setValue(1, forKey: "databaseScope") // .public == 1 // options.databaseScope = CKDatabase.Scope.public description.cloudKitContainerOptions = options

Posted by

Frameworks Engineer

thank you!

—
TimARTORG
Those changes (directly setting the databaseScope key did NOT work for me.

I still get the following error:

"dyld: Library not loaded: /System/Library/Frameworks/_CoreData_CloudKit.framework/_CoreData_CloudKit"

even after re-adding the Cloudkit framework.

—
CharlesK
CharlesK, are you referencing 'NSPersistentCloudKitContainerOptions.databaseScope' somewhere else ? Please file a bug report and post the FF #

—
Frameworks Engineer

Add a Comment

databaseScope lead to dyld: Library not loaded on xcode13-beta with simulator 14.5

Replies