Bad bugs with Xcode 4.4/4.5

There are a couple of serious issues with garbage-collected apps compiled with Xcode 4.4/4.5 that people should be aware of if they want them to run under OS X 10.6.

First, there’s a crashing bug if you show an open or save panel (not via normal AS commands, but using NSOpenPanel or NSSavePanel), or use threaded animation on a progress bar, and possibly in other cases. The result is a crash that usually includes something like this:

Thread ?? Crashed:
0 0x00007fff828ed9de -[NSImage _allocAuxiliaryStorage] + 158
1 0x00007fff82a71f05 -[NSImage copyWithZone:] + 66

Second, there’s a bug where apps continue to work, or partly work, but messages like this are logged in Console:

objc[201]: GC: 0x10029cf20 + 24 isn’t in the auto_zone, break on objc_assign_ivar_error to debug.
objc[201]: GC: 0x10029cf20 + 8 isn’t in the auto_zone, break on objc_assign_ivar_error to debug.
objc[201]: GC: 0x10029cf20 + 64 isn’t in the auto_zone, break on objc_assign_ivar_error to debug.

At some stage, the app might crash. I’ve also seen symptoms like text entered into a table cell disappearing when the enter key is pressed.

Both the above problems happen only in 64-bit mode.

There appear to be a few workarounds:

  • If you’re running OS X 10.7 or earlier, go back to Xcode 4.3.3 or earlier.

  • Compile as 32-bit only. This probably isn’t a great idea.

  • Compile as 64-bit/32-bit, and set it to run 64-bit only under OS X 10.7 only.

To do the latter, you need to add an entry in the Info tab for your target. However, there’s a bug in Xcode 4.5 that makes adding a new entry here difficult; the Add Row contextual menu doesn’t work, neither do the + symbol buttons properly, and if you fiddle with it it’s easy to end up with lots of irrelevant entries, or worse, none at all.

The entry that needs to be added has the key “Minimum system versions, per-architecture”, and by default it contains a single dictionary. You should change this dictionary to have a key of “Intel (64-bt)” and a value of “10.7”. This will ensure the resulting binary will launch as 32-bit under versions of the OS before 10.7 (provided you have compiled 64-bit/32-bit).

To get around the Info tab bug, you can instead edit the file called -Info.plist, which is usually in the Supporting Files group. Control-click on it in the File Navigator and choose Open As… → Source Code in the contextual menu. Paste in the following entry:


It doesn’t matter where you insert it, as long as it isn’t in the middle of some other key-value pair. If you later modify an entry in the Info tab it will be moved (to alpabetical order) anyway.

There’s nothing like a posting to flush out the facts…

First, Xcode 4.5.1, released yesterday, fixes the Info panel (and general property list editing) bug.

Second, it looks it doesn’t matter because the other problems are fixed by changing the compiler in Build Settings from the default of Apple’s LLVM compiler 4.1 to LLVM GCC 4.2.

Simple when you know…

I took it into my head last night to take the plunge and upgrade from 10.6 to 10.8, and then downloaded XCode 4.5. I’ll wait a few days before being sure these were two very big mistakes. I was just getting used to XCode 3.6’s crummy interface and now I have an XCode that will not even compile the virgin Document.applscript that is created by default when you begin a Cocoa AppleScript project. In fact even if you cut the script to bare

script Document
end script

it will raise the same error:

OSACompile Appname/Document.applescript
cd “/Users/jd/xcode_projects/Appname Folder/Appname”
/usr/bin/osacompile -l AppleScript -d -o /Users/jd/Library/Developer/Xcode/DerivedData/Appname-drdzzorhhjdpldcgptuirupbpcyo/Build/Products/Debug/ Appname/Document.applescript

Appname/Document.applescript:54: error: Expected end of line, etc. but found “script”. (-2741)
Command /usr/bin/osacompile failed with exit code 1

This is great news for a guy who was looking forward to continuing his progress with the lastest and greatest Apple offerings.


PS. I think you can use BBEdit as an external editor for other languages, but not for AppleScript. Is there an editor, eg. TextMate, which does work with AppleScript, that can be used instead of XCode’s dreadful editor?

