Thanks. We already implemented explicit reselection as a recovery path, and confirmed that it restores access after relaunch. The concern is how frequently that recovery becomes necessary. In our tests, an ordinary external folder rename reproduces the problem on FAT32/exFAT, while the same workflow appears to work on APFS. While the app remains running, its existing file descriptor still tracks the renamed folder. On exFAT, we traced creation of the replacement security-scoped bookmark to an open() failure with EPERM. Reselecting that same folder through the system picker allows bookmark creation and subsequent access after relaunch. Saving the last known URL could help guide the user through recovery, but would not itself restore authorization or establish that a folder subsequently found at that path is the original resource. We agree that bookmark failures need a recovery path. The remaining question is whether repeated reselection after ordinary renames is unavoidable under these constraints: a sandboxed app, public APIs, and authorization limited to the selected folder. Have you encountered this specific FAT32/exFAT rename scenario, and do you know an approach that avoids repeated reselection?

Thanks. One clarification, because I don’t want to give you the wrong impression about the product. The app is not a companion for one specific “Other App”, and it is not built around a dependency on one particular third-party application. Its core purpose is to work with multiple compatible third-party applications. A user may use one, several, or different ones over time. So if one particular “Other App” is not installed, the product is not necessarily unusable. But I also don’t want to misrepresent the integration as some optional secondary feature: working with compatible third-party apps is central to what the product is for. That’s why your point about App Review is useful. The question for me is not whether the product can pretend those integrations do not exist, but whether Apple is comfortable with an app whose legitimate core purpose involves interoperating with third-party apps through their supported mechanisms. I understand that this is ultimately something only App Review can decide, so I won’t try to push you for a definitive answer you can’t give. Thanks for taking the time to explain the boundary.

Thanks. I see the confusion now, and I was over-explaining it. What I’m describing is exactly your scenario #1. The Mac App Store app contains a file and, after an explicit user action, asks macOS to open that file using the normal system mechanism. If the other application is already installed, macOS activates that application and passes the file to it. From that point on, the receiving application decides how to handle its own file type and may present whatever UI it normally presents for that file. The originating Mac App Store app does nothing else. It does not install anything, modify the other app, automate it, or perform any additional setup. If the other application is not installed, then it is your scenario #2: macOS cannot open the file and may offer to search the Mac App Store. So there is no separate #3 flow performed by the originating app. Your point about the App Review explanation is also very helpful. I’ll describe the behavior in those simple user-facing terms rather than trying to explain the implementation details.

Thanks, that distinction is exactly what I’m trying to understand. To be more precise, the bundled file is a third-party extension package associated with another macOS application. The Mac App Store app would only: include that file as a resource in its own bundle; and after an explicit user action, ask macOS to open it normally. The Mac App Store app would not install anything itself, modify the other application’s configuration, automate its UI, or download additional executable code. If the other application is installed, it recognizes the file and presents its own installation/consent flow. The user must then explicitly choose whether to proceed. So the point I’m trying to clarify is: Does the fact that the receiving application treats the opened file as one of its own extensions make this materially different from your PowerPoint example? Or is the relevant boundary that the Mac App Store app itself is only opening a bundled file through the normal macOS mechanism and is not performing the installation? I understand that only App Review can ultimately decide a future submission. I’m only trying to understand this architectural boundary.

Thanks, that’s helpful regarding replies vs comments and Meet with Apple. Just to clarify, my concern is not a generic “will App Review like my app?” question. I’m trying to verify one specific distribution boundary before finalizing the onboarding flow: whether a sandboxed Mac App Store app may include its own pre-signed .mcpb Desktop Extension as a bundled resource and, after an explicit user action, open that resource using standard macOS APIs so Claude Desktop presents its own native installation and consent UI. The app would not silently install anything, modify Claude’s configuration, automate its UI, download executable code, or bypass user consent. I’ve already submitted the same narrow question to Apple Developer Support. I’m mainly trying to determine whether this pattern is something Apple has previously accepted or whether there is a specific guideline that would prohibit it.