As macOS turns 11 and ushers in the era of Macs running on Apple’s own processors, one related change will have some subtle, and not so subtle, ramifications for many AppleScript users.
To be able to run on Macs regardless of processor type, Apple has introduced universal apps. These contain the executable code compiled for both types of processor, so they run on either type of Mac. At the launch of Big Sur, all the apps included will be universal apps, including Script Editor. Most third-party apps will be updated over time, but until they are, they will run in an emulated form on Apple silicon Macs.
Native code for Apple silicon Macs has a new, inviolable, requirement: it will not run unless it is code-signed. In practice, that means all universal apps have to be code-signed.
In this context, “code” means binary code, not AppleScript code, so this has no affect on AppleScript directly. However, AppleScript applets contain binary code that executes the AppleScript code, and that means any universal applets will have to be signed.
Code-signing — adding a hash that can be used to verify that the code has not been modified — is something that can be done in several ways, with different requirements and security levels. For example, notarized applications have to be signed with a certain type of developer identity, and App Store applications have different requirements.
The requirement for Apple silicon code is quite lenient in this respect: there is no requirement for a signing identity. Apple calls this “Signing to Run Locally”, also commonly referred to as ad-hoc signing. Because there is no requirement for an identity, and therefore any certificate to prove that identity, anyone can sign an app to run locally.
So where do AppleScript applets stand in this? First, not all applets will be universal — those produced by apps that have yet to be revised to produce universal applets will be Intel-only, so the new requirement is irrelevant for them. They will run under emulation on Apple silicon Macs. (It’s worth pointing out that in terms of what the binary code in an applet actually does, any performance difference from running emulated should be completely insignificant.)
But Script Editor running on Big Sur will produce universal applets. This will be the case on both Intel and Apple silicon Macs. So every time an applet is saved in Script Editor while running Big Sur, it will be signed to run locally.
This signing will be noticeable in two ways. First, saving will be a little slower — signing takes a certain amount of time. Second, because the point of signing code is to ensure its integrity, and because the whole applet is signed, the applet will only continue to work as long as it is not altered after signing. And the normal persistence of property values — where you change a property’s value and the change is reflected the next time you launch the app — works by modifying the contents of an applet.
So properties will not persist in universal applets run under Big Sur. If you need to store values between launches, you will have to do it yourself. This is a big change in long-standing AppleScript applet behavior, one you should consider carefully when updating scripts.
Suppose you have an applet saved under Big Sur, and you email it to a colleague still running an earlier version of macOS. They should be able to open it by using control-open. And it will behave the same as it did under Big Sur, with no apparent persistence of properties. Mostly.
The wrinkle is that this consistent behavior is the result of quarantine information added to files when they are emailed (or transmitted some other way, like downloaded from the Web — but not when transferred directly, such as via a USB stick). If the quarantine information is removed — or not present, if the file is moved via USB stick — running the script will result in properties persisting, and in the case of a signed applet, render the signature invalid, and thus the app damaged.
The safest approach is to only distribute exported run-only versions. That way, the script file will be made read-only as part of the signing process.
The change does not affect existing Intel-only applets. But importantly, if you are running Big Sur, even Intel-only applets saved by applications such as Script Debugger 7 will not persist property values, despite the fact that they will not automatically be signed.
Even if you are not intending to upgrade to Big Sur soon, you should probably keep all this in mind. Think about how you rely on properties for persistence. (In some cases properties are already non-persistent: notarized apps, apps signed with a developer ID, apps that use GUI scripting, and apps with top-level variables that use ASObjC.) You might want to save your own data when you need persistence, or use something like the PrefsStorageLib scripting library (https://latenightsw.com/support/freeware/).
And if you distribute applets, you might want to consider moving to a workflow where you develop and save your scripts in a different format, such as .scptd, and only produce applets when you want to deploy them. Exporting them signed will also avoid the possibility of the problem outlined above when moving them to earlier versions of the OS.
A forthcoming version of Script Debugger will save signed universal applets when running under Big Sur, both Apple format and its own Enhanced Applets. We also hope to make it much easier to deal with these issues.
One thought on “Big Sur: Lost Properties”
Comments are closed.