Cocoa and Objective-C: Up and Running (by me) is now available from O'Reilly.

The Sleeper Hit Feature in Leopard

I almost completely forgot about this until Michael McCracken mentioned it, but one of the most significant bits about Leopard for developers (and aspiring developers) are the improvements to scripting support.

First off, using AppleScript to communicate with other apps from within Objective-C is worlds better. Here's what sayeth the article:

The Scripting Bridge allows you to automatically build "glue" code to access a scriptable application with standard Objective-C method calls.

The Scripting Bridge uses native Cocoa data types, such as NSString and NSArray, requires far less code than using an NSAppleEventDescriptor, and runs more than twice as fast as a precompiled NSAppleScript.

And here's what that looks like:

NSString *currentTrackName = [[iTunes currentTrack] name];

This is very good. But that's not even the biggest news. No need to hold your breath any longer:

To open up the benefits of the Cocoa frameworks to a wider developer audience, Leopard embraces two other highly dynamic languages for use in building Cocoa applications: Ruby and Python.

The Ruby and Python bridges will be officially supported in Cocoa, including the key-value protocols. You don't have to choose just one language for your application. You can mix and match as necessary.

Good things are afoot.
Design Element
The Sleeper Hit Feature in Leopard
Posted Dec 13, 2006 — 20 comments below


Davide — Dec 13, 06 2664

This is lovely news.
I have downloaded RubyOSA and I must say I feel much more confortable scripting with Ruby than with Applescript. Accessing cocoa 'officialy' will make the ruby-scripting experience even greater.

Juan — Dec 13, 06 2665

Holy cow! This is going to attract a whole bunch of developers to OS X.

Dale — Dec 13, 06 2666

I wrote about the Scripting Bridge in my blog. My concern is that it will be limited like NSAppleScript has always been, or more recently like the minimally implemented QTKit, iChat Instant Message Framework, etc.

The article's description is just too light on basic detail to determine if it's worth getting excited about the Scripting Bridge. For example, is the Scripting Bridge two way? I assume you can send data to another app, but the article doesn't say this. Can the Scripting Bridge hand data to another app, let this app transform it, and return it to the original app? How do you work out what code to write? Do you have to write an AppleScript to understand each app's Scripting Dictionary and then translate that into Cocoa?

Don't get me wrong. The Scripting Bridge seems great. And I don't expect to have Leopard's developer documentation released to the public. But it would be good if Apple gave us just enough info to know Leopard's technologies will be useful and not another limited framework.

Scott — Dec 13, 06 2667

This is a fantastic feature. I currently have to write applications using a mix of Cocoa and Applescript Studio in order to be able to use scriptable interfaces and real datatypes. It works but it's pretty clunky.

Being able to simply toll-free bridge to a scriptable application is a huge deal. Especially if they still allow bridging between records and NSDictionaries. This'll really simplify a load of my current utility Applescript Studio stuff.


Scott Stevenson — Dec 13, 06 2668 Scotty the Leopard

How do you work out what code to write?

I'm not sure what you mean by this, but I hardly ever use AppleScript so maybe I'm missing something obvious. I always assumed you use Script Editor's "Open Dictionary..." command to understand how to communicate with the application.

Note the key phrase is this:

Scripting Bridge allows you to automatically build "glue" code

Daniel Jalkut — Dec 13, 06 2669

I suspect what Scott suggests is true, that it's just a syntactic shorthand for interacting with any of the published keyed values or commands of a given scriptable application.

So, essentially Apple is providing a proxy object ("iTunes" in the cited example) that probably implements the "valueForKey:" etc methods and creates and compiles an AppleScript to achieve the desired property set, get, or command invocation. Plus, since Apple's in charge, they can tweak for performance and everybody wins.

Pretty cool, if simple, idea.

Clint — Dec 13, 06 2670

I started learning objective-c and then on to cocoa earlier this year. I really like working with objective-c, but i know having another skill to work with would be a great asset (such as python or ruby). I'm wondering what performance penalties, if any, would your app incur for using one or the other as opposed to objective-c?

Jim — Dec 13, 06 2672

I'm wondering what performance penalties, if any, would your app incur for using one or the other as opposed to objective-c?

With a game move search algorithm I did recently, I found that my Obj-C was 30x-40x faster than my Ruby version. YMMV, of course, depending on the nature of the code. For that particular computationally intensive situation, Obj-C was necessary.

For many ordinary apps, I have found Ruby to be plenty fast. Python, in my informal tests, is a bit faster than Ruby -- anywhere from 10% to 40%.

Ruby, however, is simply a joy to use. I'd use it all the time if I could. Once YARV (the on-the-fly compiler in development) is added to the Ruby distribution, Ruby should double, or more, in speed.

Scott — Dec 13, 06 2674


I suspect that what Apple have come up with is an extended framework based on the NSApplescript class. This existing class allows you to load, compile and execute Applescript from within a Cocoa application. However, it's not much fun to use if you want to do anything relatively granular (like get the name of the current iTunes track).

By using a proxy object (as you suggest) with some kind of KVC error checking based on the calling dictionary, I guess you get close to what they're s'pposedly offering.

The fun will start here tho' when working with those, uh, slightly more obtuse Applescriptable applications. There are plenty of Applescript dictionaries out there that baffle even experienced script coders. How that'll all work when you're one level removed behind a toll-free bridge could be entertaining...

mmalc — Dec 13, 06 2675

Laurent Sansonetti gave an overview of some of the new features at RubyConf 2006, reported here[/url/.

Chuck — Dec 13, 06 2677

My suspicion is that the Scripting Bridge isn't a way of hiding AppleScript, but a direct bridge between Objective-C and the Open Scripting Architecture. If I'm right, this makes Objective-C basically a peer to AppleScript rather than a client.

Steven Canfield — Dec 13, 06 2679

The Scripting Bridge analyzes the Applescript dictionary for an app and then generates a header file telling you what the appropriate calls are, since they are app specific. It also sends raw AppleEvents, not compiled AppleScript or interpreted AppleScript. Also, a little bird told me the performance is pretty sweet.

Dale — Dec 13, 06 2680

The Scripting Bridge analyzes the Applescript dictionary for an app and then generates a header file telling you what the appropriate calls are

That's good news. So we don't have to manually do this process ourselves. I was worried we'd have to read the app's dictionary, write an AppleScript to test it (every app's dictionary is different), and then transpose that to the equivalent Cocoa code. Very cool.

Rob — Dec 13, 06 2681

NICE !!!

Chris Ryland — Dec 13, 06 2683

We're not supposed to talk about the scripting bridge details until Leopard is publicly available, but, yes, it's not just a simple hack. It's a "deep, indulgent" scheme.

And, even better, the scuttlebutt (not heard from Apple, so I'm not breaking NDA ;-) is that the Python (and maybe Ruby?) bridge will use Objective-C object management (GC, etc.), so the integration will be great there as well.

Chuck — Dec 13, 06 2684

The Python and Ruby bridges mentioned are surely PyObjC and RubyCocoa, respectively.

Ryan Brown — Dec 14, 06 2707

As far as the Python/Ruby bridge support, they are just endorsing them and improving them. I would be very surprised if any work has been done to integrate the Obj-C GC, as in both cases the Python/Ruby GC is already handling retain counts/autorelease pools/etc for you (the result is you rarely have to worry about mem. management). There is a developer (Laurent Sansonetti, as mentioned in a previous comment) at Apple who has very actively working on RubyCocoa as of late. He has a branch in SVN (apple-unstable) if you want to check it out; the last commit was 2 hours ago :).

Chuck — Dec 14, 06 2708

As of the new release a couple of days ago, RubyCocoa seems to have solved all the issues I had with it (NSView spamming stderr and reference-passing methods not working at all, mainly). Ruby is such a lovely language, it'll be nice to be able to write full-fledged apps with it. It'll be even nicer when YARV comes of age and you can write closed-source apps in it!

Chris Ryland — Dec 17, 06 2737

What I heard is that the PyObjC bridge will in fact use Objective-C object management, which *is* a big deal.

Free papers — Dec 29, 09 7051

Thanks for great materials.


Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Technorati Profile
Copyright © Scott Stevenson 2004-2008