macOS Please Explain Difference Between .AppleScript & .App

[whirl]

I seem to have have the bug and am enjoying exploring the AppleScript stuff, ok, so I am probably 20+ years late to the partyb

Having lost some practice code through deleting the wrong stuff, I need to understand some differences here.

.applescript and .scrpt file
When saving the file as text in either Script Editor or Script debugger they produce one of the above files.
I presume this is just the main script file, the source code.

.app file
When you choose Save As and select Application, this makes .app file
I presume this is the app which you run. Does this include the source code ?

Run Only
What does this do ?

Script Bundle
What does this do?

Do I edit the .app or .applescript file ?
I presume I always edit the .applescript file although I have noticed that you can alo load the .app into Script Debugger.

So what is the difference between editing the .app or .applescript.

I think this is where I lost some of my test scripts earlier by editing the wrong one and maybe deleting the wrong one.

Is AppleScript Nearly At The End Of Life ?
I have been told that Xcode 14 no longer offers the option to make AppleScrip projects and its all about Swift now. I don't really want to learn all that at my age so I am wondering if AppleScript is reaching the end and could be dropped altogether.

Thanks

 

[casperes1996]

AppleScript is not something I often work with but here's some general information.

First of all, extensions are kind of a lie. They don't "really" exist. They are just part of the name and give clues to software on how to interpret files, but any file can have any extension. Your .AppleScript/.scrpt files are indeed most likely your source files. A .app is not usually a file actually. It may look and behave as a file, but will (at least generally for .app) be a bundle. If you navigate to it via the command line it will become evident; It is a folder/directory/bundle (choose your terminology) not just a single file. .app bundles have a specific structure such that macOS can load them as if they were executables. But they are folders. In the Finder you can also right click an app bundle and "Show contents". This will reveal the Contents folder inside. It has a info plist file describing some information about the application as well as a resources folder that may include static assets for the app like images for its ui. It also includes the MacOS folder which is where the actual executable lives. Given that AppleScript is an interpreted scripting language I would suspect the .AppleScript source file is indeed packaged inside that app at this location as a copy of your source whenever you make a new app bundle.

Regarding the end date for AppleScript; Well, it is true that the latest Xcode betas do not include templates for AppleScript. However, the Script Editor application is still part of macOS, and AppleScript is not deprecated. There are alternative solutions to scripting, like Automator and Shortcuts that Apple will probably prioritise and for application programming Swift or Obj-C is preferred over a scripting language in most cases. That said there is no evidence that suggests AppleScript is being sunset any time soon, although it is also unlikely it will see any feature additions or ongoing work outside of maintenance and security updates. Though you still see fairly new Apple apps ship with bindings for AppleScript so even if Xcode and other tooling may emphasise AppleScript less and less, I would be surprised if it gets removed anytime soon. If nothing else, just because there's a lot of automated workflows out there people rely on.

 

[Mark FX]

I can't say what file extensions 'Script Debugger' supports, as I don't have that application.
But if you take the standard 'Script Editor' built into the Mac OS utilities folder, then it will save AppleScript text either in '.applescript' or '.scpt' file extensions.
If you use references to 'Cocoa' framework classes via the AppleScriptObjcC framework, then you can only save the code as text with one of the above extensions, or save it as an application bundle.
But can't execute the code file via a double click of the script file, or as a run only applet.
a run only AppleScript file is one that is compiled, and can't be opened and edited in a script editor again, but can be executed via a double click, which will run the compiled code.
An AppleScript application is the same as any other application file bundle, which has a folder structure inside, housing all of the script files, along with any icon or picture resources, along with the UI '.nib' files, and other required application files, like the 'info.plist' file.
To view the contents of any application file, simply right click the '.app' file, and you will see a 'Contents' folder, which you can double click to see its contents.

