Applescript Studio Projects

You’re welcome. One suggestion: start converting the simplest app you have. Some things you won’t have to change, like if… then… else, repeat loops or calculations (set myValue to myValue +1), but things like UI elements and table views contents will be new.

But with Shane’s book (the only one in existence about ASOC, as far as I know), will really help. And there is tons of examples.

Also, search within the MacScripter forums if you have questions, most questions a beginner could have probably have already been answered before one way or another.

Again, good luck!

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

A couple of weeks ago I had to reinstall my computer because of a partition problem. I installed Lion and realized I didn’t have any disk images for Xcode so I went to the App Store to get it. It, of course only lists Xcode4. When I run Xcode4 I’ve realized there is no SDK for 10.5. The apps I build will need to be allowed to run on OS 10.5 and later, are there any recommendations with how I proceed with this issue?

Thanks

Hi,

you can add the 10.5 SDK from an existing Xcode 3 installation just by copying the file.
search google for xcode 4 10.5 sdk, there are some tutorials

Thanks Stefan. I’ve seen a few conversations about doing such, but I wanted to get some feedback from this group before I did it. To see if other people discouraged against it. I really just have too many computers still running 10.5 that use the apps I create to cut off support for it.

I appreciate your answer, thanks again.

But consider that PPC support is dropped since Xcode 3.2.6.
The 10.5 SDK does not contain the ppc. architectures.

On my machine I have an additional Xcode 3.2.5 for Tiger and PPC support

That’s ok, I can get away with saying I’m not going to support PPC anymore. It’s 10.5 that is a bigger challenge for me.

Thanks again

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?

Thanks

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

Stephan,

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:
    CFBundleSignature
    aplt
    NSAppleScriptEnabled
  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.