I have never seen this crash on my devices.

I have never seen this crash on a device. I logged quite a few things and all looked pretty much as expected.

I marked this right because it had a lot of good ideas that are probably in the zone. I don't know for sure that it fixed the issue, but I agree that it was NOT a good idea to be doing all that stuff in the the completion block of code that dismisses a viewController. I moved it to the parent viewController's viewDidAppear as per the suggestion. Probably the right way to go.

NOT the correct answer. Scroll down, but thanks for your help DarkPaw you got me poking around in the right area.

Geeze Apple get this SORTED ASAP!!! The Crash Reports are piling up and I am getting a lot of ticked off customers giving negative reviews! Put out a dot release that fixes this ASAP please.

Agreed. NONE of my TestFlight builds are delivering crash reports to either Organizer or App Store Connect. totally useless.

Yes too bad Apple purchased this service. When it was a paid service (which we happily paid for) there was someone you could report issues to and they had developers assigned to maintain the service... now who knows what happens to "feedback". Oh well, one can combine the distribution of TestFlight with the Crash Reporting and logging of Firebase Crashlytics ... also free.

Not from where we sit.... see pictures below. No crash reports for ANY build in any place, not even the 20 or 30 we just generated... :)

You might not be wrong see my reply below. But I am at a loss as to how it happened. Also I do not see those errors on my Console or any of the OS_Logs I am getting from some TestFlight users now. In fact I am not seeing ANY CKERRORS for the two testers I have who are reporting the issue.... and yet not updating. ... By the way dude, thanks for the reply. Any other thoughts based on the below?!

So on the cloudkit console deploy schema changes was still available on the Development container. I don't understand that actually because I thought I read someplace that if the initialization code listed below is run then the Dev schema is deployed and that once an App runs on production using that schema that it automatically gets deployed to production? Someplace I developed a misconception. I used the deploy option and now I see the field on the production container. So THANKS!

Hi, thanks for the response, but in my original post above, I stated that on the 1 device we have seen where the issue exists we DID open the CoreData store and attempted to retrieve the "Chart" entity (what the code example is illustrating) and what we got was 0 Chart Entities returned from NSFetchRequest. The CoreData store was there but empty according to the Fetch. Now this was on a device where BEFORE the update to our software for iOS 18 there HAD been data in the CoreData store.

As you see in the code below we use the recommended approach for getting URL to datastore. None of our code creates a new store on fault intentionally? We have not encrypted the store intentionally. The App does NOT set any of the background entitlements other than Remote Notifications for Cloudkit. We only ever interact with CoreData and Cloudkit via the APIs and do not move files or copy files directly. Data migration for model changes is also via APIs and using prescribed techniques.

Ziqiao, the users complaining about data loss is growing and steady. Clearly there was a change to iOS 18 or 17 relative to the way NSPersistentCloudKitContainer handles data when the user is not using or allowing use of CloudKit. In early SDKs it was stated NSPersistentCloudKitContainer was fungible with NSPersistentContainer, now it is almost as if a user has NSPersistentCloudKitContainer options set to nil and the data is deleted. Can you confirm or provide a link to documentation confirming?