Hi I was wondering under what circumstances does @Query call body. Does it call it when the result set changes? E.g. object added/removed/moved. Does it also call when the result set is the same but a property of a model changed? I'd prefer 1, since models are @Observable my Views can handle tracking if they need to update when a property of a model changes. But I am concerned it is 2 which would cause unnecessary calls to body? E.g. a ForEach would needlessly be reinit since the model array is exactly the same. So which is it? By the way it would be useful if the docs could be updated with this important info. Thanks

I am encountering a systemic issue on macOS where NSViewRepresentable (and some native container views like Table) completely discard explicit SwiftUI animations when the state change is handled via an .onChange modifier. While the exact same reactive architecture produces fluid animations on iOS, the AppKit bridge on macOS snaps the frame updates instantly. I have filed a formal bug report for this behavior, but I want to open this up to the community to see if anyone has found a cleaner architectural workaround. The Problem When observing a state change (e.g., via @AppStorage, @SceneStorage, or local state) using .onChange, applying a withAnimation block fails to animate the underlying layer changes in an AppKit representable view. // The Reactive Pattern that breaks on macOS .onChange(of: toggle) { newValue in withAnimation(.easeInOut(duration: 0.5)) { self.targetColor = newValue ? .systemBlue : .systemRed } } The Diagnostic Anomaly If you inspect context.transaction inside the updateNSView(_:context:) method during this lifecycle pass, SwiftUI reports that the transaction is animated: func updateNSView(_ nsView: NSView, context: Context) { // Prints 'true', indicating SwiftUI thinks it's animating print("Is Animated: \(context.transaction.animation != nil)") // Result: Snaps instantly. No animation occurs. nsView.layer?.backgroundColor = targetColor.cgColor } Why It Happens (The Double-Commit) It appears that on macOS, .onChange flushes a static layout transaction to the window layer immediately upon the state mutating. By the time the withAnimation block evaluates inside the closure, the AppKit backing layer has already processed a implicit setDisableActions(true) directive. The GPU pipeline for that transaction frame is effectively closed, despite what the context.transaction metadata claims. The Low-Level Workaround To force the AppKit bridge to respect the animation intent, I have to manually drop into Core Animation inside updateNSView and explicitly veto SwiftUI's action-disabling behavior: func updateNSView(_ nsView: NSView, context: Context) { CATransaction.begin() if context.transaction.animation != nil { // Explicitly override SwiftUI's implicit frame lock CATransaction.setDisableActions(false) CATransaction.setAnimationDuration(0.5) // Hardcoded fallback match } else { CATransaction.setDisableActions(true) } nsView.layer?.backgroundColor = targetColor.cgColor CATransaction.commit() } My Questions: Is this intentional behavior due to how AppKit's layer-backed architectures handle frame integrity vs. iOS's fluid layout engine? Has anyone found a way to bridge SwiftUI's Animation type curves (like .spring()) cleanly down into the CATransaction or NSAnimationContext layer without hardcoding durations inside updateNSView? Is there a purely "Reactive" paradigm that avoids mutating state at the primary action source (e.g., forcing a Button to own the animation logic) while maintaining fluid transitions on macOS?

