I’m developing a sandboxed macOS app that needs persistent, read-only access to a user-selected folder. We are observing different behaviour between APFS and FAT32/exFAT after renaming the folder or moving it to Trash. The main problem is that the app can still track the folder while running, but cannot reliably restore the connection or identify its location after relaunch. Environment macOS 27.0.1 (26A434) Xcode 27.1 (27A9269) App Sandbox and user-selected file access enabled Folder selection through SwiftUI fileImporter Bookmark creation: .withSecurityScope and .securityScopeAllowOnlyReadAccess Bookmark resolution: .withSecurityScope The selected items are ordinary folders, not volume roots. Filesystem comparison APFS: the tested workflows appear to work as expected, including restoration after relaunch. exFAT: we have reproduced both bookmark renewal failure after a rename and loss of the “in Trash” classification after relaunch. FAT32: we have observed automatic bookmark renewal failures after a rename. The detailed debugger trace and Trash reproduction below were collected specifically on exFAT. Rename reproduction Select a folder through the system picker. Create and persist a read-only security-scoped bookmark. Resolve the bookmark and start accessing the resolved URL. Retain that URL and keep its security scope active throughout monitoring. Rename the folder in Finder while the app remains running. Attempt to create an updated bookmark for the same folder. The monitor retains an O_EVTONLY directory descriptor. After the rename, F_GETPATH returns the correct new pathname, and runtime identity checks still match the monitored folder. However, creating a bookmark using a URL reconstructed from that new pathname fails. Calling startAccessingSecurityScopedResource() on the reconstructed URL returns false, while the original resolved URL’s scope remains active. The bookmark creation call uses: url.bookmarkData(options: [.withSecurityScope, .securityScopeAllowOnlyReadAccess], includingResourceValuesForKeys: nil, relativeTo: nil) Exact failure measured on exFAT LLDB shows that Foundation’s internal open(): Receives the correct new pathname. Uses flags 0, meaning O_RDONLY. Immediately returns -1. Sets errno to 1, EPERM, read immediately on the same thread. The correlated Foundation error reports: NSCocoaErrorDomain Code 256 Could not open() the item: [1: Operation not permitted] This is a failed read-only open during bookmark creation. We have not established which policy causes the EPERM. A log stream filtered for com.apple.sandbox.reporting / violation produced no report during reproduction. We understand that this does not exclude sandbox involvement. We also tested a native CFURL file reference retained from before the rename. It continued to follow the folder and match its identity, but security-scoped bookmark creation from that reference also failed. Reselection works, but requires user intervention Selecting the same renamed folder again through fileImporter allows creation of a new bookmark. That bookmark resolves, is not stale, and restores access after relaunch. Without reselection before quitting, the previously saved bookmark does not restore access to the renamed folder on the next launch. The app reports it as unavailable. Separate Trash reproduction on exFAT Move the monitored folder to Trash using Finder while the app is running. The app correctly identifies the folder as being in Trash. Quit the app, leaving the folder in Trash. Relaunch: the app reports the folder as unavailable. The folder remains in Trash on the same exFAT volume. It has not been restored or permanently deleted. We also encountered failures when inspecting the Trash relationship using FileManager.getRelationship(_:of:in:toItemAt:) with .trashDirectory. We have not established whether these observations share the cause of the rename failure. Questions What is the supported public-API approach to preserve security-scoped folder access across an external rename on exFAT/FAT32, including after relaunch? What should bookmark resolution return for a folder moved to Trash, and how should a sandboxed app distinguish that condition from an unavailable resource after relaunch? Are these expected filesystem limitations, problems in our API usage, or behaviours that should be reported as macOS bugs? What additional diagnostics would help distinguish them? Ideally, the solution would preserve the original folder authorization without requiring repeated reselection or access to the parent directory or entire volume. I have read Accessing files from the macOS App Sandbox. I also found this discussion of bookmark failures involving exFAT, but it concerns volume roots and an earlier macOS release, so I’m not assuming it explains our case.

I’m developing a sandboxed macOS application intended for distribution through the Mac App Store. The app integrates with Claude Desktop using Anthropic’s official Desktop Extension format (.mcpb). Anthropic supports installing a Desktop Extension by opening the .mcpb file, after which Claude Desktop presents its own installation and user-consent UI. I’m trying to clarify one Mac App Store distribution point before we commit to the final onboarding flow. Would a Mac App Store application be permitted to: include its own pre-signed .mcpb Desktop Extension as a resource inside the application bundle; and after an explicit user action, open that bundled resource using standard macOS APIs so that Claude Desktop presents its installation dialog? The Mac App Store application would not: silently install software; modify Claude Desktop configuration; automate Claude Desktop’s UI; download or modify executable code after App Review; bypass Claude’s installation or tool-consent prompts. The .mcpb and the helper executable it contains would already be included and code signed before App Store submission. My question is specifically whether this would be considered using the Mac App Store app as an impermissible software-distribution mechanism, or whether this explicit handoff to another installed macOS application is acceptable. If bundling/opening the .mcpb is not acceptable, is there an Apple-recommended pattern for this kind of handoff to another installed application? I’m not asking for implementation help; the technical flow already works in development. I’m trying to qualify the Mac App Store distribution model before productizing the installation UX.

I need to obtain a list of categories to assign to a business. I'm working on an app for employers. The app allows the user to create new customers and associate categories with the companies he inserts as customers. I noticed that when using iOS Maps and creating a new point of interest, the Maps app prompts us to enter a category, displaying a mandatory list of available categories. I specifically need this list. Is anyone aware of how to obtain this list? Using MapKit, is it possible to access the list you see? I'm sharing a screenshot I took from the device using the Maps app. After an online search I managed to find the list of categories that Apple makes available to the user when creating a new point of interest in the maps app. The list can be found here and can be downloaded in .csv format https://businessconnect.apple.com/docs/data-specification/v1.3/categories Now I was wondering... Can I use this .csv file and its contents without problems? The categories in my app are used by the user only for identification purposes when he creates his personal customer card. Category data remains saved within the app database Thanks for all! This is a screenshot of category on Maps iOS App