I noticed a problem with the NavigationCookbook sample code. The builtInRecipes array containing Recipe models without IDs which means state restoration fails because the recipes have new unique IDs every time the app is launched (there is a let id = UUID() in Recipe). The problem is in NavigationCookbook/Models/DataModel private let builtInRecipes: [Recipe] = { var recipes = [ "Apple Pie": Recipe( name: "Apple Pie", category: .dessert, ingredients: applePie.ingredients), Should be let builtInRecipes: [Recipe] = { var recipes = [ "Apple Pie": Recipe( id: UUID(uuidString: "E35A5C9C-F1EA-4B3D-9980-E2240B363AC8")!, name: "Apple Pie", category: .dessert, ingredients: Ingredient.fromLines(applePie)), And the same thing for all the other built-in recipes in the array. The builtInRecipes containing ids can be found in the Code tab in the Developer app for this samples WWDC session video: https://developer.apple.com/wwdc22/10054 I also submitted this as feedback FB11744612

PersistentModel is a protocol but would make more sense as a class that we then subclass. If all of the implementation was in a parent class of our model classes then there wouldn't be all the problems caused by requiring the use of the @Model macro, e.g. default property values not working, unable to subclass, overriding get/set not possible, conflict in property names...

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.

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?

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.