I have this problem where your crash originates on the queue:com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export (serial)This might be the same problem you are speaking of.I reported it to Apple (no solution yet).But important point is: It seems to happen only in debug mode. I have released an app with NSPersistentCloudKitContainer and it does not crash in production.

Hi, is there any news on this. I have the same problem in a private library which throws the same error on macOS 10.13. What I found so far is, that for a lot of people adding the "CoreData" framework as a library to the target in question fixed the problem. But for me the problem persists. I just upgraded to Xcode 13.0 and the problem continues to exists there. I have also cocoa pods in use which might change some of the build settings and maybe it has something to do with that also? Anyone has more details on why this error is happening?

Some updates: I have searched my system for CoreData framework versions with the specified version, but found none. I have removed a lot of library paths settings to see if this helps, but to now avail. I have a new clue which I can not investigate right away, but I searched for the version number which according to the comment was and will never be used by the CoreData framework and found the following output on another web page: /System/Library/Frameworks/Foundation.framework/Foundation (compatibility version: 300.0.0, current version: 1775.118.101)  which corresponds completely regarding the version number. So I'm now assuming that this might be indicative of a problem with the Foundation Framework for some reason being called "CoreData". For me it looks like it takes the version number of the Foundation Framework but adds it as a dependency called "CoreData". And it might also be that this has something to do with the use of cocoapods, which I use in my project. When I have time again I will investigate this finding further.

Hi there, so I guess I figured it out... After understanding more about the build process I figured that there must be some library that exposes itself something like this: Load command 4 cmd LC_ID_DYLIB cmdsize 48 name /System/Library/Frameworks/CoreData.framework/CoreData (offset 24) time stamp 2 Thu Jan 1 01:00:02 197 current version 1775.118.101 compatibility version 300.0.0 After writing some scripts to find and check all the libraries on my system I couldn't find any libraries that advertised itself fitting the above. What I instead found was the following library: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.tbd The library advertised itself like this: install-name: '/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation' current-version: 1775.118.101 compatibility-version: 300 which actually looked fine. But when I inspected it further one thing caught my eye. There were entries that looked like this: symbols: [ '$ld$previous$/System/Library/Frameworks/CoreData.framework/CoreData$$1$10.9$999$_NSDetailedErrorsKey$', So there was a reference to "CoreData.framework" which I was looking for because of the previous findings. The only references in this file to "CoreData.framework" were to this single NSDetailedErrorsKeys symbol. After fiddling around with the build process and getting some more clues, I looked at my code and it actually used NSDetailedErrorsKey in one place. When I removed the reference in my code and built the app again I could verify (with otool -L) that indeed, the none-existing reference to /System/Library/Frameworks/CoreData.framework/CoreData (compatibility version 300.0.0, current version 1775.118.101) was gone in the built library. And so were the problems getting the app to work on macOS 10.13. I'm still not sure why this error occurs, but I'm pretty confident that it has to do with the symbols: [ '$ld$previous$/System/Library/Frameworks/CoreData.framework/CoreData$$1$10.9$999$_NSDetailedErrorsKey$', entries inside of the /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.tbd file. My thought is that if I use NSDetailedErrorsKey that it finds it mentioned in this file and creates this hybrid of a version number from the Foundation framework but by the name of the CoreData framework which results in this linking that is never going to resolve on "normal" systems. Looking at the file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData.tbd I can confirm that the NSDetailedErrorsKey is also defined as a symbol here (which to me seems to be the correct place since it is a CoreData symbol). So my guess would be that it is an error that the entries are also present in the Foundation.tbd file. I might file a radar about this issue, if nobody can explain why that is happening. Another option of preventing this issue from occurring might be to change the order of the included frameworks and/or the search paths so that maybe the system would find the correct CoreData.tbd file first, which also might get rid of this problem.

Hi, also stumbled across this. Although the workaround with using a binding works. It seems that there is a special function that you can use in this case. sheet(item:onDismiss:content:) You can pass a binding to the item parameter and then use that value inside of the content closure e.g. .sheet(item: $data, onDismiss: nil, content: { data in                 CustomView(withCustomData: data)             }) This basically also uses a binding. I don't know if it has more benefits but it looks like this function was especially created for passing in dynamic data. The sheet in this case will be displayed if data becomes non-nil so there is no need for an extra variable to toggle showing the sheet.

I still have an extremely slow Simulator even with 15.0 release of xCode. It is only happening on an Intel Mac. A M1 machine does not have this problem.

For me it is crashing too. I noticed at the last startup the iPhone SDK needed to be downloaded again. Maybe an update, because I had it already installed a couple of days ago and it was working. The only thing back then was that the Simulator was extremely slow on an Intel chipset. So maybe they tried to fix something there. Now its crashing at startup but I can get rid of the crash by renaming iPhoneSimulator.platform to iPhoneSimulator.platform.bak and iPhoneOS.platform to iPhoneOS.platform.bak which are both found under the path: /Applications/Xcode.app/Contents/Developer/Platforms Of course iPhone development is not possible this way. When I then just renamed them back to the normal way, one by one, suddenly there was no startup crash anymore. And also iOS builds were possible again. But the simulator is still amazingly slow on an Intel chipset.