I think we have to keep using modifyRecordsCompletionBlock because modifyRecordsResultBlock doesn't error on server record changed, it erroneously reports success. As of Xcode 14b1 iOS 16b1. See this post for more info.

I was wondering the same thing. Also when watching the video it when he kept saying "it really is push" it seemed to me it isn't push its just for user notification. If it was real push then we could use it for async updates to data shown on a webpage, e.g. like how we use silent push on iphone to trigger a sync. He said Safari doesn't support silent push!

iOS 14.0+ import UniformTypeIdentifiers imagePickerController.mediaTypes = [UTType.movie.identifier]

I just don't think SwiftUI's state-driven design will ever be able to reliably manipulate UIKit's event-driven navigation components like UINavigationController and UISplitViewController. Especially because these have some of their own adaptive behaviour that will undermine the SwiftUI state. We probably need new versions of these components with all their hacks removed.

I was trying the dictionaryHandler version on iOS and it doesn't insert anything and no SQL debug output about the insert. The init that takes dictionaries does work though.

This is a very common problem experienced by those new to Swift and haven't fully learned closures yet. Usually its experienced with sheet but its same thing with navigationDestination. If you want a closure to have the latest value you need to add it to the "capture list", e.g. .navigationDestination(for: Int.self) { [data] index in The explanation is when the closure is created it is using the old value, which is before it is actually used, so by adding it to the capture list you are stating you want the closure to be recreated when that value changes. As for why the closure is called 3 times, it is annoying but if you take a look at how many times the ForEach closure is seemingly needlessly called that is even worse!

There is no extra state for the sort required, you can bind directly to the fetch's sort descriptors, e.g. Table(clubs, selection: $selectedClubs, sortOrder: $clubs.sortDescriptors) { The results and the table will update automatically. Unfortunately there is an issue where if the View containing the FetchRequest is re-init then the sortDescriptors get reset to their default. I'm not sure if that is a design flaw in FetchRequest or we are supposed to make our own @State for the sort in the view above and pass it in as a binding and use the value in the FetchRequest and using the binding to the binding in the Table, e.g. @Binding var sortDescriptors: [SortDescriptor<Item>] init(sd: Binding<[SortDescriptor<Item>]>) { _items = FetchRequest(sortDescriptors: sd.wrappedValue) _sortDescriptors = sd }

You can bind the table to the fetch request's sort descriptors there is no need to have additional state, e.g. Table(stats, sortOrder: $stats.sortDescriptors) { When the users clicks on a table column the fetch and the table will update automatically. Unfortunately there is an issue where if the View containing the FetchRequest is re-init then the sortDescriptors get reset to their default. I'm not sure if that is a design flaw in @FetchRequest or we are supposed to make our own @State for the sort in the view above and pass it in as a binding and use the value in the @FetchRequest and using the binding to the binding in the Table, e.g. @Binding var sortDescriptors: [SortDescriptor<Item>] init(sd: Binding<[SortDescriptor<Item>]>) { _items = FetchRequest(sortDescriptors: sd.wrappedValue) _sortDescriptors = sd } ... Table(stats, sortOrder: $sortDescriptors) {

com.apple.Music.plist library-url = file:///Users/username/Music/Music/Music%20Library.musiclibrary/

The sample was updated on 1st March 2023 to fix this and many other problems. If you download the sample again and drag the extracted folder into a Git app like Tower you can see all the changes (screenshot below). The commit message was "Updated the project sourcefor compatibility with macOS 13."

I just tested the OP's code in Xcode 14.3 and iPhone 14 Pro Simulator running iOS 16.4 and the problem appears to be fixed. I believe the old behaviour was because the onAppear was tied to the underlying UICollectionViewCell and if you are familiar with UIKit those cells are reused for performance reasons and as you scroll they all only appear once. I'd be interested to know what Xcode/iOS version this was changed in. I usually read all the release notes and didn't notice this mentioned. Recorded using Simulator File->Record Screen, stop, right click preview, save as animated GIF.

MKMapView has different delegate behaviour from normal, it's delegate methods fire when setting its properties. So to workaround that you can disable the delegate when you set the property, e.g. uiView.delegate = nil uiView.centerCoordinate = centerCoordinate uiView.delegate = context.coordinator You also must update the coordinator's parent so it can access the latest binding (which by the way is just a pair of get and set closures): context.coordinator.parent = self Note if you look at PaymentButton.swift in Fruta they set a closure rather than a parent. So if doing it that way you could set the closure nil, set the centerCoordinate then set the closure again.

Remove .modelContainer(for: Card.self) the container for the document is set automatically by DocumentGroup.

In SwiftUI the View struct is a view model already you don't need your own objects, if you try to then you'll just run into the same kind of bugs that Swift's use of value types like structs was designed to eliminate. SwiftUI diffs these structs and then creates/updates/removes UIView (or NSView) objects automatically on your behalf. So you can think of the View struct as simply view data rather than part of the view layer in the traditional MVC sense. It's worth learning the basics of the View structs features like all the different situations that body is called, e.g. if a let is changed from the last time the View was init, or if a state is set (that has had its getter called). If you previously used MVVM in UIKit (FYI you should have instead learned child view controllers and the responder chain) then you can just forget about MVVM in SwiftUI. If you paid Stanford University to teach you MVVM in SwiftUI then you should probably ask for a refund because that is one huge mistake.

Seems it's a known issue: "@Query results can appear stale or fail to refresh. (108385553)" https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-17-release-notes