Did you try using a furl?Use this code:set theImageFile to choose file of type "public.image" with prompt ""set theImageFile to theImageFile as «class furl»

I don't see any alternative for stapler.

> notarise your whole package and then have the client re-sign anything as part of their distribution flow.Quinn,At the risk of wandering off-topic, can you clarify a point about signing? Is it true that signing should always over-write any existing code-signing?I ask because I've had a recent case where this was done in SD Notary. The signing (of a framework) succeeded and notarization succeeded, although the app then failed when it tried to load the framework. I checked the logFileURL and there was an issue saying the framework was not signed.I repeated the exercise, this time starting with an un-signed version of the framework, and all went well. (I have no idea how the previous version was signed -- it was from a user).

Yes, I'm using `--force` and signing inside-out.Here's the SD Notary logging for signing of the relevant framework (with paths abbreviated):<pre>13:48:56.770: Signing ‘.../.../Contents/Frameworks/SMSTableDialogBuilder.framework/Versions/A'...13:48:57.641: Result for /usr/bin/codesign --force -o runtime --timestamp --entitlements /Users/shane/.../Entitlements.plist --verbose=4 -s Developer ID Application: Shane Stanley (LT9SRJ2NCV) /Users/shane/Desktop/.../Contents/Frameworks/SMSTableDialogBuilder.framework/Versions/ATermination status: 0StandardOut: (null)StandardError: Developer ID Application: Shane Stanley (LT9SRJ2NCV): found in both /Users/shane/Library/Keychains/login.keychain-db and /Users/shane/Library/Application Support/.../PrivateEncryptedDatak (this is all right)/Users/shane/.../Contents/Frameworks/SMSTableDialogBuilder.framework/Versions/A: replacing existing signature/Users/shane/.../Contents/Frameworks/SMSTableDialogBuilder.framework/Versions/A: signed bundle with Mach-O thin (x86_64) [au.com.myriad-com.SMSTableDialogBuilder] </pre>It was successfully notarized, but the LogFileURL contained this:<pre> "issues": [ { "severity": "warning", "code": null, "path": ".../Contents/Frameworks/SMSTableDialogBuilder.framework/SMSTableDialogBuilder", "message": "The signature of the binary is invalid.", "docUrl": null, "architecture": "x86_64" } ]</pre>

Quinn,Thanks for the confirmation that it shouldn't happen. Seems to me that makes it a bug, so I'm not thrilled at the idea of forking out for a DTS incident over it. I'll log a bug.

I suspect the .zip is not to blame. I know of at least one app that contains an encrypted .zip file, and it gets through Gatekeeper fine. (Unless the rules have changed very recently.)

Eskimo said:>Those messages should only show up once for any given combination of source and target app. I suspect what’s happening here is that your script is unsigned, so the system can’t accurately track the source app from run to run.Signing is not required, though. The problem is that AppleScript apps are self-modifying if the value of any top-level variable changes, and such changes invalidate authorization.The solution is either to re-write to avoid top-level variables, which usually means putting all the existing top-level code in a handler and calling that, or marking the file execute-only, using something like `chmod a-w` on the applet's executable (/Contents/Resources/Scripts/main.scpt).

Quinn, We're hitting this very occasionally, and it seems that our document class is sometimes being dealloced on a background thread: 10 Foundation 0x00007fff3c06252c -[_NSXPCConnectionExportedObjectTable releaseExportedObject:] + 297 At first I thought it might be an artefact of running in Xcode, because we weren't seeing it in bug reports. But now I've seen it from a user, too. Any thoughts on how to handle this?

Thanks as always, Quinn. I'd been assuming the -[_NSXPCConnectionExportedObjectTable releaseExportedObject:] implied it was the OS's doing, but perhaps that's too simplistic a reading of things.