“The largest point of these apps is drag/drop functionality.”Yeah, I did consider that possibility. Droplets are just too **** handy in a production environment. Code signing would be best; unfortunate that costs $99/year but if it’s a business I’m sure they can absorb that. (If only Adobe licenses were that cheap!)One of the challenges with Script Editor applets is that they tend to mutate themselves. (I think AppleScript took some ideas about persistency from Smalltalk VMs; a noble ambition, but goes down in *nix OSes with retrofitted user-level security like a lead balloon.) Off the top of my head, the easiest way to defeat that is to modify its entry point(s) like so:on run -- do stuff endbecomes:on run local scpt copy me to scpt tell scpt to _run() return end on _run() -- do stuff endThat should make a copy of the entire script, run that copy, and discard it. This prevents any changes to properties/globals being saved back to the applet bundle’s embedded script file, so the applet’s resource files should remain stable. I think (but don’t quote me on this) that Xcode-saved applets might be non-persistent too.Unfortunately, I don’t have access to a 10.15 machine right now to see if that makes any difference to Automation permission requests. If it does help, let us know.

AppleScript bitrot setting in too? How delightful.At this point OP might want to consider switching to zsh scripting and go read the manpage for `sips`, which is the command line equivalent of Image Events.app minus [hopefully] its hassles. There are definitely faster, less painful ways to get through life than dealing with an obsolescent AppleScript stack and its creeping failures; nevermind filing bug reports that will never get actioned.--[For those unaware: Apple scrapped its Mac Automation team back in 2016 after multiple new product failures. The whole Apple event/OSA/AppleScript stack looks to be in maintenance mode now, so unlikely to receive any further updates outside of plugging security holes. The future of automation most likely lies now in the cross-platform Siri and its [conversational] Shortcuts backend. The underpinnings for the latter are already lurking in 10.15 so I expect the full package will land in 10.16 sometime next year.]

“The issue here is that the code signature uniquely identifies the code, so if the code is not signed there’s no way to know that one instance of your app is the same as another instance”OP might consider deploying scripts via the global script menu (enabled via Script Editor’s general preferences) or third-party launcher, rather than as standalone applets (which need to be individually codesigned and immutable). Being conventional macOS .app bundles those should provide a stable target for the OS’s identity checks to latch onto, unlike traditional Script Editor applets which are notoriously self-modifying.Yeah, associating signatures with executables rather than scripts is a loophole in the current security setup which may eventually be plugged. But until Apple figures out what its future IPC and end-user automation strategies are going to be and makes it happen, might as well make the most of those holes. It’s frustrating all round.