I learned directly from an Apple Engineer that the owner of a share does not count against the CloudKit 100 participant limit, so 101 total individuals can collaborate.

Same. A rebuild might randomly work, or might not. I've seen this for over a week, have reported it in Feedback Assistant. I noticed that last week that the System Status page showed issues with App Processing, now fixed, but it didn't fix it for me.

Found the cause and fix, though I don't 100% understand why it's happening. The views in the VStack (PostView in the code above) contained a @SceneStorage property. Removing the @SceneStorage allows the list to scroll quickly, even with .scrollTargetLayout(). No excessive calls to .body. I'm guessing that as the scrolled views come and go, that the @SceneStorarge var was getting marked as changed, even though it wasn't, causing all other cached views to be invalidated? But how does .scrollTargetLayout cause this? Anyway, elevating the @SceneStorage to the containing view, and passing into PostView as a binding, fixed scrolling, and still gives access to that @ScensStorage var.

So sorry, I really misunderstood something. The objects are not being reinitialized. It's just that scrollTargetLayout() with this configuration causes a tremendous amount of re-rendering. My bad. Still a problem though. It still makes scrolling unusably slow, even with a small data set.

@RichLogan I see that Xcode 16.2 has been pulled from cloud configs, so Latest Version is 16.1 again. Your Mac builds should work now, as mine are.

Same here. MacOS build only. Quite an inconvenience. We want to love you #xcodecloud, please do better.

Same. Version 16.1 (16B40)

@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