I had read that the answer was to mark the shared object with @Binding instead of @State but that was not sufficient. See https://developer.apple.com/forums/thread/735416?answerId=761483022#761483022 In my case I needed to add the equivalent of @Bindable var profile = profile // must be placed in view body

My solution, which I learned from elsewhere on this forum, is just to drag the unique name property of my object as a String and then in the action closure use the name to find the dropped object. Interestingly, when I try to abstract this modifier the compiler expects the elements that prevent compilation; perhaps this would work with something more specific than some View. struct DropableTableRowModifier: ViewModifier { let object: Object: func body(content: Content) -> some View { content .dropDestination(for: String.self) { objectNames in // do things with object and objectNames return }

I've not gotten anywhere with this. The issue is how does one abstract code from within a DisclosureTableRow and return either another DisclosureTableRow or a TableRow. Why not organize the accounts hierarchically and feed that to Table? Because then childless parents have disclosure triangles and there are issues with expansion.

I added a .sheet in Main where I can access the shared modelContext and all is well. I'd still appreciate answers to #3