Can a Mac App Store app open a bundled, signed MCPB for installation in Claude Desktop?

Would a Mac App Store application be permitted to:

Apple never pre-approves apps. Sometimes it's obvious (to everyone except the developer) that a given app idea would be immediately rejected.

I'm not familiar with any of these AI platforms. Can you explain more about what this thing does? It sounds like you'll need to explain that to App Review too.

The .mcpb and the helper executable it contains

From what I've heard, I doubt the bundled helper executable would be sandboxed. If not, then you can't include it. And even if it is sandboxed, it would still have to comply with Mac App Store guidelines. If that leads the user to a situation where the app "presents its own installation", then that would be right out.

Never use the comments. They hide your replies.

I'm not sure Apple Developer Support will be able to help. They tend to avoid any App Review questions.

However, Apple does regularly hold "Meet with Apple" sessions where you can talk directly to App Review.

But generally speaking, if you're worried that App Review is going to reject your app, you're probably right.

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.

I’m trying to verify one specific distribution boundary before finalizing the onboarding flow

Yeah. I get it.

It's like you can ship a Powerpoint document with your app if you want. The user can double-click that. If they have Powerpoint, or some other app that can open Powerpoint documents, then they can open the document. If not, I think they'll get a prompt to search the App Store.

If that's the experience you're talking about, then it should be fine. But if that bundled document of yours does something else, and leads the user to install some other app, then you've likely got a problem.

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.

Neither of those is relevant. The previous submission history of any other app from any other developer (or even your own app) is irrelevant to any future submission.

And funny enough, the guidelines are also irrelevant. Sometimes it seems like people have those paragraph numbers memorized or something. But they don't really matter. The individual guidelines are just guidelines. They are there to help developers plan which apps to develop and how to implement them. They are a way to categorize and talk about specific kinds of apps from an App Review perspective.

But App Review can reject your app for any reason, regardless of whether there is a specific guideline or not. They will usually tell you the guideline just so you know what to do. But they can also just say, "LOL, no!"

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.

If the other application is installed, it recognizes the file and presents its own installation/consent flow.

It's like I'm beating my head against a wall here.

One thing I can definitely tell you is that App Review tries to see the world through an end user's perspective. They aren't software developers. Sometimes that frustrates developers who expect them to be able to instinctively know how to do something technical.

I've been a professional software developer for longer than most other developers have been alive. And I have no idea what you're talking about. So if you can't explain it to me, you're dead in the water at App Review time.

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?

I'm still focused on certain technical aspects of the file that you're embedding into your app. There are two scenarios here:

1. The user already has Other App installed. The user does whatever in your app and tries to open this embedded file. Doing so activates the other app.

2. The user does not have Other App installed. The user does whatever in your app and tries to open this embedded file. Doing so presents a system dialog explaining that the file can't be opened and offers to search the Mac App Store.

As far as I know, App Review will have no problem with #1 or #2. They definitely aren't going to have Other App installed, so they aren't even going to test #1.

But if there is any #3 flow that I haven't described, then that would probably be rejected. And from the way you've described it, there is going to be a #3.

But perhaps I'm misunderstanding. But remember that I'm not App Review. I'm happy to go back and forth with you here in the forums and answer in a few hours. App Review is on the clock. This kind of back and forth would take several weeks and could possibly lead to dire consequences. So regardless of what you do, you're going to have to have a better elevator pitch to explain to someone who really doesn't care why they should bother.

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.

You might also consider a "Meet with Apple" session. The only other issue is ensuring that the app has enough functionality without Other App already installed in order to pass app review. But now we're getting into "random guy on the internet says" territory. It's better to ask App Review directly.

From what I've seen and experienced, Apple takes a really dim view of interaction with Apple apps outside of heavily-marketed extension points. But there is much greater leeway for apps that interact with other 3rd party apps. I see many apps that are fundamentally based on some other app. So I don't see what other functionality they could possibly have. So I just don't know.

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.