AppleScript - is enterprise-ready? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

Cause of the huge iPhone/iPad penetration our partners we have a new requirement.

We can solve those issues with AppleScript (ie. sending iMessages) but is this scripting system enterprise ready? I mean,

• a dummy question first: is it silent? or it will show 1000 windows to send 1000 email?
• is it stable and durable? (ie. is sending 2000 screenshots és 1500 imessages okay?)
• is it "mature"? I mean if I'm using PowerShell then I feel myself in secure. Not too much superise, not too flat learning curve.

Share your experiences and insights please.

Answer 1

• Is it Silent, depends on the app and your scripts, a lot of app will want to open a window on the screen etc, the level and type of support apps can have for AppleScripts can vary greatly.
• Is it stable and durable, sort of, the issue is AppleScripts is not very fast, it does everything with AppleEvents, and so you can get timeout issues with AppleEvents a lot, or AppleScripts that take a long time, though I have to admit I haven't used AppleScript much recently but when I have with the modern faster CPUs, this is not as big an issue as it was in the past.
• Is it mature, its been around longer than Mac OS X, the biggest issue with AppleScripts I have found is the language looks like natural language which gives you the impression that you can just write something that match its natural language pattern and it will work, but this is not the case, and because of its natural language like syntax it takes a while to know what will work, it mot like other languages where you can work out the syntax and then pretty much any combination that obeys that syntax will work. I still get frustrated with operation that work on list, the language give you the impression you can do some filtering ops on any list when in fact its up to the app you are AppleScripting to supply that functionality for you, for example you can ask finder to get every running app that has some property from every active application, but if you have your own list you have to enumerate over it manual and inspect each item individually.

AppleScript is a language you can experiment with easily so I would just try some stuff out to see if it works the way you want, and then flesh out if its successful. People have used AppleScripts to write full Cocoa application, but I have never thought it was suitable for something like that.

Answer 2

Nathan Day's answer is right. But there's more.

AppleScript can be split in two layers - the Open Scripting Architecture layer and the language AppleScript.

Open Scripting Architecture is what facilitates sending and responding to Apple Events, which is what gets sent across applications. With Open Scripting Architecture, there are ways of using the same functionality without using AppleScript.

For example, Apple provides the Scripting Bridge framework, using which you can write this code in Objective-C and Cocoa (and by extension in other code which can itself bridge to Cocoa).

There are also other libraries for other languages, like the Ruby rb-appscript and rubyosa libraries and the Python library appscript.

All of these are viable alternatives to learning AppleScript and may fit better with the experience and competence at hand since AppleScript is, to put it mildly, an acquired taste that takes longer to master than its syntax makes it look, and which is hard to effectively put to other use than OSA scripting.

Answer 3

@Jesper: Scripting Bridge is problematic and appscript and RubyOSA are effectively dead so you shouldn't be recommending them.

...

@boj: Asking if the AppleScript language itself is "enterprise-ready" is the wrong question, because that's by far the least of your worries. What you should be asking is:

"Can I build high-reliability headless systems out of desktop software running on desktop hardware?"

and:

"Is Apple the right choice for server-side anything?"

iOS may be a fine consumer-oriented mobile platform and OS X a decent desktop OS, but as far as the server room goes I wouldn't touch them with a bargepole unless they were the absolute last and only option (e.g. you're stuck using one of OS X Server's proprietary services, with no other alternative). Virtualization isn't a good idea IME and enterprise basics like LOM and rack-ready enclosures are non-starters. And don't forget Apple's tendency to suddenly/radically revise its product lines, features and services with little or no advance warning. If you want enterprise-level stability, predictability and support, stick to Linux and/or Windows boxen.

In your case you're talking about using iMessage, and since that is 1. a proprietary protocol, and 2. Apple haven't to-date made the underlying APIs public then that does really narrow your options. First thing you should probably ask yourself: are you sure you can't achieve a suitable solution with SMS, which is both open and already well supported at enterprise level? I think you could make a strong business case for that: it may cost a bit more to run, but point out they're paying for stability and reliability and (you hope) a professionally-constructed system.

Anything you build around Messages.app will be an amateur lash-up by comparison. If you are forced down that road, you had better do your research and do not make any promises in advance. For example:

• What could cause your system to fail (e.g. application dialogs popping up on a headless box are a serious PITA, and don't discount application crashes, connectivity issues and other possibilities, up to and including the box itself dying)?

• What sort of downtimes are you looking at, and what are the cost implications of any failure? (i.e. What's your expected SLA for this service?) If it's anything remotely-business critical or corporate's demanding more than, say, two-nines uptime then run, don't walk, to an existing solution.

• What are your options for recovering/restarting the system when something goes wrong (e.g. will you try to jury-rig some automated failover, or have someone remote into the box to try to fix it, or is there an on-site admin to cycle the power), and are there any data loss or other issues you need to worry about? (e.g. You might want to keep your business logic and database on a separate Win/Linux box so that the system doesn't lose track of where it was when the OS X box plays up/gets rebooted.)

• What is the deal regarding system maintenance: if you're unreachable or no longer there, will anyone else be able to nurse the code and/or deployed systems without you?

BTW, WWDC and 10.9 are not too far away now, so I would recommend waiting to find out if the iMessage API will be public in 10.9 before spending any time on AppleScript and Messages.app. If/when the messaging API is opened up, it would allow you to build a more robust service in ObjC, though mind you'll still be tied to OS X in order to develop and run it.