Thanks for the tip. com.apple.application-instance doesn't seem like the way to go for me, because the resouce needs to be stored in the droplet bundle itself (the droplet is designed to be shared). The section on Changes That Don't Invalidate a Code Signature sounds promising, but I don't understand what it actually means yet: If you have optional or replaceable content you wish to change without invalidating the code signature, nested code can be replaced with equivalent (conforms to the designated requirement) nested code without disturbing the outer signature. This is the design mechanism for indirection in code bundles. It is acceptable to code-sign a bundle containing no main executable, and then treat it as nested code (typically in Contents). What is indirection in code bundles?

Hmm. The droplets are designed to be shared with others, not just run locally. My users are not necessarily developers. It seems in the absence of custom resource rules the droplets will need to remain unsigned/unsandboxed. This seems like a shame to me... it means receiving them will be riskier than it needs to be.

There is no central database of droplets. Each droplet is a unique user-generated self-contained bundle. The user creating the droplets should not need to be a developer, and the recipient of a droplet should not need additional software to run it. Think FileMaker Pro or Hypercard.

Thank you Quinn “The Eskimo!” and TyngJJ. What I was really after was custom resource rules; it's a shame Apple knocked that on the head. In an ideal world, I'd be able to sandbox and notarize the executable code in the bundle, and specify that this single non-code resource does not affect the code signature. This would reduce the attack area to virtually nil in my case. As it stands, it seems distributing the app bundles unsigned/unsandboxed (like Transmit droplets) is my only option. Recipients will need to be directed to the the control-click + Open trick. This is a shame, because the bundles will be vulnerable to all sorts of attacks (like code modification) that could otherwise be prevented.

Same. Still stuck on 11.0 Beta (20A5299w) which is the build that came on the DTK.

For anyone reading this thread later and wanting to do something similar, note the following: New in macOS 11 on Apple silicon Mac computers, and starting in the next macOS Big Sur 11 beta, the operating system will enforce that any executable must be signed with a valid signature before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature issued locally is sufficient, which includes signatures which are now generated automatically by the linker So producing non-code signed app bundles at runtime on the customer's Mac is a no-go.

Same problem. Tried restarting, deleting derived data, etc. No luck. Disabling SIP worked for me too, thanks for the tip.

Legend! Thank you so much for posting.

I'm already displaying the standard menu from the document name title view in my editor document-based iPad app. The problem is how to display the popover connected to it, when the user chooses "Export" from this existing menu?