AppleScript and Code Signing in Sierra
If you have moved to macOS 10.12 Sierra, you will probably have noticed that the AppleScript version is 2.5, unchanged from that in El Capitan. That doesn’t mean nothing has changed for scripters, though; there are at least a couple of things we have noticed.
[…]
In Sierra, the rules on what can be in a signed bundle have been tightened, and resource forks are no longer allowed. AppleScript has been saving information in resource forks forever, although that information has been unused for a long time. With Sierra, when you save a script, this resource fork information will no longer be saved.
So how will this affect scripters? If you don’t sign your code, it obviously doesn’t matter. And if you have applets written and codesigned under previous versions of the OS, they’ll still work fine. But it means you cannot codesign a script that was last saved in a version before Sierra; you have to save in Sierra to be able to sign in Sierra.
SpamSieve supports some e-mail clients that require AppleScripts to have resource forks. Newfangled data fork scripts are not recognized. With Sierra, it’s no longer possible to include those scripts in my app because then it can’t be signed:
resource fork, Finder information, or similar detritus not allowed. Command /usr/bin/codesign failed with exit code 1.
So I am instead packaging the scripts in a .tar archive and having the app expand it to access the scripts when needed. In order to complete the code signing, I also had to get rid of some unimportant metadata that was attached to some of my HTML and CSS files. The easiest way to do this was to delete the affected folders and restore them from Git (which only stores basic Unix metadata). You can also use the xattr tool.
If you’re code signing with Sierra, also beware of having duplicate identities.
Back to Stanley:
[A] lot of applications that did not have tabbed windows will when running under 10.12, and how that effects scripting them might not be obvious. […] The trick is that, as far as these applications are concerned, they are still opening separate windows for each document the same as before. The system then makes the windows all the same size and position, and only actually draws the frontmost one to the screen, along with a tab bar.
So when you script such an application, you too should treat the tabs as separate windows.
