NSPersistentCloudkitContainer Memory Leak -> Crash? (iOS 15 beta 4 & 5)

Background

I have an established app in the App Store which has been using NSPersistentCloudkitContainer since iOS 13 without any issues.

I've been running my app normally on an iOS device running the iOS 15 betas, mainly to see problems arise before my users see them.

Ever since iOS 15 (beta 4) my app has failed to sync changes - no matter how small the change. An upload 'starts' but never completes. After a minute or so the app quits to the Home Screen and no useful information can be gleaned from crash reports. Until now I've had no idea what's going on.

Possible Bug in the API?

I've managed to replicate this behaviour on the simulator and on another device when building my app with Xcode 13 (beta 5) on iOS 15 (beta 5).

It appears that NSPersistentCloudkitContainer has a memory leak and keeps ramping up the RAM consumption (and CPU at 100%) until the operating system kills the app. No code of mine is running.

I'm not really an expert on these things and I tried to use Instruments to see if that would show me anything. It appears to be related to NSCloudkitMirroringDelegate getting 'stuck' somehow but I have no idea what to do with this information.

My Core Data database is not tiny, but not massive by any means and NSPersistentCloudkitContainer has had no problems syncing to iCloud prior to iOS 15 (beta 4).

If I restore my App Data (from an external backup file - 700MB with lots of many-many, many-one relationships, ckAssets, etc.) the data all gets added to Core Data without an issue at all. The console log (see below) then shows that a sync is created, scheduled & then started... but no data is uploaded.

At this point the memory consumption starts and all I see is 'backgroundTask' warnings appear (only related to CloudKit) with no code of mine running.

CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExporter analyzeHistoryInStore:withManagedObjectContext:error:](501): <PFCloudKitExporter: 0x600000301450>: Exporting changes since (0): <NSPersistentHistoryToken - {
    "4B90A437-3D96-4AC9-A27A-E0F633CE5D9D" = 906;
}>

CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExportContext processAnalyzedHistoryInStore:inManagedObjectContext:error:]_block_invoke_3(251): Finished processing analyzed history with 29501 metadata objects to create, 0 deleted rows without metadata.

CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _scheduleAutomatedExportWithLabel:activity:completionHandler:](2800): <NSCloudKitMirroringDelegate: 0x6000015515c0> - Beginning automated export - ExportActivity:
<CKSchedulerActivity: 0x60000032c500; containerID=<CKContainerID: 0x600002ed3240; containerIdentifier=iCloud.com.nitramluap.Somnus, containerEnvironment="Sandbox">, identifier=com.apple.coredata.cloudkit.activity.export.4B90A437-3D96-4AC9-A27A-E0F633CE5D9D, priority=2, xpcActivityCriteriaOverrides={ Priority=Utility }>

CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate executeMirroringRequest:error:](765): <NSCloudKitMirroringDelegate: 0x6000015515c0>: Asked to execute request: <NSCloudKitMirroringExportRequest: 0x600002ed2a30> CBE1852D-7793-46B6-8314-A681D2038B38

