Xcode is the primary development tool for any Mac or iPhone developer and is where we spend much of our time. As such new versions that bring new goodies are like Christmas for many developers. The fact that the version number has gone from 3.1 to 3.2 is deceptive to the huge amount of improvements that have been added.
For a lot of developers, a compiler isn't really much to get excited over. It takes your code, checks it, optimises it and converts it to something the computer can read. Usually any updates to the compiler just improve compile times a bit, optimise your code a bit more, fix some bugs or add a few more options.
However, LLVM has got a lot of people excited. It debuted in 10.5 with the LLVM GCC 4.2 compiler. This used LLVM for the optimising and converting to machine code (the back end) and GCC for the checking the code (the front end). New in Snow Leopard is the Clang front end.
But just being new isn't cause for celebration unless it does something worthwhile to use it over the older, more mature compiler. Thankfully it does, and it does it in huge strides rather than small increments. Clang LLVM 1.0 is possibly the biggest improvement to any tool in a Mac or iPhone developer's toolset since OS X was first created.
First off, it is FAST. Take your current GCC compile times and reduce the time by about 40-50%. This is a crazy speed improvement for something that is doing essentially the same job.
Secondly, it makes your code faster. It adds a new optimisation level that performs link-time optimisation. This allows it to do many more cross file optimisations. Anything that can make your app run faster without having to change any code is very welcome.
And lastly, it produces sane and actually useful error messages. For a long time we have had to put up with GCCs rather cryptic error messages. It would tell us there is an invalid binary operation with a + sign on a certain line, but if there are multiple + signs on that line then it is fairly useless. Clang tells you exactly which + sign is at fault.
If you passed in the wrong type into a function or method then GCC would tell you that there is a type mismatch. Clang tells you which argument, what type you're passing in and what the type should be.
And finally, the single best improvement in error handling is that you miss a semicolon from the end of a line, Clang will tell you the exact line it is missing from, unlike GCC which will put the error on any line except the line the error actually is on.
But Clang's introduction as a new front end isn't just good for speed and error messages. It is licensed under the BSD open source licence, meaning that Apple can integrate it tightly into Xcode. This means they can use the exact same language parser for compiling as they do for code completion, refactoring etc. This could lead to a huge number of great new features in Xcode to bring it truly up to par with the likes of Visual Studio and Eclipse in terms of its knowledge of your code.
One of the new features that Clang makes possible is the new Static Analyser. You may have heard about and used the Clang Static Analyser from the command line in Leopard, well now Xcode includes it and provides a nice GUI for it.
So what is static analysis? Well it is the analysis of your code to search for common bugs. It doesn't actually launch your code and run it to test (hence the static). It can find all sorts of errors such as code that will never be called, possible memory leaks or crashes. Because it can search multiple paths through your code very quickly it can find bugs that you would never be able to find on your own and also point out assumptions you have about your code that aren't explicitly written in your code.

While Xcode has got quite a few new goodies, most of the stuff to get excited over are improvements to old features. Perhaps the single biggest improvement over Xcode 3.1 is the build results window. To start with, it just looks great. I can only hope the rest of Xcode gets the same cosmetic treatment at some point in the future.
But this isn't just looks. You no longer lose older warnings when you re-compile. The new filter bar at the top allows you to view all warnings and errors in your project since you last did a clean and build. And best of all, it persists across launches! You can also choose how you want the view to be grouped, either by the build step or by the type of issue that is showing up.

