What is the idiomatic way to use a ModelContext in a document based SwiftData app from a background thread?
The relevant DocumentGroup initializers do not give us direct access to a ModelContainer, only to a ModelContext.
Is it safe to take its modelContext.container and pass it around (for creating a ModelContext on it on a background thread) or to construct a ModelActor with it? Is it safe to e.g. put a ModelActor so created into the environment of the root view of the window and execute various async data operations on it in Tasks throughout the app, as long as these are dispatched from within the window whose root view's ModelContext was used for getting the ModelContainer?
Post
Replies
Boosts
Views
Activity
Document based SwiftData apps do not autosave changes to the ModelContext at all. This issue has been around since the first release of this SwiftData feature.
In fact, the Apple WWDC sample project (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-using-swiftdata) does not persist any data in its current state, unless one inserts modelContext.save() calls after every data change.
I have reported this under the feedback ID FB16503154, as it seemed to me that there is no feedback report about the fundamental issue yet.
Other posts related to this problem:
https://forums.developer.apple.com/forums/thread/757172
https://forums.developer.apple.com/forums/thread/768906
https://developer.apple.com/forums/thread/764189
I have a use case in which there is a zoomable and pannable parent view, and a child view that needs to display a custom context menu on long press.
(The reason why I need to implement a custom context menu is this: https://developer.apple.com/forums/thread/773810)
It seems, however, that this setup produces a bug in SwiftUI. The problem is that the onChanged of the drag gesture is only invoked right before its onEnded, hence you cannot smoothly animate the drag:
struct ContentView: View {
var body: some View {
ZStack {
Rectangle()
.foregroundStyle(.green)
.frame(width: 200, height: 200)
.onLongPressGesture {
print("long press")
}
}
.gesture(MagnifyGesture().onEnded { value in
print("magnify end")
})
.gesture(DragGesture()
.onChanged { value in
print("drag change")
}
.onEnded { value in
print("drag end")
})
}
}
Changing the DragGesture to a .highPriorityGesture() makes the drag's onChange execute at the correct time but results in the LongPressGesture only triggering when the user lifts up his/her finger (which was originally not the case).
So it seems that the two gestures are in a sort of conflict with each other.
Is there a workaround?
If you add the .scaleEffect() modifier to a parent view inside of which there are children with contextMenu()-s, the context menu preview unfortunately keeps the original, unscaled size of the child view. This results in a very weird, glitchy user experience.
Unfortunately, providing a custom preview that is scaled up also does not help, since even though it is the right size, it gets cropped to the unscaled size of the child view.
Adding scaleEffect() to each child element individually (BEFORE the contextMenu() modifier!) does make the problem disappear. However, I would like to avoid this, since my use case is zooming into a complex graph with context menus on its nodes, and having to recalculate the position of each node manually seems to perform much worse than delegating that work to scaleEffect().
Tested on iOS 18.2 (device + emulator)
Is there a workaround?
Here is a minimal working example that demonstrates the problem:
struct ContentView: View {
var body: some View {
VStack(spacing: 20) {
Rectangle()
.frame(width: 100, height: 100)
.contextMenu {
Button("Test") {}
Button("Test") {}
}
Rectangle()
.frame(width: 100, height: 100)
.contextMenu {
Button("Test") {}
Button("Test") {}
}
}
.scaleEffect(1.5)
}
}
Screenshot (problem: The two squares are the same size. However, the long-tapped upper square got shrunk down before the context menu got displayed.)
Embedding a NavigationStack inside the detail view of a NavigationSplitView is described by the Apple documentation: https://developer.apple.com/documentation/swiftui/navigationsplitview
However, I would like to do the opposite: embedding a NavigationSplitView inside a NavigationStack. I have found no hint in the documentation about why this shouldn't be possible, but it does not appear to be working consistently.
There are many use cases where you might want to do this. E.g. you have an eBook reader that starts with a list of books (e.g. a Grid inside a NavigationStack), and when you open a book, you end up in a NavigationSplitView showing the chapter hierarchy in a sidebar. Here, you wouldn't want to have the list of books as a second sidebar, but would want an option to go back to the list of books at any time.
The following trivial example correctly displays a NavigationSplitView on iPadOS, but results in an empty view on iOS:
NavigationStack {
NavigationSplitView {
List {
Text("Element1")
Text("Element2")
}
} detail: {
Text("Detail")
}
}
Is there a workaround?
I have been recently getting the following error seemingly randomly, when an event handler of a SwiftUI view accesses a relationship of a SwiftData model the view holds a reference to. I haven't yet found a reliable way of reproducing it:
SwiftData/BackingData.swift:866: Fatal error: This model instance was invalidated
because its backing data could no longer be found the store.
PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: COREDATA_ID_URL),
implementation: SwiftData.PersistentIdentifierImplementation)
What could cause this error? Could you suggest me a workaround?