In answer to your previous forum posting which remains unanswered, if you reference the 'application' or 'current application' from within any Script Editor, you will indeed be referencing the Script Editor app, and not your own AppleScript application bundle.
One of the limitations of building AppleScript application bundles from a Script Editor, where if you create and build your application from Xcode, this limitation does not exist.
In short AppleScript is not the best language to build full blown applications with a complex interface, its slow and troublesome to create, although I have done some very big apps myself with AppleScript and Xcode, with 5000 line of code, I would not recommend this to a beginner, as Xcode has little to no help for AppleScript, and you have to learn to understand the Apple's Developer Documentation from the point of view of an ObjectiveC coder.

As for the future life expectancy of AppleScript, no one other than Apple themselves could honestly answer that.
But Apple haven't improved updated or bug fixed AppleScript for a few years now.
And have publicly announced that it wants to remove command line scripting and programming languages like Python, and Ruby Pearl and others on newer Mac OS's, although they can still be reinstalled by the user.
Couple that to the fact that all new applications have to be sandboxed and code signed, with AppleScript applications included in those rules, this does not look good for AppleScript, as by it's very nature is used to issue commands to other applications for the purposes of automation, and use scripting additions, which are also applications in themselves, which makes AppleScript breaks all of the sandbox rules.

Apple have not said they want to axe AppleScript, but reading between the lines, I think they would like to ditch it
For the above security reasons, and seem to have left it do die slowly, with no attention being invested in it.
It just doesn't seem to fit into the future direction of coding on Apple's OS's.
They even fired 'Sal Soghoian' who was the head of AppleScript and 'Automator' at Apple for decades.
So read into that what you want!

Bottom line is, I'm a long time AppleScripter both in editors and Xcode, but I've moved over too 'Swift', and I can do everything that I could do with AppleScript, but a hell of a lot more as well.
I'm even creating a little 'Swift' script editor similar to the Mac OS built in Script Editor, which has code and syntax formatting and colour highlighting, along with code word completion mechanism, which is still a work in progress at the moment.
But I still use AppleScript very occasionally for little tools and utilities.
So if your starting out with coding, and want to put complex UI's on your apps, I would suggest learning 'Swift', its not a hard language to learn coming from AppleScript, where the bigger learning curve is set by Xcode and the 'Cocoa' frameworks, which you would still have to learn if you wanted to put UI's on your AppleScript applications anyway.

Regards Mark

 

[whirl]

Update:
Looks like Mark answered this question above, Thank you Mark

So my issue is hinged around adding files into the Resources Folder

I want to have a custom icon shown when using display dialog so I have placed an icon into the Resourses folder and reference it in the .applescript fle like this

set icon to path to resource "question.icns"

But when I run the script from insie the editor I get a Resource not found error

 

[Mark FX]

That is because your script is looking for the resource file in the Script Editor's bundle, and not your own application.
Please bare in mind that your AppleScript code is not an application.
It's simply text!

Only once you have created an application bundle with a valid 'info.plist' file, does the Mac OS consider it an application.
As previously stated, creating a proper application from a Script Editor is not the best way to go, because of these limitations.
Even once you create an application bundle, if your working on code from a Script Editor, then you will still be accessing the Script Editors bundle, you will have to switch to Xcode for bundle and UI work and testing.

Regards Mark

 

[whirl]

I stared to use Xcode for this simple app as I wanted a GUI. I got about 97% completed until I ditched it because the only part I just could not get to work was getting a Progress Bar to update on the UI and it wasn't for the sake of trying

The Bug in Xcode 13 wasn't helping and when I read that AppleScript projects were not going to be in Xcode 14, my bubble burst

 

[Red Menace]

People have been saying that AppleScript is dead/dying/mortally wounded for over 20 years. It has always been weird and a bit clunky (OK, maybe more than a bit), but there isn't much of an alternative for controlling other applications (despite the security that has been added on the last few years). Personally, Swift gives me a rash, Xcode is a beast all by itself, and since I am not a professional, I try to stay away from both.

The biggest issue with AppleScript is that it was designed to control applications, not necessarily to be a general-purpose scripting language, although it winds up being used for that. Pretty much any other scripting language will be more powerful (and faster), since they are designed to be more general purpose, but to control other applications they all wind up dropping back into AppleScript.