It also improves unit testing by no end. As you can see in the above screenshot, it now gives you details about how many tests passed out of how many ran and how long it took. It also allows you to see the full text of the error without having to go and search through the full text build log (which as far as I can see, actually isn't accessible any more, but pretty much everything you care about is accessible through the details buttons for each warning or error). This essentially fixes all my issues with running unit tests in Xcode.
I previously mentioned that error messages had been improved if you use Clang as your compiler. Well that isn't the only improvement to errors. The inline error bubbles introduced in Xcode 3.0 have been massively improved. They were always a great concept, but they caused all sorts of problems, the key one being that they reflowed your code. Well not any more.

As you can see they are put at the right of the code view, with the full line highlighted. You may also notice a small red arrow under the "e". This is thanks to compiling with Clang, which tells you precisely where the error is. This fixes pretty much every issue with the error bubbles from previous versions.
Every developer needs to read documentation, but the documentation viewer in Xcode has long been one of those things Apple has struggled to get right. The incarnation in Xcode 3.0-3.1 was reasonably useful but somewhat awkward at times and used up a lot of valuable vertical screen space for displaying search results.
The new documentation viewer is a huge improvement, though it may take some time to get used to. The whole documentation set download system has been moved from the documentation window and into the preference window. It also allows for custom doc set feeds to be added, which I don't believe was available previously. [UPDATE] Apparently this was new in Xcode 3.0
With the left side of the window freed up, search results can now be displayed there. Results are now grouped by how they were found, either by API, title or full text. It also only shows the most likely matches and hides less likely matches until you want to look at them. Coupled with this is the fact that the full doc set has been updated to the new style that was introduced with the iPhone SDK, which is a much nicer layout.
One thing that Xcode doesn't do any more is install a huge collection of developer samples. Instead you can search for samples via the documentation viewer and download them. It is nice that you have a bit more disk space, but I think this is outweighed by the fact that you have to re-download all the sample code you used. It would be nice if they had included some of the more venerable samples by default.
Xcode 3.2 also does away with the research assistant, which I always found a useless piece of carp. It replaces this with a new pop up doc panel, which is reasonably useful. This is accessed by the option double click that usually performed a search in the documentation viewer (the shortcut for this is now command-option double click).

There are lots of other little improvements all over the place. For one, the code completion has improved dramatically and is far more accurate than before. No longer will you get isEqualToSet: appearing as a completion for a variable that is an NSString.
The new project and new files panels have also been improved a huge amount, with small variations on a certain project or file type being moved to an options bar. You can add options for your own templates quite easily, they are only managed by a plist file. Unfortunately I can't find any official documentation on it, so for now it is a case of seeing what Apple has done and copying it.

In the world of multi-touch trackpads, Xcode isn't being left behind and now has a few gestures of its own. Much like with other browsers, 3 finger swiping left or right will move back or forwards in the history. However, 3 finger swiping up or down now moves between the header and documentation windows, which is a great new feature and one I wish I could have on my iMac.
Speaking of file history, the history now stores location within a file as well as the actual files you accessed, giving you a much more fine grain control of going back to where you were.
The old find panel has been replaced by a Safari style find bar, which removes yet another piece of needless clutter. It still supports all the stuff you expect such as regular expression search. It also has a rather nice bezel that comes up when your search loops back to the top of a file which is a nice touch.
This reminds me of another thing that has been improved. I wouldn't class myself as a designer, but I am anal about pixels in a user interface. Xcode 3.1 and lower didn't use a standard search field, but instead had a fake field. The magnifying glass was too big and the edges weren't properly anti aliased. This drove me mad, as when I notice things like that I will forever notice them (such as when iTunes had one corner not being antialiased on its window). Anyway, this is now a standard search field now, so the pixel anal side of me can now rest easy at night.
There is one last thing that has changed, which is kind of significant. For decades the standard monospace font for coding on a Mac has been Monaco. In Snow Leopard apple introduced Menlo, a new font based of DejaVu Sans Mono. It is meant be designed with Objective-C in mind, and in deed some characters do seem to be improved a lot over regular DejaVu, such as the square brackets which are much crisper.
The big problem is the * character. Call me a traditionalist but it should be a superscript character, and in Menlo it isn't. It isn't like it is a rarely used character when coding, you use it everywhere and it really grates me. I tried Menlo for a few hours and then had to switch back to using regular DejaVu. It may be nice for some, and it does indeed have some nice improvements that even I, as someone who isn't really a font geek, can notice.
In a nutshell Xcode 3.2 is easily the best update to Xcode to date. Given the scale of the improvements and the fact that it needs a new OS, it is puzzlingly that they haven't called it Xcode 4.0. I can only assume that if this is what Apple thinks warrants a .1 increase in the version number, then Xcode 4.0 will be a huge improvement.
Like with the rest of Snow Leopard, Xcode 3.2 is a release that is built around polishing what is already there and introducing new technologies upon which the next decade worth of software can be built. I believe what we have seen thanks to the release of Clang is only the tip of the iceberg compared to what could be possible. We may now be up to version 3.2 of Xcode, but we are only just beginning to see what Xcode could become.
To access the build log transcript, select all lines in the Build window, ctrl+click, then copy and paste.
Good post! Had been trying to decide if I really wanted the Snow Leopard update, as my Mini is barely 4 mos. old; wasn’t sure I’d really benefit that much from it. However, the improvements to XCode alone warrant the upgrade, it seems.
millenomi: You can also push the “three lines” button at the very right of the row of a build phase to show the exact transcript for that phase.
“Speaking of file history, the history now stores location within a file as well as the actual files you accessed, giving you a much more fine grain control of going back to where you were.”
And as someone who relied on the old behavior this change is a huge pain in the ass. I wonder if there’s a pref to control this…
You should consider correcting the typo in the title
teh ? The ?
The typo is intentional
Two things:
1) You can get the full text transcript using the context menu in the build results window. Rather than opening in a cramped split view, it gets a full text editor window for itself, and can be saved, searched, and edited as a text document. You get different transcripts depending on whether you’re viewing All Results or Latest Results.
2) Per Jonathan Wright, hold down the Option key to get the old file-based Go Forward/Go Back behavior. We rarely change established behavior like this when adding new options, but in this case, the majority of users considered file-level navigation Broken and location-based navigation Correct, based on their experience in browsers and other IDEs. We chose to give what more people considered the “obvious” behavior the pride of place on the keyboard shortcut, but the old way is still there.
Two other favorites:
* Sensible tabbing between placeholders in snippets (or shift-tab to go backward)
* Bracket matching (type a closing bracket and it types a missing opening square bracket for you)
I’m still amazed that no text macro editor is included, and no third party developer sells one. Even though it’s simple text, it would be convenient to have it built into Xcode.
Are you using the 10A432 seed?
Xcode hangs when I run a Unit test target :(
Chris: Ah cool, didn’t notice that, though I’m sure I tried right clicking. Granted the new build window makes needing to view the raw build log a fairly rare event.
Geoffrey: I dunno how I forgot to mention those two in the article as I’m using them daily. As for text macros, you can edit them by hand. Alternatively you could use a 3rd party code snippet manager like: http://www.mcubedsw.com/software/codecollectorpro ![]()
Kiran: I haven’t had any issues running a unit test target on 10A432. Is this a new target you’ve created in 3.2 or one brought over from an earlier version?
I had migrated my OS from 10.5 via WWDC seed and ten constantly updated it via Software update seeds. Now I have updated this with 10A432 seed. Also I have uninstalled and reinstalled Xcode.
Unit testing fails for newly created projects. For Xcode to hang, all I need to do is :
1. Create a new project from template Cocoa based App.
2. Add a Unit Test Target to the project.
3. Add a Unit Test case file to the target created in step3.
4. Add a dummy test case in the newly added file. [This does not affect the hang]
5. Select and Build the Unit Test target.
Xcode hangs at this stage. The Console shows the following :
Aug 31 11:14:40 Kiran-Bs-Mac-Pro Xcode[1793]: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x200f4daa0
Aug 31 11:14:40 Kiran-Bs-Mac-Pro Xcode[1793]: -runOperationInBackground raised an exception: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x200f4daa0
Not seen anything like that, I recommend filing a bug or asking on one of the mailing lists
Great article. Can’t wait to get my hands on Snow Leopard.
Good post. Although, I’m not liking the lack of the ‘Errors and Warnings’ pane one the left anymore. That’s really quite annoying.
OK thanks a lot for confirmation. I have put in xcode-users mailing list. So far it seems to be an isolated issue which many other developers are not observing. But I cannot get Unit tested on any of my Macs. I have tried it on 2 iMacs, 2 Mac Pro and a Mac book. Xcode always hangs.
Same problem happens to me, no matter what I try. Tests worked fine on Leopard.
[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance 0x2950660
I’m running Snow leopard, using XCode 3.2 and its hanging on my unit tests as well. I’m running the calculator unit test example program provided by apple. At the bottom of xcode, it says its running a custom build script, and thats where I get the beachball. Only way to get out of it is to force quit.
Does anyone have a solution to fix this?
I have reported this as a defect in Radar and it has been marked as a duplicate. They have acknowledged that its a known issue.
So hopefully, it will be fixed in 3.2.1 ![]()
But one thing that I don’t understand is how is works for some developer? ( like the author of this post has no issues running unit testing)
I can regenerate 100% of the time on at-least 4 different Macs.
Creepy
Jarod & Kiran I posted a quick blog about the workaround for unit tests hanging in Xcode 3.2 on Snow Leopard.
http://www.artin.org/geekblog/2009/09/xcode-snow-leopard-logical-unit-tests-hanging/
I should have used the little check box “Notify me of follow-up comments?”. I missed your post Aaron.
I was back here to update others about the fix available in Xcode 3.2.1.
Wish I had saw your blog post earlier :(