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

Question

kain84 OP

Created 1d

Replies 4

Boosts 0

Participants 2

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.

Answer 1

Etresoft OP

1d

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.

Answer 2

Etresoft OP

14h

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.

Answer 3

kain84 OP

14h

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.

Answer 4

Etresoft OP

5h

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!"