Swift scripting

General
#1

Hello all

I know, this is a mainly Applescript site.

What about Swift scripting?
Is there room here to add this to the forum?
In my opinion is Apple secretly dumping Applescript, and my water and someone at Apple tells me that Swift Script is the future, beside a good replacement for Bash.

I did stop using implementing Applescript in my projects since 2021 and in my next project I will start using GitHub - tingraldi/SwiftScripting: Utilities and samples to aid in using Swift with the Scripting Bridge. If you want to automate tasks on your Mac, but don't like AppleScript, this is for you. and Scripting Bridge.

To keep up with the future I guess its not wrong to invest space in this forum about this. Not knowing if there is already any forum about this.

Any suggestions?

1 Like
#2

ScriptingBridge has its pluses and minuses.
I mainly code in Objective-C now. But do lots of stuff with iTunes. (Came from AppleScript) so I started to use ScriptingBridge with iTunes. There are many features where it fails and/or it’s just easier in AppleScript so I still have AppleScript code for executing many functions I need. Now with the ability to just create my own “bridge” header files to point to my functions in AppleScript. I can call them without using Scripting Bridge.

ScriptingBridge uses a lot of pointers/references to objects until you call “get” on the objects. I also use a lot of Predicates to filter items and SBArray’s can’t handle many of them (IE value IN aArray). In iTunes world there is the ITLibrary framework which can handle all of these and is much faster, SB still calls upon AppleEvents which can be slow. Unfortunately with ITLibrary framework you can’t create elements like playlists. It’s more of a framework for querying

#3

Thank you for your reply. I appreciate your comment.

My main target of my post is if there is room on this site to start Swift scripting topics. Are you interested in this; or are there others who want this in this forum?

1 Like
#4

Like any of the other scripting languages, I suppose it depends on how AppleScript is involved - as you mentioned, this has been primarily an AppleScript site for decades. You have been able to run Swift scripts from a playground or shell script for quite a while now, and despite what Apple would like to think, the language is not really for beginners, so the target demographic is a bit different. I don’t even see any Swift scripting tags at StackOverflow, which I would think should be a better target for something like that.

You can do pretty much anything with the Cocoa frameworks, so then the question becomes how much AppleScript do you really need to use. I wind up calling shell scripts more often, and haven’t run into anything that would make me want to use Scripting Bridge over NSAppleScript or plain old osascript. I mainly use AppleScript for prototyping, which despite its quirks, it is better at than most anything else. Personally, Swift gives me a rash.

1 Like
#5

To compare AppleScript with Swift Scripting is a kind of comparing apples with oranges.

The main goal of AppleScript is to control / talk to applications with a quite simple common scripting language and the communication and exchange of data between applications. Swift can’t do that at all.

The term Swift Scripting is a bit misleading. The so called scripts are actually command line tools. However it’s pretty convenient to run Swift code without Xcode from the command line.

Scripting Bridge on the other hand is a – in my opinion quite cumbersome – Objective-C wrapper for AppleScript/OSAScript which sends Apple Events in the same way vanilla AppleScript does. Later Apple introduced AppleScriptObjC which can run Objective-C code in an AppleScript-ish syntax and which became more popular in the AppleScript community than Scripting Bridge

If Apple is going to completely abandon AppleScript, it will do it in favor of Shortcuts.

1 Like
#6

The short answer to your question is that yes, on the MacScripter site there is room for other scripting languages and technologies beyond appleScript.

This would be welcome, and I say that even though I am an AppleScript purist.

(I’m just hoping it turns into something of comparative value to AppleScript and Apple Events and interapplication scripting).

1 Like
#7

There have been many self-proclaimed “alternatives to AppleScript” in the past.

It’s hard to say for or against dealing with Swift Scripting in MacScripter.net.

I am reluctant to suddenly put AS and Swift, which are like “water and oil”, next to each other. Swift, which uses a lot of symbols, and AppleScript, which uses as few symbols as possible, have different styles in the first place. It’s too different.

