I've since submitted this as FB9489988

Just confirmed it's still happening on beta 6.

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?

This is still happening for me in Beta 7 :(

Excellent, thanks so much for the response! It makes me feel much better to know y’all are actively working on this. I’m happy to provide any additional information you might need, just let me know.

I spent quite a while testing this over the last few days and I’ve found the issue to be something with enumerating relationships. My app is a music app, so I have an Entity for Album, Artist, Genre, etc. Artist and Genre have a one-to-many relationship to the Album entity. If I create all of the objects in CoreData (2500 Albums, 800 Artists, 250 Genres, on my test device) but DO NOT link any of the relationships, everything is able to successfully sync up to iCloud and download down. If I link only the Artists, syncing is also successful. No Artist has more than 5 Albums linked. Once I link the Genres to Albums, however, the crashing begins. I started playing around with this and found that if I limit the maximum number of Albums linked to a Genre to under 15, syncing is successful. If instead I make the limit 20, the crashing issue comes back. I’m really hoping beta 8 addresses this. Starting to get quite nervous as the release approaches!

Same behavior in beta 8 for me.

I submitted a feedback for this several weeks ago and have provided sysdiagnoses and exports of the store files: FB9489988

Other than the response from a Frameworks Engineer in this thread just a few minutes after your post, no I hadn’t heard anything since 8/12 when Apple responded to my feedback asking for store files, like they asked you. After the problem wasn’t fixed as of beta 8, I started working on my own sync engine that writes backup files to iCloud Drive via the UbuiquityContainer APIs. I’m doing everything I can to have it done by the iOS 15 launch date but if it doesn’t seem like I’m going to and this crash still isn’t fixed in the GM I’m just going to submit an update that disables sync in 15 until my sync engine is ready for primetime. It’s a crummy solution but it doesn’t seem like I have another option.

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.

@nitramluap If you aren't sure how to provide Apple with some of the data they've requested, I'm happy to try to clarify how.

Thanks for the response! I am pretty sure that I am, but I'll go back through everything with a fine toothed comb. Just to confirm, your understanding is that if I'm ending the background task correctly and in the allotted time, my app shouldn't be killed at the conclusion and will remain the Now Playing app?

Aha! This was it after all. For whatever reason, multiple "MPMusicPlayerControllerPlaybackStateDidChange" notifications were being sent on pause, which meant that the backup job was being kicked off multiple times, starting a new background task each time. Since the task was in progress, a later stage didn't run, which meant the additional tasks were expiring. Now that that's all cleaned up the app indeed stays as the now playing app after the task ends. Many, many thanks, @eskimo!

This was my experience on Big Sur -- I had been hoping it was fixed in Monterrey but hadn't had a chance to test. Are you on the latest OS @oxigenator?

Thanks for the clarification, Joe. Fingers crossed there will be some good news at this year's WWDC about being able to bring MusicKit apps to the Mac!