If you don't need to do that, various scripting languages such as Ruby, Python, and of course Swift (yes, it can also be used as a scripting language) also have bridges to the Cocoa API, so it just depends on what you are looking for. It sounds like your main issue with the progress bar is keeping the UI responsive, so another alternative would be to use a separate background application such as SKProgressBar.

 

[casperes1996]

People have been saying that AppleScript is dead/dying/mortally wounded for over 20 years. It has always been weird and a bit clunky (OK, maybe more than a bit), but there isn't much of an alternative for controlling other applications (despite the security that has been added on the last few years). Personally, Swift gives me a rash, Xcode is a beast all by itself, and since I am not a professional, I try to stay away from both.

The biggest issue with AppleScript is that it was designed to control applications, not necessarily to be a general-purpose scripting language, although it winds up being used for that. Pretty much any other scripting language will be more powerful (and faster), since they are designed to be more general purpose, but to control other applications they all wind up dropping back into AppleScript.

If you don't need to do that, various scripting languages such as Ruby, Python, and of course Swift (yes, it can also be used as a scripting language) also have bridges to the Cocoa API, so it just depends on what you are looking for. It sounds like your main issue with the progress bar is keeping the UI responsive, so another alternative would be to use a separate background application such as SKProgressBar.

BTW. I believe it started in Yosemite, but all AppleScript bindings have equivalent JavaScript bindings. You can open Script Editor, set it to JavaScript and use all the same automation capabilities of AppleScript with JS. Here's just a tiny example using the JavaScript bindings for Cocoa automation to show the Music app window and hit the play/pause

var musicApp = Application("Music");

musicApp.activate();

musicApp.playpause();

 

[Red Menace]

Yep, but JXA is a good example of why Apple got rid of the Automation team (IMO). That, and Automator, Scripting Bridge, and generally squandering what automation could have been.

 

[casperes1996]

Yep, but JXA is a good example of why Apple got rid of the Automation team (IMO). That, and Automator, Scripting Bridge, and generally squandering what automation could have been.

I'm not so sure. AppleScript tried to bring automation "to the rest of us", to use the famous phrase. But even if it somewhat could read like English, it was still a language you had to learn to talk to the computer. Automator took the "for the rest of us" a little further and now Shortcuts aims to do the same, once again trying to ease the learning curve and open up automation to more "regular" users. While still maintaining traditional environments for power users who do know or want to know to speak to computers in more traditional languages, and with JavaScript instead of AppleScript it's allowing a scripting language to be aimed more strongly at those who want to "speak computer", keeping the "reads like English" and "for the rest of us" aspects that AppleScript were fulfilling to the GUI based automation tools like Shortcuts. It feels to me like a cohesive sensible path forward to try and allow more automation options and broaden the amount of users who can take advantage of it, not a slow deprecation and removal of automation options. And the macOS security model explicitly has permissions for automation and "allow this application to control other applications". It feels to me like they still want to optimise the potential for automation in personal computing.

 

[Red Menace]

All you have to do is look at the history of the automation team (or even better, that mess of a website by its ex-project manager). AppleScript has been coasting for a long time (AppleScriptObjC is the best that has come out in recent history), the Script Editor is barely adequate (even the lite version of Script Debugger mops the floor with it), scripting support is still lacking, weak, or just plain wack in several of the main applications (Mail.app anyone?), and Automator is goofier than ever (enter Shortcuts). Even the Scripting Bridge is problematic, so now you have NSAppleScript to try to work around that.

Just about everything they did was half baked, the mess that is JXA (JavaScript for Automation) was just the final straw - they took one of the more popular (for whatever reason) scripting languages and extended it in such a convoluted/broken way that almost no one wants to use it for automation. That thing died almost immediately after release (it helped that there was no promotion, documentation, or support), compared to users foaming at the mouth for first-class scripting bridges for others such as Ruby or Python (that got screwed up, abandoned, or dropped) - they would probably have had better results just restoring the old developer dialect for AppleScript so that regular developers wouldn’t run away screaming.

I still use AppleScript for prototyping and small projects, I just understand why Apple did what they did. I only hope that there is enough enthusiasm left for automation "for the rest of us".