@DTS Engineer When I enable and disable it, I do receive the startFilter and stopFilter messages, but I no longer receive the handleNewFlow message. As soon as I receive the stopFilter message, the network returns to normal. By the way, let loNetworkRules4 = NENetworkRule( remoteNetwork: NWHostEndpoint(hostname: "127.0.0.1", port: "0"), remotePrefix: 0, localNetwork: NWHostEndpoint(hostname: "127.0.0.1", port: "0"), localPrefix: 0, protocol: .any, direction: .any ) A rule like this has also caused complete network outages on many versions of the system. Speaking of which, I urgently need to find a solution. So, I have two requests: When this issue occurs, how can I collect system logs to help us pinpoint the specific problem (it could be a system issue or an issue with our extension)? Is there a way to quickly reset the network? You mentioned earlier that there is a process similar to launchd responsible for the entire lifecycle of the system extension. Can I kill this process to achieve a network reset? thanks

@DTS Engineer I’m not quite sure what you mean by the 'sysex process.' I have tried numerous ways to restore the network state without rebooting, including a clean uninstallation of my application—system extensions, the wrapper program, and all related auxiliary tools included—followed by a fresh reinstall. I’m increasingly convinced this is a system bug. My testing shows it occurs far more frequently in version 15.6 than in 26.2. While the issue still persists in 26.2, the probability has significantly decreased. What I urgently need to know is: Is there a way to forcibly reset the entire network stack to clear out potential 'bad states' without having to restart the machine?

@DTS Engineer FB19922007

@DTS Engineer First of all, thank you for your response. I followed the instructions in the manual, and the content of the manual is valid. The key operations were: plutil -create xml1 MyWorkspace.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings plutil -insert iOSPackagesShouldBuildARM64e -bool YES MyWorkspace.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings However, this is for iOS, where the toggle is iOSPackagesShouldBuildARM64e. What I need now is for macOS. I tried changing it to MacOSPackagesShouldBuildARM64e, but it didn't work. So for macOS, the issue remains unresolved .

Thank you for your explanation. Actually, I am using sparsebundles as an encrypted file storage area, so I need it to be readable and writable, which is why I can't use a dmg. The problem I'm encountering now is that when files are deleted from the sparsebundles, the corresponding space isn't immediately freed up. I'm currently looking for a method to reclaim the extra occupied space (around 20GB) after deleting files from the sparsebundles.

I conducted more tests and made the following discoveries: The disk does shrink, but it always retains around 20GB of occupied space. For example, I created a 1TB sparsebundle, filled it with 200GB of data, then deleted 100GB of it—the actual occupied space shrank to around 120GB. After deleting another 50GB, the disk shrank further to about 70GB. Finally, when I deleted everything, it shrank to around 20GB. Then, I used the resize command to adjust the disk size to 100GB, and it almost fully reclaimed the space, leaving only about 200MB occupied. The space reduction always happens some time after remounting. Moreover, the shrinking only occurs when the sparsebundle is opened by double-clicking in Finder. If I mount it using the hdidutil attach command, no shrinking happens. So, what’s the difference between opening a sparsebundle in Finder and mounting it with the hdidutil attach command? Does Finder perform some additional operations?

@DTS Engineer Thank you for your answer. I roughly understand the underlying mechanism now. Essentially, the reason the space cannot be reclaimed is that APFS doesn’t actually delete the content but merely marks those blocks as unused through its own data structures. As a result, hdiutil doesn’t realize those blocks are no longer in use. This reminded me of the TRIM functionality in SSDs, but unfortunately, I found that the mounted SPARSEBUNDLE isn’t recognized as an SSD. However, I did find a workaround: using hdiutil resize to shrink the image’s capacity. For example, if the actual usage is 20GB, I resized the capacity to 100GB and mounted it. At this point, APFS seems to start actually deleting the data because it detects that the container’s free space has reached a certain threshold. This might also explain why 100GB could be automatically reclaimed while 200GB couldn’t. I wonder if my guess is correct. If it is correct, then the key to reclaiming space is to make APFS truly delete the data it has marked as unused. Are there any tools or methods available to achieve this?

i found a way by myself import SwiftUI @main struct ThreeSideViewerApp: App { var body: some Scene { WindowGroup { ContentView() } .windowToolbarStyle(.unifiedCompact) } } struct ContentView: View { @State var show: NavigationSplitViewVisibility = .all var body: some View { NavigationSplitView(columnVisibility: $show) { Text("SideBar") .toolbar(removing: .sidebarToggle) // remove default add .toolbar { ToolbarItem { // add my self Button(action: { // use animeatino to toggle withAnimation { if show == .all { show = .detailOnly } else { show = .all } } }, label: { // set large Image(systemName: "sidebar.leading").imageScale(.large) }) } } } detail: { Text("detail") } } }

.toolbar(removing: .sidebarToggle) ?