I found a workaround that might work for you: Define EditMode state and provide it to List and EditButton directly. See this example: @State private var editMode: EditMode = .inactive List { ... } .environment(\.editMode, $editMode) .toolbar { ToolbarItem(placement: .primaryAction) { EditButton().environment(\.editMode, $editMode).navigationTitle("Tags") } if editMode.isEditing { ToolbarItemGroup(placement: .status) { Button("Merge") {}.disabled(multiSelection.count < 2) } } } Hope this helps.

As a note: Still, the animation is quite clunky when selection changes, because the path clearing is still happening during transition, which is shown on the toolbar and title. It looks like NavigationSplitView is always intended for drill-down scenario where selecting a sidebar always leading to Root is acceptable. Probably I need to find a solution with TabView, but let me know if I'm wrong.

willSet didn't work on @State sidebarSelection; it was never getting called. But onChange(of:) worked nicely. Here is the change I made: List(SidebarSelection.allCases, selection: $sidebarSelection) { selection in switch selection { case .files: Label("Files", image: "custom.square.stack") case .tags: Label("Tags", systemImage: "grid") case .trash: Label("Trash", systemImage: "trash") } } .onChange(of: sidebarSelection) { if sidebarSelection != .files { backup = path print("backup: \(path.count)") } else { path = backup print("restore: \(backup.count)") } } Thanks for a hint!

Hi DTS Engineer, thank you for reply and providing a suggestion. I understand your suggestion, and I also have read the two articles you shared. How can I apply it to my problem where NavigationSplitView clearing the NavigationStack's path when selection changes? Is your suggestion to use willSet/didSet on path and back up the path there?

Update: it turns out I had to re-sign the paid app contract after migrating the developer program from individual to LLC recently. Actually, I thought I signed it but it was not Paid App contracts which I had to search around the AppStoreConnect to find out the fact that it was missing. I doubted this when I found yesterday that storefront didn't work even in the Sandbox environment which worked fine before. Within 3 hours of signing the contract the storefront started working in the sandbox environment, and within 15 hours, the production build with the AppStore started to work. I should probably note that I also updated the reference name of the products in an attempt to enforce them to be refreshed quickly, but it didn't take in effect until 10 hours were passed additionally, so without the heck it might have just worked after some time has passed after the paid app contracts were signed. I'm still opening store front using groupID, so this might not be applicable to SPEEDCUP and Thomssie.

I'm having exactly the same issue. After free month, my subscribers failed to renew automatically, and the store front shows "Subscription Unavailable. The subscription is unavailable in the current storefront." I also filed feedback last week, but haven't got a response yet. My feedback ID is FB14509371. This seems quite serious problem as it causes inconvenience to my paid users, nonetheless to say it affects revenue as well... Any recommendations or temporary fixes that aren't too temporary i.e. updating app descriptions?