A Summary of the WWDC25 Group Lab

Sadly there is not much change in SwiftData in WWDC25 while fatal issues like this one must be fixed as soon as possible. Just to allow SwiftData works normally.

@DTS Engineer Thank you, but I read all the threads and didn't find any options for fixing it. Electron likely set up this flag by default, since we didn't configure the app group. Can you give me some advice, especially for my case? Electron + JS application. Thank you so much.

It’s a documented limitation that Mac apps can’t be transferred if they ever used an app group. See the extended discussion on this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Im seeing the same thing, started on 2025-08-13. Newly pushed build were no longer being added to an Internal Testing group (configured for automatic distribution)

My team is experiencing the same issue. Additionally, newly approved testflight builds are displaying a count for invites, but no internal groups have been automatically assigned or has anyone received invitations. This has been going on for ~3 days.

I have similar problem. I uploaded a version to testflight with an internal group which build distribution set to automatic. I tried to change text of the Test Details. I tried to add a dummy group with manual build distribution, and adding it to the version group. Still not working. I tried to add/change test information for the app. Not working Please help

I guess this is one way to do it. TLDR; Create a resolver view to wrap your content views. Use an environment closure to pullback values from it. Re-distribute these values using the containerValue API to propagate value to subviews. Use .onChange(of: subview.containerValues.foo)API on subview to be notified of changes. Let's say we want to design an API like that: // MARK: Client Stepper { StepView { Text(Becoming spartan) } content: { FooView() } StepView { Text(Dying in glory) } content: { BarView() } } where FooView, BarView could access to a complete closure through environment to notify it finishes (same way as @Environment(.dismiss)): struct FooView: View { @Environment(.isComplete) private var isComplete var body: some View { VStack { Text(This is the part where you become a spartan) HStack(alignment: .bottom) { Rectangle() .fill(Color.blue.gradient) .frame(width: 50, height: 25) Rectangle() .fill(Color.cyan.gradient) .frame(width: 50, height: 10) Rectangle() .fill(Color.pink.gradient) .frame(width: 5

I don't understand. Aren't all these tools you mention (Zombies instrument, ASan, Main Thread Checker etc.) meant to be run in Xcode or Instruments? Or are you saying I should enable some compiler flag in my production build? They're intended to run in your development build. Let me jump back to what you're saying here: since the crash reports are downloaded by Xcode from other users and I cannot reproduce it myself... What you're saying here is testing in Xcode won't help because I can't reproduce the issue. The problem with that statement is that it misunderstands how the tools above actually work. They don't just provide better diagnostic data about a crash that would otherwise occur, they actually CREATE crashes that would otherwise NOT occur. Jumping back to my description here: However, what the Zombies instrument actually does is modify the dealloc method so that freeing an object doesn't ACTUALLY free that object, but instead replaces it with an intentionally invalid object (the zombie). That means th