@outcoldman Answering you after a few months... sorry, disabling and waiting doesn't fix it. Mine's been broken for nearly a year.

Thanks Ziqiao, for these great ideas! I've tried both, separately, in my test project.... Replacing the data property with a relationship does indeed avoid loading the images until needed. A good workaround. I'll test it in my real project to see what happens with more complexity and scale. Using fetchCount on a FetchDesciptor instead of count on SwiftData's Query array also improves things. It does not load the entire dataset to make the count. So thanks for these workarounds. Used together they may allow a SwiftData app to run normally on iOS 18. Now just thinking out loud, for myself and for fellow developers facing the same issues, strategizing about iOS 18 (and other fall 2024 os's).... Changing the image properties to relationships has these costs and risks.... I'll probably have to write a migrator, as this change seems unlikely to be handled automatically by lightweight migration. Will swift data reliably manage and discard the related items? Any different behavior from being properties? Changing the queries to FetchDesciptor has these costs and risks.... In my large app, I use the convenience of counting SwiftData's pseudo arrays all over the place. Not just in Queries, but in relationships. How much work will it be to inject FetchDesciptors everywhere? Any performance difference? Any unforeseen interactions or failures with SwiftUI views? And the big question, do I just wait a few more Betas and hope that SwiftData's iOS-17-like behavior is restored? Is the old-way I was working closer to SwiftData best practices? When do I give up and make these changes?

@Gil see https://developer.apple.com/forums/thread/761522?page=1#799145022 I was asked by an Apple contact to write this up and cross link to Feedback Assistant. Hopefully we can find a workaround.

Related report by developer Gil here... https://developer.apple.com/forums/thread/759345

@vincent123 I got a fast build and archive just now. Seems the earlier issues are cleared up? Give it a try.

Sadly there is a similar bug still present in 17.5.1, but your fix still works

It's been fixed server-side. Xcode Cloud status page was never updated to show the error or the resolution. 😐 I'm experiencing unusually long build times, maybe just demand as everyone catches up?

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 nuke 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.