Hi everyone, I was watching the "Code-along: Add persistence with SwiftData" session and noticed a strange architectural choice at the end. They track model side-effects directly inside a SwiftUI View's initializer like this: init(activity: Activity, isLast: Bool, isEditing: Bool) { activity.token = withContinuousObservation(options: .didSet) { event in // ... side effects here } } This feels like a significant architectural smell. SwiftUI views are transient structures with no guaranteed lifetime—they can be initialized dozens of times a second during standard layout passes. Furthermore, if multiple views display or interact with the same Activity, this tracking work gets duplicated redundantly. I understand this is a workaround because attaching a standard didSet directly to a stored property inside a @Model class doesn't trigger cleanly due to how the macro expands back-end storage. To keep this data-logic in the model layer where it belongs, I came up with an alternative that maps a custom computed property over a real stored attribute using. Here is the pattern: import SwiftUI import SwiftData @Model class Item { // 1. Persist the actual database column under an internal property name private var _title: String // 2. Expose a public computed property to intercept mutations var title: String { get { _title } set { // Updating the backing variable automatically fires the macro's observation hooks _title = newValue updatedAt = .now // Our derived side-effect! } } var updatedAt: Date init(title: String) { self._title = title self.updatedAt = .now } } Why I prefer this over the WWDC approach: Separation of Concerns: The model handles its own data dependencies (updatedAt), meaning the View layer remains purely declarative. Predictable Execution: The mutation logic runs exactly once per write, regardless of how many views are rendering or re-initializing around the object. No Manual Observation Setup: Because _title is a real, macro-backed attribute, SwiftData’s generated access and withMutation hooks are invoked naturally when the computed property reads or writes to it. We don't have to manually manage tokens or observation blocks. What do you all think? Are there any hidden gotchas to manipulating the schema mapping via originalName like this, or is this a vastly superior layout to WWDC's view-bound observation snippet? The downside is now the SQLIte column is _TITLE instead of TITLE. Is there any workaround for that? There doesn't seem to be @Attribute(columnName: "title")

Is this the right way to pass data to a sheet for editing? struct Detail: View { ... // The single atomic source of truth for our sheet presentation @State var editorConfig: EditorConfig? // Completely encapsulated local configuration package struct EditorConfig: Identifiable { var id: PersistentIdentifier { item.persistentModelID } let context: ModelContext let item: Item } var body: some View { ... Button("Edit") { // 1. Spin up a separate scratchpad container layer let context = ModelContext(modelContext.container) context.autosaveEnabled = false // 2. Safely resolve our model inside the new isolated playground if let sandboxItem = context.model(for: item.persistentModelID) as? Item { // 3. Package it up to trigger the sheet presentation editorConfig = EditorConfig(context: context, item: sandboxItem) } } } } // 4. SwiftUI tracks value replacement accurately without ghost state bugs .sheet(item: $editorConfig) { config in // Inject the isolated context into the sheet's environment chain EditorView(item: config.item) .environment(\.modelContext, config.context) } } }

Hi in the CometCal sample they have this: @main struct CometCalApp: App { init() { let dependency = CalendarManager.shared AppDependencyManager.shared.add(dependency: dependency) } var body: some Scene { WindowGroup { CalendarListView() } .modelContainer(CalendarManager.shared.modelContainer) } } However I do not want my manager to init when I am using SwiftUI previews. FYI in SwiftUI previews the App is init but body isn't called. So I require the CalendarManager to be init lazily. Is this a valid way to achieve that: init() { let dependency: @Sendable () async -> (CalendarManager) = { @MainActor in return CalendarManager.shared } AppDependencyManager.shared.add(dependency: dependency) } If so it would be great if the API could be improved to let me just do this: AppDependencyManager.shared.add(dependency: CalendarManager.shared) Which currently fails with Main actor-isolated static property 'shared' can not be referenced from a Sendable closure Thanks!

I noticed that on iOS when I tap an already selected List row it calls the selection binding setter again. This is suprising to me because the selection value hasn't changed and results in duplicating unnecessary work to transform the data. Is this behaviour normal or should I report it as a bug? I noticed it when using custom Binding for the selection, i.e. where I implement the get and set closures myself. Thanks!

In SwiftData, how can I have class inheritance without entity inheritance? My understanding is when models are subclassed they then share the same SQLite table allowing one Query to return multiple model types. However what if we don't require that functionality and only wish to share some overridable logic. I.e. share a base class implementation with multiple @Model subclasses but each model is in it's own SQLite table. E.g. say I want a savedAt timestamp field in every model and have the logic for setting it across all models. Or do some validation that calls super to check parent implementation is valid too. Maybe the validation behaviours can be done using protocols and extensions some how? Thanks!

I noticed if I show a sheet from a List row, then remove the row the sheet isn't removed from the screen like it is if using VStack or LazyVStack. I'd be interested to know the reason why the sheet isn't removed from the screen in the code below. It only occurs with List/Form. VStack/LazyVStack gives the expected result. I was wondering if it is an implementation issue, e.g. since List is backed by UICollectionView maybe the cells can't be the presenter of the sheet for some reason. Launch on iPhone 16 Pro Simulator iOS 18.2 Tap "Show Button" Tap "Show Sheet" What is expected: The sheet should disappear after 5 seconds. And I don't mean it should dismiss, I just mean removed from the screen. Similarly if the View that showed the sheet was re-added and its show @State was still true, then the sheet would be added back to the screen instantly without presentation animation. What actually happens: Sheet remains on screen despite the row that presented the sheet being removed. Xcode 16.2 iOS Simulator 18.2. struct ContentView: View { @State var showButton = false var body: some View { Button("\(showButton ? "Hide" : "Show" ) Button") { showButton = true Task { try? await Task.sleep(for: .seconds(5)) self.showButton = false } } //LazyVStack { // does not have this problem List { if showButton { SheetButton() } } } } struct SheetButton: View { @State var sheet = false @State var counter = 0 var body: some View { Text(counter, format: .number) Button("\(sheet ? "Hide" : "Show") Sheet") { counter += 1 sheet.toggle() } .sheet(isPresented: $sheet) { Text("Wait... This should auto-hide in 5 secs. Does not with List but does with LazyVStack.") Button("Hide") { sheet = false } .presentationDetents([.fraction(0.3)]) } // .onDisappear { sheet = false } // workaround } } I can work around the problem with .onDisappear { sheet = false } but I would prefer the behaviour to be consistent across the container controls.

I gave the FocusCookbook sample project a try and FocusState is not working correctly on iOS 18. I understand the sample was originally designed for iOS 17 when it was released along side the WWDC 2023 talk The SwiftUI Cookbook for Focus. however I am suprised it no longer works on iOS 18. E.g. when I launch the app on iPhone 16 Pro simulator (Xcode 16.2, iOS 18.2 Simulator) and tap the grocery list nav bar button, the grocery sheet appears however the last entry text field is not focused like .defaultFocus is designed to do. Futhermore, if I tap the add (+) button and a new entry is added, despite the addEmptyItem() func setting the currentItemID which is the @FocusState var the focus does not change to the new text field. Is FocusState broken on iOS 18? Relevant code from GroceryListView.swift import SwiftUI struct GroceryListView: View { @Environment(\.dismiss) private var dismiss @Binding var list: GroceryList @FocusState private var currentItemID: GroceryList.Item.ID? var body: some View { List($list.items) { $item in HStack { Toggle("Obtained", isOn: $item.isObtained) TextField("Item Name", text: $item.name) .onSubmit { addEmptyItem() } .focused($currentItemID, equals: item.id) } } .toolbar { ToolbarItem(placement: .cancellationAction) { doneButton } ToolbarItem(placement: .primaryAction) { newItemButton } } .defaultFocus($currentItemID, list.items.last?.id) } // MARK: New item private func addEmptyItem() { let newItem = list.addItem() currentItemID = newItem.id } private var newItemButton: some View { Button { addEmptyItem() } label: { Label("New Item", systemImage: "plus") } } private var doneButton: some View { Button { dismiss() } label: { Text("Done") } } }

Could an Apple employee that works on SwiftUI please explain the update() func in the DynamicProperty protocol? The docs have ambiguous information, e.g. "Updates the underlying value of the stored value." and "SwiftUI calls this function before rendering a view’s body to ensure the view has the most recent value." From: https://developer.apple.com/documentation/swiftui/dynamicproperty/update() How can it both set the underlying value and get the most recent value? What does underlying value mean? What does stored value mean? E.g. Is the code below correct? struct MyProperty: DynamicProperty { var x = 0 mutating func update() { // get x from external storage x = storage.loadX() } } Or should it be: struct MyProperty: DynamicProperty { let x: Int init(x: Int) { self.x = x } func update() { // set x on external storage storage.save(x: x) } } This has always been a mystery to me because of the ambigious docs so thought it was time to post a question.

Is it normal behaviour that when I apply a .toolbar to a Group that I see duplicate buttons equal to the number of Views in the Group? e.g. Group { Text("1") Text("2") Text("3") } .toolbar { Button("Hi") { } } Results in 3 toolbar buttons appearing in the UI, like in this screenshot: If not, then I'll submit feedback about this bug but thought I'd ask first. Xcode Version 16.0 beta 6 (16A5230g) iPhone 15 Pro Simulator

Please delete this one!

I noticed the code snippets are missing from the wwdc2024 10210 video titled Bring your app’s core features to users with App Intents https://developer.apple.com/videos/play/wwdc2024/10210/ It would be useful if those could be added. I also noticed the transcript is missing from the web version but it is in the Developer app, that is odd.

I was wondering if anyone knows why the sample project uses Task.detached everywhere because it seems highly non-standard, e.g. in ContentView: .task { Task.detached { @MainActor in await flightData.load() } } Instead, I would expect to see something like: .task { flightData = await controller.loadFlightData() } Or: .task { await controller.load(flightData: flightData) } Is the use of detached perhaps an attempt to work around some issue with ObservableObject published updates?

If they had used .task they could have removed the class LocationsHandler: ObservableObject and simply done: struct ContentView: View { @State var lastLocation: CLLocation? var body: some View { VStack { ... } .task { let updates = CLLocationUpdate.liveUpdates() for try await update in updates { if let loc = update.location { self.lastLocation = loc } } } And saved themselves about 20 or so lines of code. .task was added in the year before so it isn't the case that it wasn't available to the CoreLocation team yet. To wrap async/await in a Combine's ObservableObject is very strange. They could have also used @AppStorage instead of UserDefaults and saved another few lines. To be honest this is some of the strangest SwiftUI code I've seen.