I have looked carefully at the default Document.applescript in the virgin AS/Cocoa project and can’t see anything that should make it fail. The only way to get it to compile is to comment out --script Document and --end script. The thing will then build and run but, of course, as soon as the app launches I get a ˜display dialog’ with icon 2 saying that “no document could be created”, and the same, not surprisingly, when I select ˜New’ from the File menu.

Can it really be that XCode 4.5.1 was released without anybody checking whether it was possible even to begin building an AppleScript project?! I’d ask the usual “what am I doing wrong?” if it weren’t that I am doing nothing.

Now when I asked if I needed to have a separate pair of .applescript+.xib for each window, Shane said yes. But how? If I make a duplicate of the Document.applescript class, name it Document_2.applescript, build and run”after commenting out --script etc. of course”then I end up with still just one .xib.

It’s all pretty frustrating, especially now that Mountain Lion has deprived me of Eudora and Excel, got the mouse wheel performing in reverse and seems on the one hand to be threatening to delete all my documents if I don’t let iCloud have them and on the other hand failing to get hold of them! Twittering Facebook times, Jeeves!


The default document script does compile. However, by giving it no class prefix, you’re trying to call the class Document. But document is an AppleScript keyword, which is what’s causing your compile error. Wrap it in pipes (|Document|), or better still start again and use a class prefix (eg, JDDocument).

However the default document code, while compiling, is seriously flawed. The code for outErrors is nonsense, and you can’t use the keyword data as a variable.

You can use AppleScript Editor, Script Debugger or AppleScriptObjC Explorer 2. The latter is pretty much designed for the job, offering things like ASObjC code completion. You can download a 30-day trial (see my sig).

(Seems to be ghost time. First Cal turns up on MACSCRPT out of the blue, now look who turns up here :wink: )

Cal !!! That takes me back 20 years!

As to the pseudonym, I’ve no idea why I used it when I subscribed years ago. I’ll drop it and resubscribe as the real…


Model: Mac Mini Intel
AppleScript: 2.2.3
Browser: Firefox 16.0
Operating System: Mac OS X (10.8)

I was surprised at this too, since in XCode 3.6 the class is MyDocument, but I presumed things changed with the namespace of ASOC.

Yes, if I call it |Document| or JDdocument the build succeeds and the app runs but I get no windows whatever I do in Document.xib. Can you suggest a default script to replace Apple’s that will work out of the box, as the script does in XCode 2.6. I 'd be most grateful, as it would get me started. I was beginning to make progress with the previous software and now I’m back to the first hurdle.

Looks pretty good at first glance… but to me an app without a scripting dictionary and a scripts menu is seriously deficient. :wink: Was Cal’s Scripter app scriptable? Where is it now!


Xcode is very much a moving target. (The change had nothing to do with ASObjC; it happened for Objective-C projects too.)

That’s why I suggested starting again. Just changing the name to JDDocument (JDdocument is incorrect Cocoa naming style, and you should get used to the correct style because it matters in some places) is not enough; the name is used in various places. It’s safer to start a new project. And it does work.

It has a (minimal, admittedly) scripting dictionary. The scripts menu decision was partly personal – I already have two (the system-level one and FastScripts).

Not that I recall.

Long dead. There’s not a lot of support for Mac apps written in Pascal these days. If you want a decent general AppleScript editor, Script Debugger is the only game in town. And a great editor it is, too.

But Explorer is the only editor that does any ASObjC logging.

I don’t seem to be making myself clear. I have “started again” a dozen times or more but whatever changes I make in Document.applescript I cannot get the app to produce documents. I just get the dialog “No document could be created”, as I’ve explained before.

Have you actually tried building and running from the template provided in 4.5.1 and getting a document when you type ⌘N ? If you did, and succeeded, how did you do it? All I’m asking for is a skeleton script to get started. It was no problem in XCode 3.6 and there is no problem with a Cocoa Application. All I need do there is create a new project, drag a Text View to the window and run. I get a text editor window on launch and another every time I type ⌘N. Why not so with the Cocoa Applescript project?

I’m not interested at the moment in intricacies of Cocoa etiquette ” I could say some nasty things about AppleScript variable names that begin with the… ” All I want is proof that it is possible simply to begin making a document-based app in a Cocoa Applescript project in 4.5.1. So far I have heard from nobody who can tell me it is or tell me how.


