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.

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?

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).

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.)