We propose the idea of setting up a “buffer zone” together, such as a BBS that summarizes “know-how for calling Swift from AS” (on the Xcode Project) and a BBS that summarizes “know-how for calling AS from Swift”.

From here, I will analyze my own past “alternative to AppleScript”.

Many of the self-proclaimed “alternatives to AppleScript” were intended to replace a small part of AppleScript’s processing system, and were optimized for a very limited purpose.

And history has been repeating itself, exhausted by the size of the AppleScript ecosystem and the breadth of the area it covers, and leaving on its own.

(1) Multilingual support
Many of them only worked in an English environment and were not verified. In particular, many of Has’s solutions did not work in the Japanese environment. If it doesn’t work in a Japanese environment, it won’t work in a Chinese or Korean environment.

(2) A large number of runtime environments
There are 11 AppleScript runtime environments by default in macOS, including Script Editor, Script Menu, Switch Control, osascript, Folder Action, and more. Whether or not to include the application’s built-in menus (Music.app, various text editors), calls from macro languages (FileMaker Pro, MS-Office), and various executable tools. Without such a “big picture”, if you are told that it is an “alternative to AppleScript”, you don’t really know what you want to do. In fact, I even get the impression that people who don’t know the whole picture are dabbling in “AppleScript alternatives” to meet a very small number of language specifications.

(3) Poor user character
People who claim to be “AppleScript replacements” have one thing in common: they can’t behave well for some reason.
And the content that makes you happy that “it’s so easy to do!” is very rudimentary. Then, based on that simple example, they tend to start fights with the original residents.
Users who claim to be “Better AppleScript” or “AppleScript replacement” are more likely to start a fight with AppleScript users, and probably waste time.

By the way, this is the fourth attempt to “replace AppleScript with Swift” as far as I know.

2 Likes
#8

Not speaking scientifically, but more a musing. I’ve been spending some time working with SwiftUi and in some ways I think it could be the one that rules them all. The popular generative AIs can write pretty solid AppleScript, JXA, and Swift UI code already. I suspect that Apple will have such generation built-in to Xcode before long and Script Editor to possibly. I already have used JXA to integrate AI into the iWork apps and BBEdit has a chat worksheet “Write a script that retrieves cells A1-H16 from numbers and create a series of Keynote slides from the rows and then write a presentation script.” In someways writing swift UI code in the iPad is very similar to writing advanced Applescript. And it seems very possible that a souped-up version of Script Editor writing SwiftUI with an ability to talk to apps could create the kind of tools we want and more. But this is purely speculative and not based on any specific knowledge.

#9

Here’s the script untested I got from “JXA Helper” custom GPT with the prompt I described in my post.

// Define a function to retrieve data from Numbers
function getDataFromNumbers() {
const Numbers = Application(‘Numbers’);
Numbers.activate();
const doc = Numbers.documents[0]; // Assumes the document is open and is the first one
const sheet = doc.sheets[0]; // Assumes data is in the first sheet
const table = sheet.tables[0]; // Assumes data is in the first table

// Range A1-H16
const range = table.ranges['A1:H16'];
const data = range.cells.value();
return data;

}