Yes. I just did it again. I suspect you’re trying to add the class prefix after the event; you need to enter it in the Class Prefix field in the dialog that comes up when you create the project. That way it gets used correctly throughout the project.

It’s not a matter of etiquette, BTW. Lots of functionality depends on correct naming.

Shane Stanley wote:

| Yes. I just did it again. I suspect you’re trying to add the class prefix after the event;
| you need to enter it in the Class Prefix field in the dialog that comes up when you
| create the project. That way it gets used correctly throughout the project.

Ah! Now that makes it clear at last. No mention of this little detail in the Apple
tutorials I’d seen.

| It’s not a matter of etiquette, BTW. Lots of functionality depends on correct naming.

So what is the correct way? You’ve already told me JD is not a suitable prefix so what

Then there’s the matter of multiple types of window for the app. Suppose that the
first WIndow object that is listed in jdDocument.xib is to be a text editing doc, I
guess, probably wrongly that I should give the ˜Window’ object a more informative

I now want, say, a calculator window as the second object. I can duplicate the first
object and rename the duplicate ˜calc_window’, but you have told me this is not the
way to do it, and that I should create a new .applescript+.xib pair. I must admit that
this seems to be easier said than done. How do you do it?


That’s partly because it’s a fairly recent change; Xcode used to default to a class name of MyDocument. The class prefix is a relatively new option.

You’ve misunderstood. Cocoa has naming conventions, including about case: class names always begin with a cap, variables and method names begin with a lowercase letter except for proper names, and inter-capping is used strictly. There are other conventions to do with method names. Some are functional, some not. But the key is you said JDdocument – that’s how I knew you had changed it manually, because Cocoa would always cap the D for document, as in JDDocument. So JD is fine as a prefix.

You can give it a name in the dock area of the interface builder, but you don’t actually name it unless you subclass it. To be able to refer to it, you make a property in your doc class, set it to missing value, and then connect it as an outlet to the window via File’s Owner of the document .xib in the interface. The template assumes you have such a property, called window, because that’s how it works in the Objective-C template. But that obviously won’t work for an AS class, so the project template is problematic here too.

Do you want a second window, a second window for the same document, or a separate window for a different type of document? At its simplest, you can have an outlet to another window in the same .xib, and simply open and close it. It’s not great design, but it works. If it’s going to be related to the document, you may also have to subclass NSWindowController, which also means removing the windowNibName method and implementing makeWindowControllers instead. A different app type with its own window will mean separate document, .xib, and window controller subclasses.

If you’re going to try to build anything but the most basic of document-based apps, you really need to read the Document-Based Application Programming Guide. This stuff isn’t intuitive.

Go to File → New → File. For a .xib, you will want User Interface → Empty, and for the AS classes you will want Other → Empty, making sure to include the .applescript extension when naming it.

Well, intuition comes from observation through experience”that’s the origin of the word, so it certainly is not intuitive for me!

Thank you for the explanations and the pointers.

As to the “Document-Based Application Programming Guide” you
mention, it looks as if I should start here:
Is that what you were thinking of? Thank you.

It’ll all be great fun once I get going. I remember what a pain it was
getting into AppleScript when it first came out and all I knew was Excel,
QuicKeys and OneClick. Frontier Usertalk was a lot worse and Perl even
worse, but I now almost dream in Perl and use it for almost everything.
It won’t take long.


Model: Mac Mini Intel
AppleScript: 2.2.3
Browser: Firefox 16.0
Operating System: Mac OS X (10.8)

Yes, but you can also find it by searching in the Organizer window of Xcode.

Ah good! Another useful discovery. It’s getting better.:slight_smile:

I’ve had a few crashes for reasons that were clear enough but which ought to have been caught, but I suppose 4.5.1 is still pretty raw.

One problem with the Organizer window : you can click a button in the corner to make it full-screen, but how do you get back to normal? I tried the esc key and all sorts of combinations but had to quit to get back to normal.


Model: Mac Mini Intel
AppleScript: 2.2.3
Browser: Firefox 16.0
Operating System: Mac OS X (10.8)