I need clarification. The query is:
If I create an app using scripting additions, does that mean only persons with scripting additions installed on their computers will be able to use the script-app?
Or does saving/exporting as app import the definitions into the app itself?
I imagine only a small percentage of end-users for my particular app will have scripting additions installed on their systems. Less than 5% at a guess.
Others know more about this subject than I do but I’ll throw this out there. NB that there have been changes over the last couple of OS releases so things are likely different depending upon your users’ OS. I believe there are some other posts which discuss the issue of additions and the current OS.
In general, if an addition is used in a script’s code then it must be available at run time. However, if you’re distributing the script as an app then you can embed an addition therein.
No! Not even then!
Since macOS Mojave (10.14) the scripting additions are no longer loaded, unless they are inside the applet as described by Mockman and:
Note: As of macOS Mojave, you can no longer use scripting additions in the Script Editor or Script Debugger, i.e. you can no longer modify existing scripts, because the additions are no longer loaded.
Thank you both Mockman and db123, both excellent answers; informative and helpful.
That aspect sounds promising. I had hoped scripting additions were portable in one way or another. References I’d read did not make this clear.
Is there a way to determine which Scripting Additions are used within a particular script if you don’t know?
This is scary!
Does that mean as of either Mojave or later, Scripting Additions are dead? Does it mean any OSAX script-app using scripting additions will no longer work? (regardless of any shortcuts to allow certain 3rd party apps.)
The 5 programs my script-app will support are legacy apps with last updates between 10 and 12 years ago, before Apple starting putting its foot down. To use them I presume people are finding shortcut ways of running unsigned apps as well as by-passing other hurdles. I don’t have such environments to do tests with so I’m quite ignorant as to what these shortcuts might be. Except a web-search shows me Apple Support’s https://support.apple.com/en-au/guide/mac-help/mh40616/mac and (more specific instructions ~) https://support.apple.com/en-au/HT202491 both updated several months ago.
Three of the apps have support (text) files within the app package (scary.) Whilst two are almost identical & only need one file updated, the third app stores 4 such files (security hostiles, two webcache files (udp/tcp access), and a base settings file (adds info to block 3 types of bot.) The difficulty with this last app is these files are stored within a .jar file within the app package. A handful of years ago I experimented on an Ubuntu VM with changing this to a zip extension, unzipping, updating, rezipping & changing its name back to jar. It worked; works on ubuntu, windows & macos (at least up to 10.11.) I use this app now. Whilst I am considering experimenting with repeating this process on macos with my app-script, I’m not sure whether later macos would allow it. This aspect of the update would probably only be needed once every 5 to 10 years.
Yes, because even if they are loaded inside the applet (see below), then no longer in the Script Editor/Debugger.
Not necessarily. If you put the scripting additions into the applet’s “Contents/Resources/Scripting Additions” folder and sign it with SD Notary (better yet, notarize it), then the applet will run as before (tested under Big Sur)
I don’t think that works in this case. It is possible to bypass the gatekeeper, but this is only for notarizing, not for loading the scripting additions. For this, the bundle and the scripting additions must be code-signed with the same signing identity. Otherwise, the applet simply does nothing and does not give any error message (tested under Big Sur).
If files are changed at runtime within the bundle, this is a big problem, as it destroys the signature. This should cause it to not load the scripting additions afterwards (among some other effects).
Here is an applet example which is once unsigned, signed and notarized. It uses the url encode function of AppleScript Toolbox.osax and displays “Hello World”: https://www.icloud.com/iclouddrive/0umoalXdudCKN1zyyWQOYVBag#Sample
The unsigned version runs under Hight Sierra. The signed version with the workaround you described (right mouse button…) under Mojave, Catalina and Big Sur and the notarized version without restrictions everywhere.
Thank you db123 for your reply, again very informative and helpful information.
I was not referring to the script-app, but still that is a very important point, both to know about the (macos) sensitivities of the script-app but also the intended target.
All the target apps are open source. From what I can ascertain only one of the 5 target applications were formerly signed & my script does not do anything with that particular app itself. (I cannot actually find what would constitute a formal sig for that app.) A continuation of one of the 5 apps under a different name is not code-signed. Thus I’d suggest the target apps can probably only be used when both Gatekeeper, Signature and notarized by-passing methods are used in any case, something the end-user would inevitably have some practice at.
At the same time, I realise the future of such apps is limited unless updated versions were released satisfying macos security requirements. As for forcing open source and free app devs to pay an annual fee to have acceptable apps, probably enough has already been said on the net. Such a financial requirement is not a huge incentive for prospective devs working on free apps.
I think this is about security. It’s the same like SSL. All browsers have switched to this standard and without a SSL certificate you can no longer operate a site meaningfully, which is correct, so that the user can be sure that the site really comes from you.
This is similar for apps. The signature guarantees that the code is in its original state and has not been manipulated. For this, you need a certificate for the code signing. I believe that this does not necessarily have to be provided by Apple, but I have not tested it yet.
And regarding the scripting additions, Apple also offers a compromise for existing use cases. They have to be inside the applet and part of the signature. In addition, the use is limited to the respective use case.
At the moment, I don’t see a need for a paid Apple account yet and the things are understandable for me. The end user has to trust you and to do that he has to be sure that the code really comes from you and is unchanged.
But I agree with you that the trend is going in the direction of a paid account.
