Neither of these solutions worked for me. I needed a ForEach () with rows which can be deleted in EditMode and other views which show or hide depending on Edit Mode. Without any solution, the Edit mode button allowed my ForEach list items to see Edit mode, but not my custom views. The environment variable never changed. The first solution didn't work due to Bindings, key paths and other arguments needing to be passed through to lower levels which just got too complicated. The second solution allowed my custom views to see the changes from the edit button, but the ForEach loop was not able to see the editMode anymore. I came up with the following simple solution which didn't disrupt the ForEach loop, and enabled my CustomViews to react. struct IfEditMode<Content: View>: View { var showView: () -> Content var notEditingView: (() -> Content)? init(@ViewBuilder show: @escaping () -> Content, @ViewBuilder `else`: @escaping () -> Content) { self.showView = show self.notEditingView = `else` } init(@ViewBuilder show: @escaping () -> Content) { self.showView = show self.notEditingView = nil } @Environment(\.editMode) var editMode var body: some View { if editMode?.wrappedValue.isEditing == true { showView() } else if let notEditingView = notEditingView { notEditingView() } } } Use it as follows: // With a single argument, providing a View to show only in EditMode IfEditMode { Text("In Edit Mode") } // Or a second argument, providing a View to show when not in EditMode IfEditMode { Text("In Edit Mode") } else: { Text("Read Only !") } Hope this helps

I ran into the same issue yesterday. @DTS Engineer Ziqiao, your proposed solution solves the compiler errors, many thanks, but I see that this fix has not made it into iOS 18 or 18.1. Is it safe to use this workaround and should we expect the SwiftData API to incorporate this anytime soon ? If not, what are the risks/concerns ? Thanks, Guy

OK I am happy to report I have found a workaround which is benign on other platforms, until Apple fixes TabView on Catalyst. Adding an onAppear() to each tab subview, and manually setting the selectedView stops Catalyst from resetting the subview, and doesn't appear to have any issue on iOS/iPadOS. struct ContentViewFixed: View { @State private var selectedTab: Int = 1 var body: some View { TabView(selection: $selectedTab) { Button("First tab") {} .tabItem {Text("First tab")} .tag(1).onAppear {selectedTab = 1} TestViewButton(color: .blue) .tabItem {Text("Blue")} .tag(2).onAppear {selectedTab = 2} TestViewButton(color: .green) .tabItem {Text("Green")} .tag(3).onAppear {selectedTab = 3} TestViewButton(color: .red) .tabItem {Text("Red")} .tag(4).onAppear {selectedTab = 4} Button("No change") {} .tabItem {Text("No change")} .tag(5).onAppear {selectedTab = 5} } } }

I have run into the same issue. If any subview of the TabView is invalidated due to an ObservableObject being updated, on MacCatalyst or Mac designed for iPad builds, the TabView resets to the default tab. No issue on iOS or iPadOS. import SwiftUI @main struct TestTabViewApp: App { var body: some Scene { WindowGroup { ContentView() } } } class AppState: ObservableObject {} struct TestViewButton: View { var color: Color @ObservedObject var appState: AppState = AppState() var body: some View { ZStack { color Button("\(color.description)") { appState.objectWillChange.send() } .padding() .background(.white) } } } struct ContentView: View { var body: some View { TabView { Button("First tab") {} .tabItem {Text("First tab")} TestViewButton(color: .blue) .tabItem {Text("Blue")} TestViewButton(color: .green) .tabItem {Text("Green")} TestViewButton(color: .red) .tabItem {Text("Red")} Button("No change") {} .tabItem {Text("No change")} } } } In the above basic application, each tab has a button. When run on My Mac (Mac Catalyst) or My Mac (made for iPad), pressing the button under the Red, Green or Blue tabs causes the tab view to reset. Pressing the button on the "No change" tab, does not reset the TabView, as the subview state is not invalidated. When run on an iPad 18.0.1 or My Mac (macOS), the TabView behaves correctly, without any reset. Feedback submitted (FB15436253)

I'm on Version 13.3.1 (13E500a)

Same for me. I have been battling with profiles and certificates all morning. I get the following error Invalid Provisioning Profile Signature. The provisioning profile included in the bundle 'xx.xx.xx' (Payload/xx.app) cannot be used to submit apps to the iOS App Store until it has a valid signature from Apple. (Expired profile signing certificate.) For more information, visit the iOS Developer Portal. With error code STATE_ERROR.VALIDATION_ERROR.90165 for id *** When I build in Xcode, it says my iOS Team Store Provisioning Profile: (Expires 21/9/22). My Apple Development certificate in the Keychain expires on 10/9/22 I can't find anything expired. As Xcode, Keychain, and the online developer account use different terms for things, I am totally lost as to what the error is actually due to or what I am expected to do (if anything).

Thanks so much Quinn,Using "0.0.0.0" as the Host for the localEnpoint is just what I needed.CheersGuy

I trawled through the source code to the NW classes on github and discovered the answer let parameters = NWParameters.udp parameters.allowLocalEndpointReuse = trueSeting this on both NWListener and NWConnection sets the reuse option on the socket.