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:
- Change the name of the main script file to “main.scpt”
- Make sure the following keys are in the Info.plist:
CFBundleSignature
aplt
NSAppleScriptEnabled
- 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.