I have the same use case where I only want rows to be selectable in edit mode. I solved this by checking whether edit mode was active before passing the selection binding to the List.
For example:
struct ContentView: View {
let items: [Item]
@Environment(\.editMode)
private var editMode
@State
private var selectedItemIDs = Set<Item.ID>()
var body: some View {
NavigationStack {
List(items, selection: isEditModeActive ? $selectedItemIDs : nil) { item in
ItemView(item: item)
}
.toolbar {
ToolbarItem(placement: .topBarTrailing) {
EditButton()
}
}
}
}
private var isEditModeActive: Bool {
return editMode?.wrappedValue == .active
}
}
This approach works. However, be aware that it does currently trigger a SwiftUI bug where the List no longer shows its multi-select checkmarks in edit mode. I reported the bug in FB13434460 (Open Radar ID 5544045669515264).
fumoboy007
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Same for MusicKit.
The bug is in SwiftData’s ModelContext initializer implementation. The initializer checks whether it is running on the main dispatch queue and if so, configures the context as a main context rather than a background context. More details in FB13399899 (Open Radar ID 5518888167014400).
Here is my workaround:
extension ModelContext {
struct UncheckedSendableWrapper: @unchecked Sendable {
let modelContext: ModelContext
}
/// Creates a background context.
///
/// - Remark: This method works around FB13399899, which causes `init(_:)` to sometimes configure the instance
/// as a main context. This method is marked `async` and not `@MainActor`, which guarantees that the method will be
/// called off of the main thread, working around the bug in the initializer implementation.
static func makeBackgroundContext(for container: ModelContainer) async -> UncheckedSendableWrapper {
let modelContext = ModelContext(container)
return UncheckedSendableWrapper(modelContext: modelContext)
}
}
actor MyModelActor: ModelActor {
…
init(container: ModelContainer) async {
let context = (await ModelContext.makeBackgroundContext(for: container)).modelContext
}
…
}
What about web views? WKWebView? SFSafariViewController?
More precisely, from a SwiftUI engineer (twitter.com/luka_bernardi/status/1151633281982406656):
We made the change because it allows us to do a better job in coalescing updates; especially in the presence of animations.
According to the “Manually publishing ObservableObject changes” post on the Hacking with Swift website (I can’t link it here due to forum restrictions):
As its name implies, this publisher should be triggered immediately before we make our change, which allows SwiftUI to examine the state of our UI and prepare for animation changes.
That makes sense to me. SwiftUI might need to know the old value in some cases in order to perform animations.
I am encountering two issues on beta 4: In my test app, I get the compiler error Cannot find 'SKCloudServiceController' in scope even though I imported StoreKit. The exact same code compiled in beta 3.
In my real app, I don’t get the above error. But SKCloudServiceController.requestUserToken(forDeveloperToken:completionHandler:) returns Error Domain=SKErrorDomain Code=0 "UNKNOWN_ERROR".
Are you getting either of these?
Same. I just reported this in FB8223550.
Looks like that method is deprecated. Have you tried requestUserToken(forDeveloperToken:completionHandler:) - https://developer.apple.com/documentation/storekit/skcloudservicecontroller/2909079-requestusertoken instead?