Scriptarian
Matt Rajca (tweet):
Scriptarian allows you to easily automate macOS using the Swift programming language, providing a modern alternative to AppleScript.
[…]
Scriptarian uses a multitude of heuristics and transformation passes to ensure AppleScript naming conventions map nicely to Swift. For example, the property name
uses sslgets imported asusesSSL,url stringgets imported asurlString, and the class namePXCanvasDocumentgets imported asCanvasDocument.[…]
In addition to full support for the Swift Standard Library, Scriptarian includes ScriptingKit, a scripting framework we built from the ground up with Swift in mind. It lets you communicate with any AppleScript-enabled app and even provides various utility functions for speech synthesis, sound playback, file management, process management, and more.
There’s no trial version, but it’s only $10.
There’s a 100% chance Apple either Sherlocks this or buys it, strips it down, and ships it as Script Editor 3.0.
Hamish Sanderson sees potential:
I love the idea of Scriptarian: a clean, simple out-of-the-box alternative to Script Editor + AppleScript that “Just Works”. The minimal featureset is quite acceptable considering it’s only $10; by comparison, Script Debugger 6 is $100, down from $200, which is still not unreasonable for a “pro” tool.
But has some concerns:
And this one’s the deal-killer: For any software that claims to provide a modern alternative to AppleScript, everything hinges upon how well its application scripting support, a.k.a. Apple event bridge, works compared to AppleScript. And Swiftarian’s AE bridge is rubbish.
[…]
Whether an Apple event bridge has any chance of working right depends 100% on whether or not its authors realize that application scripting is far more closely related to relational databases and SQL than it ever will be to Cocoa and Swift.
Again, I have some sympathy for Swiftarian, since even Apple's own AppleScript alternatives, ScriptingBridge and JavaScript for Automation, are crippled, incompetent garbage, while Apple documentation at best leaves you with no clue about how this stuff works and at worst gives you an understanding of it that is 100% wrong. OTOH, even a cursory study of history would've found that this is hardly a new problem and there are numerous previous attempts, both good and bad, from which to learn: Frontier, AppleScript, Mac::Glue, aetools+gensuitemodule, JavaScriptOSA, aeve, appscript, ScriptingBridge, RubyOSA, and so on.
If the first thing I notice about this app is that it’s more than twice the size than the developer claims that it is, I’m bound to get confused. I can’t see any reason for a developer to claim a thing like this if it’s not the truth.
Then I notice that it’s kinda slow, but hey, it’s a work in progress, so I really don’t mind that. And it’s probably faster if I compile it first… Oh, the second claim about the app “Scriptarian can compile your scripts into native executables” is also not true.
I seriously can’t understand why you would advertise features that isn’t working in the state you are selling it. And apparently it will work in the next update, then please write that it will work, not that it actually works.
I still think that this is a great idea, and worth my $10, but it really needs some tweaks on how the developer is trying to sell it.
8 Comments RSS · Twitter
Obligatory: SwiftAutomation. Descends from appscript so has the proven pedigree, but to succeed Apple needs to adopt it and include it in macOS. Let them know you want it.
"There’s a 100% chance Apple either Sherlocks this or buys it, strips it down, and ships it as Script Editor 3.0."
90s Apple, the company that cared about creative productivity software: sure.
2010 Apple, the consumer electronics giant: why should they bother?
@Michael: Ironically, with Siri and voice control, Apple clearly does have a serious interest in non-graphical UIs. What it doesn't have is joined-up thinking skills.
Curiously nobody is mentioning the fact that; since the Swift language is unstable, the scripts will probably break with the next Swift language update.
I don't trust Apple when they say Swift 4.0 will not break Swift 3.0 code; if you do trust them, then this is not a problem to consider until you're eventually hit by it.
@someone: That's maybe only #73 on the list of Top 100 Ways That Swift is a Pain in the Ass, and applies to all Swift code, not just 'scripts'. At least it's only once a year; if only that could be said of the myriad Swift issues that plague us daily.
Stick to ObjC/AppleScript for now if you've better things to do with your time than chase the shiny; they're legacy but they're stable.
@has I would rank it a bit higher in the list because APIs not being stable is not an issue after your code has been compiled. But it is for shell scripts which are evaluated by default by the latest version of the swift "runtime" (this can be fixed with the shebang).
[…] “allows you to easily automate macOS using the Swift programming language, providing a modern alternative to […]
