Wednesday, January 13, 2021 [Tweets] [Favorites]

Lost Persistent AppleScript Properties

Shane Stanley:

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.

[…]

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.

Previously:

2 Comments

Beatrix Willius

Design choices have consequences. Stupid question: what benefit does the "code-sign everywhere" have for scripts? Those are meant to be manipulated?

At least the AppleScripts work. I have bug reports about AppleScripts not working under Rosetta. I've reproduced one issue for Mail with Gmail accounts. Reproducing the problem with Outlook is on my to-do list.

@Beatrix Even with the code signing design choice, they could have implemented a way to save the properties in a data file outside the app.

I’m seeing a bug with AppleScript and string parameters (especially e-mail contents) under Rosetta. It happens with data from both Mail and Outlook. The receiving app never sees the Apple event, and the sender eventually gets a timeout.

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment