Reported as FB14323934

Yes, same here. Related bug, calling .count on a Query's array seems to load all models, including the large items in external storage, causing a memory overflow. Calling .count on iOS 17 is fast and inexpensive. Jeff

I found that I had to remove ALL usage of @Environment(.modelContext) private var modelContext to eliminate all SwiftUI/SwiftData background crashes since 17.4. See https://developer.apple.com/forums/thread/744194?answerId=788019022#788019022

Same here. Starting with iOS 17.4, my app waking in the background would crash when accessing an invalid modelContext environment variable. Even moving the app into the background with recent SwiftData changes (especially changes to Relationships) caused the same crash. My guess is that an autoSave is triggered? Easier to reproduce on iPad. My workaround, based on the helpful discussion above.... Create a globally accessible modelContext and modelContainer. In my case I created a singleton "DataCenter" object created in the first line of the app's init. Remove ALL @Environment(.modelContext) private var modelContext from your project Add the modelContainer modifier to the WindowGroup, in my case WindowGroup{...}.modelContainer(DataCenter.shared.container) Use that global context directly when needed, such as DataCenter.shared.context.insert(...) Half measures didn't work for me, such as just removing the modelContext environment variable from the root view. Had to **** it entirely in the project.

Any SwiftUI in your app @agnel_joseph ?

Fixed by Apple on the evening of May 1

Seeing the same bug on 17.4.1 iPads too. Can't reproduce on Mac or iPhone

On One-to-Many relationships, Apple's sample code typically shows the @Relationship macro on the One side. Although it's supposed to work either way, I'll bet it was tested more thoroughly on that direction. And I've certainly found the @Relationship macro to have some fragile quirks.

Thanks @mikrasya for documenting this. I have the same problem, but already have inverses set. Removing inverses didn't help either. (I've read that inverses aren't necessary when using iCloud, that they are automatically inferred). 🤷🏼‍♂️ I sent in a question to Developer Tech Support, and will repeat any solution here for you and the other five who've marked your posting with "Same Here".

I'm hunting the same bug. Didn't see it until recent versions of watchOS 9. I'll be sure to post something here if I figure it out.

Same. I implemented the Complication controller in the watch app, and set ClockKit Complication - Principal Class to $(PRODUCT_MODULE_NAME).ComplicationController in the app plist. It's never called.

You'll find many good quality mockups of older devices here, courtesy of Facebook https://design.facebook.com/toolsandresources/devices/

Same issue here. Same Xcode and OS versions, on M1. I tried removing and re-adding the package, but that didn't fix it.

@t9mike, How are you able to add the new sizes to the complication assets? The template in xCode 13 is not updates for the 41 and 45 sizes.