@John-Doe Cloud builds and archiving are working for me now, after some random failures this morning. Hope it's cleared up for you.

I'm also seeing random failures today at the very end of builds, when exporting the archive. Seems like after yesterday's outage, things aren't quite right yet.

A flip side of @gwachobt's problem... today some configuration changed on Xcode cloud so that Latest Release and Latest Beta or Release is back to 15.4. Devs with Xcode 16 projects need to select it from the Release Versions section of the Menu, then remember later to set it back to Latest Release when the dust settles.

The documentation, and Quinn's Fight article, imply that an App Store distribution of a native Mac app with an iOS-style app group will work, due to some manual approval by app store reviewers. Can anyone verify that?

@Gil and @max_us I just gave up on SwiftData and reverted to Core Data. A pretty painful few days on a large app, but in the end it runs great on the fall OS's, and I have the convenience of FetchedResultsController for non-view code. I have a gut feeling this won't be fixed in the fall releases.

@malc Interesting idea. I don't think I'm initing twice. A SwiftData engineer acknowledged the corrupted modelContext environment variable as a known bug. Container initialized in a singleton... @MainActor struct DataCenter { static var shared:DataCenter = DataCenter.init() public let container: ModelContainer public let context: ModelContext init() { let schema = Schema([ Folder.self, Reminder.self, DateReminder.self, LocationReminder.self ]) container = try! ModelContainer(for: schema, configurations: [ModelConfiguration(isStoredInMemoryOnly: false)]) context = container.mainContext } } Setting the container... WindowGroup { ContentView() } .modelContainer(DataCenter.shared.container) I don't reference the modelContext environment variable anywhere. In code that needs the context, I always reference the singleton... let folder = Folder(name: newFolderName) DataCenter.shared.context.insert(folder) It's been working fine, until iOS 18 came along. But I think my many problems with SwiftData in 18 have nothing at all to do with this container usage. But I've been wrong before.

Ziqiao, thanks for the fetchCount workaround. Unfortunately I've found another case. Simply iterating over a @Query with ForEach causes the same problem. No call to count. Your suggestion to make large items in externalStorage reference instead does help in this case too. But it points to a serious problem in SwiftData, where Query macros become useless in non-trivial apps. (I'm pretty sure that the problem does not happen when iterating or counting an array representing a one-to-many relationship. Hard to be sure because I can't get the app running well enough to exercise in iOS 18) I do hope that it's fixable, because this is not how SwiftData is supposed to work, and everything works fine on iOS 17.

This seems a lot like a bug that was introduced to SwiftData around the 17.4 timeframe. The modelContext environment variable becomes corrupted as the app becomes de-active, then when in the background some SwiftData/SwiftUI activity, relying on that variable, crashes. With autosave turned off, that background activity doesn't happen, but you even when that's turned off you'll probably be bitten eventually. The solution is to avoid relying on the modelContext environment variable, instead setting the modelContainer manually on a root view. See these threads for a deeper discussion : https://developer.apple.com/forums/thread/750084?answerId=52256025#52256025 https://developer.apple.com/forums/thread/744194?answerId=788019022#788019022

@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?