@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) ?

hi Uddalak, I got the same problem, do you have any progress?