2021-08-13 08:41:01.518422+1000 Somnus[11058:671570] [BackgroundTask] Background Task 68 ("CoreData: CloudKit Export"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.

2021-08-13 08:41:03.519455+1000 Somnus[11058:671570] [BackgroundTask] Background Task 154 ("CoreData: CloudKit Scheduling"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.

Just wondering if anyone else is having a similar issue? It never had a problem syncing an initial database restore prior to iOS 15 (beta 4) and the problems started right after installing iOS 15 (beta 4).

I've submitted this to Apple Feedback and am awaiting a response (FB9412346). If this is unfixable I'm in real trouble (and my users are going to be livid).

Thanks in advance!

  • To date with the official release of iOS 15 & macOS 12 using Xcode 13.2.1 this is still an issue. The problem is still reflected with the mirror delegate as the source of the leaks on the macOS where the app is terminated during a cloud sync when it goes over 120 Gigs of ram and on the phone.

Add a Comment

Accepted Reply

Quick Update

(Note: I've not received any official update from Apple yet)

I've just installed iOS 15.2 (beta 2 19C5036e) today and have noticed that data now seems to be uploading from my App (App Store version) when previously it would just sit there... then crash. If I look under iCloud -> Manage Storage -> MyApp I can see the figure for data stored going up slowly.

Better yet, I'm seeing data come DOWN to my other devices now.

I'm not near my development setup so I can't test this on a physical device to see what the console output shows, but I'll try and do this tonight on my iPad. I'll ingest my large external backup file into Core Data and see if it uploads to iCloud and report back.

There is no new update for Xcode yet so I don't think we can test with iOS 15.2 (beta 2) in a simulator environment. I'm not going to count my chickens just yet...

  • Definitely seems to be resolved with this beta so the official 15.2 should hopefully fix the issue for all our users.

  • The official word from Apple is that it's still marked as 'unresolved' but it's quite possible that it has been addressed in the second beta of 15.2 but they're not yet 100% sure it's ready for release. Still... promising developments I think. 🤞🏻

  • Still no official word from Apple but all my testing with iOS 15.2 (beta 2) is showing it to be working as expected. Hopefully 15.2 will be released soon and this will be marked as resolved.

Replies

I am seeing very similar behavior on iOS 15 in my app. Installing it fresh on iOS 14 allows it to upload the initial data and start syncing, but doing the same on the latest iOS 15 beta causes the app to crash while in the background using 100% CPU, and it never manages to upload any data.

I've submitted this as FB9489988, which also references an issue I've seen on both iOS 14 and iOS 15 around cpu_usage_fatal crashes when syncing with iCloud.

  • Just confirmed it's still happening on beta 6.

  • Excellent, thank you for the feedback and for submitting a report to Apple as well. I have had an engineer reach out but after sending them more information, I'm still waiting to hear back. It's not fixed in beta 6 (although I think this was a quick beta release) so fingers crossed for beta 7!!

  • I'm currently running an iOS15 beta 5 simulator after ingesting my backup data to Core Data (700MB) it shows "Finished processing analyzed history with 29581 metadata objects to create"... and nothing after that. Currently, it's sitting at 4GB of RAM consumed, which would have crashed a physical device ages ago. Something is broken with NSPersistentCloudkitContainer since beta 4.

Here is a screenshot of the call tree from Instruments and what's chewing up the RAM. There is something broken with the NSCloudKitMirroringDelegate since iOS15 beta 4 (and still not working in beta 6).

Please file a feedback report with your app container (which will include your store file) and this instruments trace.

  • Thank you for commenting. This information is in my feedback (FB9412346) report. I have not received a reply from Apple in this report yet.

  • Neither your application container nor your instruments trace appears to be attached to that feedback. We will need your persistent store files to investigate this issue further, can the instruments trace from your reproduction would be helpful.

  • OK, thank you. Can someone from Apple please reply to that feedback to explain how to do any of that because I'm not sure what you mean and I want an audit trail of the process. I'm a developer as a hobby, not a profession (I'm an MD), so excuse my ignorance here. Nobody from Apple has yet replied to me within the Feedback app which is why I posted this here and I see others have the same issue. My data also contains sensitive information (patient & surgical data) so I'm not keen on sending that to any third party so I need to know what to send and how to do it safely. Regards, Paul

Same issue with my app with iOS 15. After a fresh installation, after a couple of saves, the data stops syncing with iCloud. This can be seen on the iCloud Dashboard. No data is sent or received. They are saved only locally. The most interesting thing is that the size of the application data in the system settings stops changing. I can delete and add data - the displayed size remains the same (it is unclear where the changes occur at all). My application does not crash. Only there is no synchronization with iCloud. On iOS 14 everything syncs perfectly and quickly.

  • Thanks for the reply - good to know there are more of us out there. My application only seems to crash (due to RAM consumption) when the sync required is large (eg. after restoring data from an app generated backup file). It's as though it's trying to do the entire sync as a single entity instead of breaking up the cloud sync into small chunks & processing them, like it did previously (iOS 14 & iOS 15 (beta 3 & below). I think Apple is investigating this, but I've not had a formal confirmation. I tried using Code Level Support in case it was something in my code that was broken, but they said 'Apple's Investigating this' and to keep checking the Feedback app. So make sure you submit a feedback ticket! 🤓

  • It occurred to me earlier that one “odd” thing about my setup is that the store lives in an AppGroups shared location rather than the default location. Is that true for you as well?

  • In the iOS Simulator, the path to my store is the default location (Library -> Application Support -> xxxx.sqlite) and this has not changed since I added NSPersistentCloudkitContainer support almost 2 years ago. In fact, I've not changed any Core Data or NSPersistentCloudkitContainer code in 18 months!

I bought a new iPad and using my app (downloaded from the App Store, not via Xcode) I can confirm that:

  • Data created/modified on iOS 14.7.1 successfully syncs bidirectionally on iOS 14.7.1 devices
  • Data created/modified on iOS 14.7.1 successfully syncs down only to iOS 15 (beta 4, 5 or 6) devices
  • Data created/modified on iOS 15 (beta 4, 5 or 6) does not upload to iCloud (and eventually crashes the App)^

In order to see the iOS 14.7.1 -> iOS 15 (beta) changes appear I have to reload the app as the download seems to occur before the upload. Once the upload task 'starts' (it never really actually uploads anything), it prevents any changes from downloading.

I've made no changes to my code, data model or NSPersistentCloudkitContainer related methods and it was something that abruptly appeared after installing iOS 15 beta 4.

^ basically any changes made on the device after iOS 15 (beta 4) was installed have not ever been sent to iCloud.

  • This is still happening for me in Beta 7 :(

  • Yes, happening for me on beta 7 also... however, I'll reserve judgement until Xcode beta 6 so I can see what's happening. It is possible that on my iOS 15 (beta 7) device running my App Store app that all the 'old' exports are still queued, causing the failed syncing -> crash. Fingers crossed that's the case. I'm hesitant to delete & restore all my data until I can test it in the simulator first.

  • Still happening on beta 8. First change of data on iOS 15 device stops sync for this device in and out. Syncing for iOS 14 devices keeps on working. Release is near. It's frustrating...

Found this potentially related thread: https://developer.apple.com/forums/thread/688792?page=1#686082022

I’ve not hit these errors with the macOS version (not tried it), but it looks like it’s the same issue with NSCloudKitMirroringDelegate gobbling up available resources and crashing.

Just installed the RC versions of iOS 15 & Xcode 13 and it's still broken. After ingesting external data into my Core Data store & saving the context, I get messages in the console that suggests something will happen... then the memory & CPU use keeps climbing until it crashes. I've tried

  • Resetting the Development Environment
  • Erasing & Resetting the Simulator

At the end of my data import (from an external backup file), which saves to Core Data just fine, the console shows this:

CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExportContext processAnalyzedHistoryInStore:inManagedObjectContext:error:]_block_invoke_3(251): Finished processing analyzed history with 30421 metadata objects to create, 0 deleted rows without metadata.

2021-09-15 07:27:25.213430+1000 Somnus[37796:7522408] [BackgroundTask] Background Task 99 ("CoreData: CloudKit Export"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.

No syncing occurs and all that happens is CPU & Memory consumption goes through the roof as it has done since iOS 15 beta 4. Everything you see here is 100% NSCloudKitMirroringDelegate - it's insane, especially considering the data that needs to sync is only about 500MB. No code of mine is running at all - the App is just idling!!

This is totally unacceptable for a RC version and it's breaking my existing App Store application so when my users upgrade from iOS 14 -> 15 it's going to stop syncing (and god knows how out-of-sync it's going to get). My App is in use by medical professionals and they're not going to be very happy with me. I so disappointed with this I've effectively stopped prepping the next update of my app. This is just awful.

  • I've had it running now for 5 minutes and it's now consumed 4.8GB of RAM (Simulator) and still going. If this was a real device it would have simply crashed ages ago... with my users losing inputted data potentially. So now that it's RC, are you saying this is not a problem Apple? NOBODY has replied to me in my Feedback about this. Where do I turn now??

  • nitramluap

    I think I figured out the problem (in my case at least). So, initial state:

    iOS 14 and MacOS BigSur: Both for Development (installing app from Xcode 12.5.1 to device) and Production (installing app from TestFlight) synchronization works very well. Quick and accurately.

    iOS 15: For Development environment (installing app from Xcode 13 RC to device) synchronization work ALSO well. BUT for Production environment (installing app from TestFlight, app was submitted by both - previously Xcode 12.5.1, and now Xcode 13 RC) synchronization FAILS. It works just BEFORE first change of data on iOS 15 device. At first data changes on iOS 14 devices and MacOS BigSur are available on iOS 15 device, but then after first change of data on iOS 15 device it becomes out of sync - no changes are going to iCloud and no changes are coming from iCloud. At the same time synchronization for iOS 14 devices and MacOS BigSur keeps going on without issues...

    Because there was difference in Development and Production environments behavior, I've looked at my Schemas in CloudKit dashboard. There was a new field in Development Schema - CD_image_ckAsset, that wasn't there before (and I didn't do anything to add this field). I've Deployed changes in Schema in Production. After that my TestFlight app becomes alive in terms of synchronization on iOS 15 devices. Try to pay attention to Schema in CloudKit dashboard. If in your case you can't go even with Development environment, there also might be problems with fields in Schema.

  • Popping in to confirm that I'm also still seeing the issue on the iOS 15 RC. My Development/Production schema are correct and nothing has changed for the duration of the beta. Glad to hear that was the fix for you, though, @Alex_Vorobiev.

    As I mentioned in some comment somewhere, I ended up making plans to drop NSPersistentCloudKitContainer once this issue wasn't fixed in beta 8. Even before this iOS 15 bug made it unusable for me, it was causing intermittent background crashes on iOS 14, especially for users with lots of relationships between entities. I guess it's possible that my CoreData model is overly complicated or something. Or maybe most people use other solutions like Firebase?

    Now my cloud syncing is handled by a custom built sync engine that writes out changes to .json files I store on the user's iCloud Drive. Every 5 minutes or so it checks for updates in the cloud, then checks for unsynced updates locally. It took many many hours to write, but I'm happy to have much more control over the process than the black box of NSPersistentCloudKitContainer. Maybe I'll revisit this decision later down the line, but after the radio silence all summer I didn't feel like I had another choice.

Apple definitely did something with CloudKit. In these threads there are also some strange issues with iOS14/15 support: https://developer.apple.com/forums/thread/682925, https://developer.apple.com/forums/thread/690044 Framework Engineer wrote this: "We made a number of changes to Core Data this year to isolate CloudKit classes from non-cloudkit clients". I think it's all somehow connected with each other.

  • This is interesting, and concerning. The Apple Engineer states “You cannot mix applications built against the iOS 15 SDK with iOS 14.* devices or simulators.” Which is all fine & dandy… BUT I’m seeing sync failures with an existing App Store App (built with iOS 14 SDK months ago) failing in the same way. This is a deep OS level change which affects older applications and that is why I’m so concerned. Existing, working apps are going to break in a few days.

  • If I get a reply from my TSI I’ll report back here

  • these issues are different, and those threads have been updated

Add a Comment

FB9412346 should be fixed in the next iOS 15.1 beta seed.

  • Thanks for the reply - I wait with bated breath as I'm starting to get complaints from my users!!🤞🏼😬

  • fwiw, I currently anticipate this to be next week

  • Thank you - downloading now! Will report back soon 😬

Sorry, Apple... this is still broken in iOS 15.1 (beta 2)

The CPU & RAM usage is still excessive and no syncing occurs at all. I've replied to my TSI in the hope I can get someone to look into this as a matter of urgency. I now have users running iOS 15 who are no longer seeing their data syncing via iCloud, resulting in a terrible user experience, using my app downloaded from the App Store which has been unchanged since iOS 14.

Whatever Apple did in iOS 15 beta 4 to NSPersistentCloudKitContainer, they broke it badly. Maybe users who don't have complex databases aren't seeing this problem, but the whole point of NSPersistentCloudKitContainer is to sync a Core Data store with complex relationships (and besides, it works just fine on iOS 13 & iOS 14!).

My testing setup

  • Monterey (beta 8)
  • Xcode 13 (13A233) non-beta
  • Testing on iPhone 13 Pro with iOS 15.1 (beta 2)

Preparation

  • Deleted iCloud data for my app
  • Deleted my app from the device (App Store download)
  • Rebooted device
  • Reset the iCloud Container Development Environment
  • Built & run my app using Xcode on my iPhone 13 Pro

Results

I ingested an external backup file into my app, which saved to Core Data perfectly without any errors. This backup file restores the user database which contains lots of many-to-many and one-to-many relationships (the entire POINT of using Core Data).

After the import and the context was saved, the console shows this:

CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2530): <NSCloudKitMirroringDelegate: 0x2806a4dd0>: Observed context save: <NSPersistentStoreCoordinator: 0x2816b0070> - <NSManagedObjectContext: 0x2806ac1a0>
CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2530): <NSCloudKitMirroringDelegate: 0x2806a4dd0>: Observed context save: <NSPersistentStoreCoordinator: 0x2816b0070> - <NSManagedObjectContext: 0x2806ac1a0>
CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2530): <NSCloudKitMirroringDelegate: 0x2806a4dd0>: Observed context save: <NSPersistentStoreCoordinator: 0x2816b0070> - <NSManagedObjectContext: 0x2806ac1a0>
CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2530): <NSCloudKitMirroringDelegate: 0x2806a4dd0>: Observed context save: <NSPersistentStoreCoordinator: 0x2816b0070> - <NSManagedObjectContext: 0x2806ac1a0>
CoreData: debug: CoreData+CloudKit: -[NSCloudKitMirroringDelegate managedObjectContextSaved:](2530): <NSCloudKitMirroringDelegate: 0x2806a4dd0>: Observed context save: <NSPersistentStoreCoordinator: 0x2816b0070> - <NSManagedObjectContext: 0x2806ac1a0>
CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExportContext processAnalyzedHistoryInStore:inManagedObjectContext:error:]_block_invoke_3(251): Finished processing analyzed history with 19785 metadata objects to create, 0 deleted rows without metadata.

Then the CPU & Memory usage starts to rise as before, although not as dramatically, so it takes longer to crash, giving the impression that this is 'fixed', yet absolutely no data is being transmitted from the device - zero syncing is occurring. After several minutes of no activity (other than rising RAM consumption) iOS kills the app for 'using too much memory' - awesome...

What Now?

So the question is what on earth do I do now?

It's been months for this to be acknowledged and now we're being told it's 'fixed' when it's just as broken. What was changed in iOS 15 beta 4 that totally wrecked this... months ago?

If this won't be fixed then I have no choice but to abandon my apps and stop development. I really hope this isn't how it's going to end...

  • It'd be helpful to put this information in your bug report include these Instruments trace files. A sysdiagnose after reproducing too. If you can provide this backup file: "I ingested an external backup file into my app, which saved to Core Data perfectly without any errors. This backup file restores the user database which contains lots of many-to-many and one-to-many relationships (the entire POINT of using Core Data)." that would help immensely. The stripped down data you previously furnished doesn't reproduce this.

  • It's the same (de-identified) backup file I've sent previously (to my Feedback FB9412346). The biggest frustration is that there is no conversation going on in that Feedback thread of mine - I feel like I'm yelling into the void - so I have to keep coming back here for any interaction with Apple - thank you at least for replying here! I just need someone at Apple to download my app, restore that backup file, and observe what (doesn't) happen(s).

    Even in my TSI I've only received vague replies such as 'it will be fixed in beta 2' but I'm not able to engage with anyone directly to get to the bottom of this quickly. My issue is that this 'backup restore' and subsequent sync to iCloud worked just fine in iOS 15 beta 3 and before (iOS 13 & iOS 14) so something changed... and my app didn't (at least none of that code). It's the same version that's been syncing for a year on iOS 14, etc. If my app no longer syncs, it's going to be the end of it unfortunately. 😔

  • As the screenshots above show, there appears to be an order of magnitude difference between what you were seeing and what you are seeing on the latest beta. It would be really helpful to include a new Instruments memory trace and a new sysdiagnose after reproducing.

    The backup file in FB9412346 has all the images and assets stripped, so it's not self evident we're looking at the same things. It'd help to add instructions with very small words to using your application to ingest the backup and reproduce the issue.

This is all very confusing to me...

...and it's quite possible that this 'bug' is something I'm doing wrong when ingesting data from a backup file, despite it all appearing to save to Core Data just fine. But why now though? Why has it been working just fine for almost 2 years without modification?

Backup Restore Process

The backup file that my users create is a serialised dictionary file, which includes encoded data for images (if present). When I restore it, I use a private context to ingest it on a background thread, with a progress bar being updated on the main thread. As I do not want partially imported data to be incorporated into the user's Core Data store I only save the context at the end of the import when successful.

This has been working flawlessly for the past 2 years with NSPersistentCloudKitContainer, with the data syncing after the import finishes and is saved to Core Data... but was it only working by accident all this time!? Should I not be using the private context to save imported data??

Is it me? I'm quite happy to eat humble pie if it's my problem which as only appeared now because Apple has fixed something at their end and I was 'getting away with it' until now. That's why I filed the TSI (780063461) and why I really want to have a one-on-one with someone!

  • Nope... that wasn't it - same issue. Saving to the main context made no difference. It's as though NSPersistentCloudKitContainer no longer likes a massive change to the context... weird. I'll try more regular context saves (which slows everything down) to see if that makes a difference. Sigh.

  • I've had an Apple Engineer reply to me now directly with my TSI so hopefully we can get to the bottom of this. When I ingest a small external data file it imports and syncs to iCloud, but as the file size increases (and the relationship counts increases), the delay in syncing and RAM consumption increases significantly to the point where it fails to sync at all. My backup restore is effective a 'large' data file with 19,000 metadata objects - entities, relationships, etc). There is something about relationships that is grinding things to a halt, a problem which didn't exist in iOS 13 & 14.

Add a Comment

Update

While the issues is not yet resolved in iOS 15.1 beta 2 (just downloading beta 3 now), I have been very happy with the Apple Developer Technical Support Representative I contacted (via a TSI) they have been the 'intermediate' to liaise with the Framework Engineers.

Had I been trying to troubleshoot this with Apple via messages here, or through the Feedback Assistant (no two-way communication ever occurred there), it would have been a very long & tedious process as we've run into several hurdles. We've been exchanging several emails per day.

So far I've run many tests and uploaded tens of gigabytes of .trace data, etc. (some files are 60GB or more and tests that take hours to run) to get to the bottom of this. They can see their is an issue with CPU & RAM consumption and they're looking into it. This is great news. While the bug (if it's a bug) is a big concern concern, the communication aspect of resolving it was far more important to me. I no longer feel like I'm 'yelling into the void'.

It might take time to fix (that's fine) but there does appear to be something going on when trying to sync lots of relationships - either an initial sync of 'default data' or 'backup data' or when adding objects to an already large & complex (relationship-wise) database.

Syncs with fewer relationships between objects (but the same data model) seem to sync just fine, although sometimes it takes while before any data is transmitted. On earlier versions of iOS syncing would start pretty quickly, but relationships would often be the last to complete to 'finish' the sync and have the data appear correct on other devices.

It's as though it's trying to sync everything in one hit so you don't see any incomplete relationships as objects sync. In iOS 14 this wasn't the case and it took time before the data all synced and looked correct. Perhaps this is a bug related to attempting to stop this from occurring as it might confuse the end user?

The problem is that when the number of metadata objects required to sync exceeds a thousand or so (from my crude test runs), it ends up using so much CPU & RAM, it crashes the app and the actual syncing of data never has a chance to start. It also results in serious battery drain, listing my app as the cause of it!

This will be my last post on this until I hear back from Apple regarding a resolution, which might take some time. Here is a screenshot from App Store Connect showing crashes over time with my App. I last updated it 4 months ago.

You can see the moment my users started installing iOS 15 😬

  • Please do post when you hear back. I’m developing an app using NSPersistentCloudKitContainer, and while I don’t see this happening, I have a small test data size (for now) and am very interested in what’s causing this and if it’s fixed. I’d hate to release the app and see this in the wild. Thanks for all the updates.

Add a Comment

The same Issues appeared in my app. Are there any Updates regarding this?

  • Not yet. The ball is in Apple's court but they know it's an issue and they're working on it. Due to the complexity of finding the bug, fixing it, testing it and merging it with the existing update roadmap, it might take several weeks before it's fixed... but I do know that the Frameworks Engineers are working hard to sort this out. As soon as I here something official in the TSI and I can report it here, I'll let you know.

Add a Comment

Anyone tried with 15.2 beta 1 yet? :)

  • Tried with iOS 15.2 (beta 1) using a build with Version 13.2 beta (13C5066c) of Xcode. Same issue. Having said that, I was told to wait until I hear back from Apple so while it might not be fixed yet, it might come in a later beta build.

  • Just tried with iPadOS 15.2 (beta 2) and Xcode 13.2 beta (13C5066c). Seems to be resolved!

Add a Comment