I have a SwiftUI list that is backed by a @FetchRequest to Core Data. To display the items in the list it is necessary to traverse relationships on the originally fetched objects and currently the fetch is a little bit slow, while a number of the objects being displayed require images to be rendered, so overall it is a heavy view at present.
I am working to make both the view rendering and the fetch more efficient, but alongside that I tried to improve the user experience by debouncing the connection between the user's search text and when the predicate would be updated on the @FetchRequest. This was quite simple to do, and meant the source data would only be re-fetched when the user had stopped typing for at least 0.5 seconds.
However, what this demonstrated was that with a .searchable attached to the list, all items in the list were being updated on every keystroke, with printing changes revealing it was because their identity itself was changing, rather than any content. I found this was still the case even if I completely removed my updating of the predicate, so the text binding from the .searchable was stored in an @State value on the view, or stored in a @Binding to some other location, but was not being read nor used for anything else.
Is this intended as a "feature" of .searchable, that it is intentionally triggering a view update on the assumption that when the .searchable text is changed that the view will want to change? If so, this is definitely a bug in SwiftUI from the perspective of how I was wanting to use it. Alternatively, any pointers to how I might be triggering this issue would be appreciated!