This is working in Xcode 16.3 (16E140) on macOS 15.4 (24E248)! I didn't test very often, so I don't know exactly when it was fixed.

Still broken with Xcode 15.0 (15A240d) on macOS 14.0 (23A344).

I'm pretty sure that's populated by UI tests which show the string in question and which record a screenshot. This way, you can run your tests in various locale settings and confirm the string doesn't overflow a field and get truncated.

Forgot to mention that I haven't seen the problem outside of XCTest. VoiceOver properly moves the cursor into either popover and can hit the Cancel button.

Looks normal enough to me. What exactly do you mean by "untangle"? What's the concern?

I've managed to improve performance somewhat. Modifications are in the most recent commits on the repo. Added a property to my Core Data objects which computes the height of that row from only the object count in the relevant fields Implemented NSOutlineViewDelegate.outlineView(_:heightOfRowByItem:) to get the height from the object Set up my outline view delegate to observe NSManagedObjectContext, get the index of every row the outline view is showing, and tell the outline view to recompute those rows' heights Disabled usesAutomaticRowHeights Before the modifications, I got 172ms mean hitch duration, 168ms median. Afterwards, I get 87ms mean 88ms median. Scrolling performance still isn't great, but that may be down to my development machine being on the older side.

The problem is your view's newdrug value always has the same UUID. It gets allocated one time when the view is instantiated. You then add the item with that UUID to the list several times. In your add button, replace this: viewModel.favs.insert(newdrug, at: 0) with this: viewModel.favs.insert(Drug(name: newdrug.name, amount: newdrug.amount, bag: newdrug.bag), at: 0) That will cause a whole new Drug object to be created and inserted. It gets a new UUID when it's created, so it won't match the ID of any of the other objects in the array. SwiftUI will then be able to recognize it's a different object.

You can't use @FetchRequest in a function, but you absolutely can use a fetch request in a function. You just have to build an NSFetchRequest object, set its predicate and sort descriptors, then fetch it from a managed object context. Depending on exactly where that function is in your code, you may be able to access the managed object context without passing it explicitly into the function. It would go a bit like this: func searchResults(searchingFor: String) -> [Recipe] { let recipeFetch = Recipe.fetchRequest() recipeFetch.predicate = NSPredicate(format: "title CONTAINS[c] %@",searchingFor) recipeFetch.sortDescriptors = [NSSortDescriptor(key: "date", ascending: true)] let results = (try? self.managedObjectContext.fetch(recipeFetch) as [Recipe]) ?? [] return results } I haven't run this exact code, but it's very similar to code I'm using in several of my applications.

The problem is you have named your new entity "List". SwiftUI also has a construct named "List" which you are trying to use. The compiler is confused, and is trying to use the entity in your UI. Change the name of your entity, clean your build folder, and rebuild. I would use something like RecipeCollection, as I mentioned in my edit in your other thread. Depending on how exactly you want it to work, "RecipeFolder" or "RecipeTag" might be better names.

I would get rid of the 'recipes' attribute on your List entity. You traverse an NSManagedObject's relationships just like how you traverse attributes, so you can get the set of all of the recipes linked to a list like "myCurrentList.recipeList". I would also change the name of the relationship from List to Recipe to instead be "recipes", but that's more a personal preference than a technical recommendation. Edit: Just realized after posting that you have called one of your entities "List". You are also trying to use a SwiftUI construct named "List". They are conflicting. Rename your entity to something like "RecipeCollection", clean your build folder, rebuild, and they should no longer conflict. This part was in my original post. It's wrong, but I'm leaving it for future readers, as it's good practice when making changes in Core Data. As for your errors, after you added the new entity and the new relationships, did you clean your build folder (Shift-Command-K) and rebuild from scratch? When updating Core Data's managed object model, it sometimes falls out of sync with Xcode's UI, which can lead to really weird errors. A clean and rebuild often gets you back to rational errors.

Core Data has some value transformers already. Set the attribute to be Type: Transformable, and set the custom class to be [Int]. It should work.

Yes, though I would drive a collection view with an NSFetchedResultsController and bindings. NSManagedObject subclasses are automatically observable. You don't need to do anything for ObservableObject conformance, nor do you need to annotate properties with @Published. In SwiftUI views, you can just add an @ObservedObject var for your managed object, and the view tracks as properties and relationships of that object update.