// Define a function to create Keynote slides
function createKeynoteSlides(data) {
const Keynote = Application(‘Keynote’);
Keynote.activate();
const doc = Keynote.documents[0]; // Assumes a document is open and is the first one
data.forEach((row, index) => {
const slide = Keynote.Slide({body: row.join(’ ')}); // Combine row data into a string for the slide body
doc.slides.push(slide);
if (index === 0) {
slide.baseSlide = Keynote.themes[0].masterSlides[0]; // Use the first theme and master slide for the first slide
}
});
}

// Define a function to generate a simple presentation script based on the data
function generatePresentationScript(data) {
let script = “Presentation Script:\n\n”;
data.forEach((row, index) => {
script += Slide ${index + 1}: Discuss ${row.join(', ')}. \n\n;
});
return script;
}

// Main function to orchestrate the workflow
function main() {
const data = getDataFromNumbers();
createKeynoteSlides(data);
const presentationScript = generatePresentationScript(data);
console.log(presentationScript);
}

// Execute the main function
main();

#10

Every now and then people will claim AppleScript is dead or getting killed/dumped and I have to admit that it strikes my nerve a little bit. Having written hundreds if not thousands of scripts already in the past few years alone and continue to write more almost every single day. I’ve been using AppleScript since before macOS Big Sur and have experienced controlling macOS UI with little adjustment to the scripts for every macOS version release so I don’t really see the point of killing something so useful. It’s like suggesting stop manufacturing hammers because it is now obsolete and there are much cooler tools already.

I don’t really see the point on the need to replace good tools just because they are old or outdated. I use bash also a lot and it is a good companion to AppleScript. As long as AppleScript can drive other apps/tools, I don’t see how it loses its usefulness.

TBH, I don’t like the nesting in AppleScript that’s why I designed wrapper libraries so I can code almost similarly to other modern programming languages.

1 Like
#11

Hello,
I’ve heard rumors? or complaints that there’s not the community or something regarding Applescript? Applescript has been around since 1992 so there is major support for it I’m guessing. My former job wasn’t in scripting or coding at all so it was a bit of a learning curve to try to implement automation using Applescript and related into my graphics workflow. I couldn’t imagine starting over in another scripting environment.

As an enduser that used primarily graphics apps and related, being able to script various aspects of the GU interface is critical. I also used everything from Automator to UI Browser to iKey (yKey) to older apps as in OneClick (which disappeared by OSX), etc. (I heard about Keyboard Maestro but haven’t tried it out in detail.). It took awhile to build rather involved scripts. One Applescript I used daily (print-file-backup) had 39 separate actions that was activated by one menu item in the main script menu. And batch processing a bunch of files in a folder was the bomb. I have to say, having a resource like macscripter was very helpful. Books were good to some extent, but they didn’t help with specific problems. One usually ended up adapting aspects of various scripts.

Most end users that I noticed at work didn’t use any scripting. In most cases, they didn’t even use macros; except for one person using Word.

I don’t know. I’d rather draw curves rather than get involved w learning curve. Maybe I’m getting old.

1 Like
#12

I’m in a coding background but I also feel getting old. Keyboard Maestro serves as the event bus for me. I didn’t want to invest too much on it initially, given it’s a third party app, but it proved to be indispensable for me now.

I also use Elgato Stream Deck for productivity. I would use Stream Deck and add shortcuts and with a push of a button, I would run an AppleScript via Keyboard Maestro driving the application or website.

1 Like
#13

I think one issue is getting typical endusers in a work environment to utilize automation in their workflow. Everyone that I knew at work that used a Mac, never even uttered the word ‘AppleScript’; even though I went on about it and showed the odd person some of my scripts running.

It seems that if the scripting environment is powerful, it is also complex and comes with a steep learning curve. With Automator for example, it’s way easy and I noticed it has a record your actions option. But there’s always the question of how powerful is it and whether 3rd party apps support it. And from what I’ve noticed, the results of just recording some actions (several mouse clicks) required tweaking or editing of some actions.

The best scripting tool I used so far was OneClick; which as I mentioned, died with the intro of OSX.

From what I did at work, I needed:

  • easy tool to build scripts
  • batch processing of files
  • has to be robust and not go off the rails if one touches mouse for instance
  • support if debugging or looking for a solution
  • apps that have script dictionaries or Automator actions
  • easy and full control of GU interface
  • options in assigning macros or scripts to Fkeys, main script menu, droplet, etc.
#14

Thank you for remembering OneClick! What an amazing tool it was . . .

1 Like
#15

Yea, it was amazing. I have the original manual around somewhere.

When I heard they weren’t developing it due to OSX, I told them I’d pay $400 for it. They responded saying they won’t be porting it :frowning_face: