Applescript Studio Projects

I’ve copied the SDK over and it seems to be working. Thanks again for the help.

I’m also wondering, is it still possible to get Xcode 3.2.6 for Lion?


Apple says: Xcode 3 is incompatible with Mac OS X 10.7 Lion

Thanks again Stefan

Incompatible with Lion heh? That’s a bummer… now I’ll have to rewrite all the apps that use Interface Builder’s plug-ins, like BWToolkit. I don’t know why they haven’t brought IB plug-ins over to Xcode 4… not nice. :slight_smile:

I just noticed that there are some tutorials on the web to get Xcode 3 installed on Lion


are you saying it’s possible to continue to develop AS Studio apps with XCode 4 if you install the 10.5 SDK? I am still using XCode 3.2.6 on Snow Leopard for this reason, but this is interesting. I thought the only option (for Lion+) was to install both XCode 3 & XCode 4.

Also, do you have any idea whether it will be possible to accomplish the necessary signing (of AS Studio apps) for Gatekeeper on OS X 10.8?

I don’t think that installing the 10.5 SDK will let you do AS studio apps any more than you can already. And AS studio is as far as I know, considered obsolete by Apple, which means it will be purely and simply rejected during the app store review process.

Believe me, the switch to ASOC is well worth it, even though the step is high for long-time applescripters. And it’s a really a big help in understanding Objective-C/Cocoa, which is the next natural step.

And I would be cautious with installing unsupported things in Xcode. I installed Xcode 3 on Lion and it broke the app store’s submission tools, the only solution being to reinstall from scratch. So be sure you have a up-to-date backup before you install this.

Good luck!

Browser: Safari 6533.18.5
Operating System: Mac OS X (10.6)

Well that’s not encouraging, but I also am not sure it’s true. I contacted Developer Support to ask them the question about submissions to the App Store, and essentially I was told there was no policy to reject but basically they weren’t sure. And I’ve heard other reports that there are AS Studio apps in the App store. But I’ve seen nothing absolutely definitive either way, which is a bit maddening.

That said, my question was not about the App Store. It is was about continuing to develop apps on Lion+, and about Gatekeeper. I’ve already decided it’s probably not worth the effort try to submit these apps to the App Store as what it require seems so uncertain (especially with sandboxing). But I want to be able to upgrade to (Mountain) Lion and continue to maintain and upgrade existing projects. And with Mountain Lion, at least I want to be able to get the necessary certs for Gatekeeper.

As for “makng the switch”: no way in hell. My apps are far too complicated to port to ASOC, they’d be complete rewrites anyway. For sure if I did that I am going to go straight to ObjC. Already burned once by Apple on this right? (With all the sandboxing requirements coming up, I don’t even see a bright future for vanilla AppleScript without any interface integration. I mean if there are steps being taken to lock things down so much how could they possibly allow AS to survive as is?)

The guidelines are clear:

Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected

Studio is officially deprecated as of Lion, so that looks pretty clear-cut.

You can do that with a hack that lets you run Xcode 3 under Lion, but I’d be very surprised if that’s an option in 10.8. OS versions and Xcode versions tend to be closely related.

The certs don’t rely on an OS version, and you can code sign from the command line.

If they can be written fully in Objective-C, that would make sense. ASObjC is really more sensible for apps that require AppleScript (i.e., they drive other apps).

If changes like this are your idea of being burned, then you’d probably be better off steering clear of Objective-C too. Apple’s APIs are changing all the time, with old ones being deprecated regularly. (That’s probably more what’s going to kill many ASStudio apps; already some of the APIs it uses are deprecated.) AppleScript users have been sheltered from all this – the silver lining to being largely neglected.

They might just be a bit smarter than you give them credit for. No need for FUD.

I totally agree with every one of Shane’s statements. I also think that you will eventually need to rewrite your studio apps, that for me is a given. I had complex projects in studio too (+6000-9000 lines), and rewriting them saved about 1/3 of the lines of code, either because cocoa already had methods I wrote code for or just because I did optimization.

I’d say start writing ASOC apps right now if you haven’t already, no matter the OS version, app store or not, gatekeeper or not, you will profit from this in the long run because then objective c is a natural step from ASOC. At least, it made things a lot easier to understand for me. And it’s way, way more easy to mix ASOC code and objective c than mixing studio and objective c.

Right now, I either do a hybrid with processor intensive operations done in cocoa, and the rest in ASOC, especially if I need to drive other apps, or i do pure cocoa. Depends on the project’s complexity of course, but this is working for me now. And it’s really easy to switch ASOC classes to cocoa ones later down the road.

Browser: Safari 6533.18.5
Operating System: Mac OS X (10.6)

Thank you, Shane. Those are very sensible responses, though not the ones I want to hear. :slight_smile:

OK. In that case, any thoughts about why it might not be possible with 10.8? And more importantly, what can be done about it? Bottom line is that I really can’t convert most of my existing projects to either ASOC or ObjC because they’re just too complicated. (Leon mentions a project with 9000 lines. One of mine has that many lines in the main code, but relies on several external script libraries that make it 4x that at least.) It seems to me I’d have to completely recreate them, or else abandon them. (And yes, Shane, BTW, I bought your book “ but I haven’t had the chance to read it yet, still too busy putting out fires here.)

So that seems to leave the option StefanK suggested:

Would that actually make it possible to maintain AS Studio apps using Xcode 4? Is it possible this would be a better option than a concurrent installation of XCode 3? Or could I possibly do both?

That’s a very good point. Most of my apps do really require AppleScript as they interact with other apps. The most complicated one maybe a little less so, however.

my suggestion about 10.5 SDK refers to the ability to compile an app with a deployment target of 10.5

This may not work so well for larger projects but after installing Xcode 4 I moved a small (<400 lines) ASS project out of Xcode entirely:

  1. Change the name of the main script file to “main.scpt”
  2. Make sure the following keys are in the Info.plist:
  3. Wrap the script in a “using terms from application ”
    The app can now be simply opened and edited in AppleScript Editor, plus a stand-alone IB 3 for editing AS info in the nibs (although without the Xcode integration you can’t easily change the script that elements are connected to).

I think it’s a matter of more stuff changing under the hood, basically. I might be quite wrong, but I think it would come as a great surprise to most people if it happened.

I feel your pain. Now you have some idea of what it’s like to be a Carbon developer…

There’s just no easy answer. Yes, conversion largely means re-writing. If the external libraries are just plain AS libraries, they will need little work. It’s only the interface-related code that will be useless – and in a lot of cases bindings can greatly simplify things, especially if you use thing like tables.

On the positive side, you’ll probably end up with better and faster apps. You’re likely to end up with less code, and the whole class thing lends itself to much more convenient code arrangement – just having scripts able to talk to each other opens many new doors, and can get rid of tedious workarounds.

As Stefan says, he was addressing another issue.

Well all the code that interacts with other apps is pretty much going to keep working fine in ASObjC.

It’s nice to find out I’m not alone with these issues. I also have a complex ASS project I want to migrate over to Mountain Lion. I currently maintain it in Xcode 3.2.5 on Lion. From the discussion above I understand it will be possible to sign the release builds from these ASS projects so they’ll pass ML Gatekeeper ?

But whether the app itself will run is an entire different story? In the above discussion, nothing has been said about entitlements yet. My script communicates with QT and iTunes, so I guess that will be a no no. Or could these be incorporated as well while reminding in Xcode 3.2.5?

So, now I’m not sure what to do: try to continue the 3.2.5 ASS route, or abandon all hope, and upgrade to Xcode 4 and ASObjC. I understand the latter will be the smarter move in the long run, but we have several users that will be left out in the cold when they upgrade to ML soon.

Yes – signing can be done from the command line.

That’s right.

That’s because entitlements are to do with sandboxing, which is separate from Gatekeeper. You only need to sandbox if you’re trying to get into the Apple Store – and that’s not going to be on with an ASS app.

The first thing you might do is join the developer program so you can try your ASS version under ML. That might answer the question for you. And you’ll have to do it to be able to sign your code for Gatekeeper either way.

FYI, I did join the Mac dev program some months ago, and was able to code sign AS Studio apps and build them with Xcode 3.2.6 on Lion. So the apps run on ML with gatekeeper.

I did have access to the ML dev previews, but had not had the time to see whether Xcode 3.2.6 would continue to run on ML. Today I did those initial tests on the release version of ML. Unfortunately what I found was that while Xcode would launch and seemed to have no problem building existing apps, Interface Builder 3 hangs on launch.

I would very much like to get it to work with ML (otherwise I’m effectively stuck on Lion forever until I can migrate all my AS Studio projects!).

I’ve posted about this and included a portion of the IB crash log in Apple discussions. Any insights here or there greatly appreciated.

A separate disk or partition is probably the only option.

But I’m struck by the contrast: you don’t want to be stuck in Lion, even though it was current until this week, yet you seem to want to stick to ASStudio, which was deprecated three years ago. Something’s going to have to give, it seems to me…

Shane, thanks for your response. You are certainly right that “probably” a separate partition will be our (I’m not alone) only option. But probably is not definitely and clearly we wouldn’t be looking for a work-around if it seemed impossible. As it happens, we’ve made some progress getting IB to launch on ML. Currently the issue seems to be a lack of connections to objects.

I dont’ see why you think it’s such a contrast. There’s absolutely no irony here. I have multiple, highly complex projects written in AS Studio, which can be built and run just fine on Lion and when so built, also work as designed on ML and code signed, too. Other than maybe some interface bells and whistles, they perform their jobs as designed and users continue to find them just as helpful on ML as they did on Panther or Tiger. And I have been able to continue to support 10.4-10.8 and intel/PPC for most projects, to boot! Meanwhile, ML clearly offers advantages and features as an OS. Given that development work is not my full-time occupation, and working in XCode comprises only some portion of my time, why should I need to sacrifice the benefits of the current OS on the Mac that I work on daily?

Well you don’t, at least while you’re not doing Xcode stuff, if you have a separate partition or disk. And if the projects are all working fine, and “they perform their jobs as designed and users continue to find them just as helpful on ML as they did on Panther or Tiger”, then I don’t quite see why you need to spend much time on them in Xcode anyway, so it would seem a minor compromise.

I can understand your frustration, but really, you’re playing Russian roulette. That’s OK if you like that sort of thing, but it’s a bit more complex when others are depending on your stuff too.