If it is listed in mdimport -e it can run with mdimport -m -y LOWERCASECONTENTTYPE -u PATHTOAFILE however the attributes aren't actually added to Spotlight's database. And even if the Spotlight extension is enabled in Settings->LoginItems->Spotlight Extensions, Spotlight will never actually run the extension itself. And if in the extension code you attempt to open the file with a try, it throws a permission exception so you wouldn't even be able to compute attributes anyway.

That just tests the extension though. It doesn't make Spotlight actually use it. Oh sorry you already added a reply about knowing that.

I had the same problem and lucky I found this forum post! I've suggested this info be added to the documentation for fetchIdentifiers(_:) FB17555489

By the way on macOS 15.4.1 (24E263) I found @Query does call body when ModelActor saves 🤔 Seems to me @Query watches for the remote store changed notification, then toggles a bool to and performs another SQL query. CoreData: debug: Remote Change Notification - posting for store ContentView: \QueryController<Item>.<computed (Bool)> changed. CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZCOUNTER, t0.ZTIMESTAMP, t0.ZUNIQUEIDENTIFIER FROM ZITEM t0 ORDER BY t0.ZTIMESTAMP DESC, t0.Z_PK

FB16770732 submitted today thanks

See my reply for info

Seem it has changed to NSNotification.Name(rawValue: "_SwiftDataModelsChangedInContextNotificationPrivate") but the sets are of type Set<AnyPersistentObject> and AnyPersistentObject is private so we can't get to the objects.

Only if post is a struct though. Otherwise you probably don't want to capture it because then ParagraphDetail won't update if a property of post is changed.

[post] should fix that, e.g. .navigationDestination(for: Paragraph.self) { [post] paragraph in ParagraphDetail( post: post, paragraph: paragraph) } This way it captures post and not self so it won't be called every time any property of self changes and only if post changes.

Not just the same format, style, but exactly the same button duplicated an arbitrary number of times. I'm trying to think of a situation where one would want that to happen but haven't thought of one yet.

Try redesigning your model so you only have one @Query per View. It might mean your model isn't designed correctly. Try to design it based on what you want to show. And its best to compute counts when you save rather than compute them in the UI.

Usually you don't need Task.detached. To get a background thread simply move the code to a nonisolated async func in the View struct or move it to a struct that is not MainActor.

Usually you don't need Task.detached. To get a background thread simply move the code to a nonisolated async func in the View struct or move it to a struct that is not MainActor.

Since SwiftUI already is a view model you would be better off learning State & Binding instead of trying to build a custom layer of MVVM objects on top of it. That will likely cause the same kind of consistency errors that SwiftUI's use of View structs was designed to eliminate. Try breaking your view data up into View structs, put State in a shared common parent, pass down as let for read only or Binding var for read/write. The body will be called in all cases when the data changes.

delete