About
This is the M Cubed Software weblog. To find out more about us head to our about page.
Search
Feed
Archives
- March 2010
- February 2010
- January 2010
- November 2009
- August 2009
- July 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
Xcode 3.2: teh awesome edition
Posted on 30/08/2009 at 05:43 PM in General
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.
Clang LLVM 1.0
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.
Static Analysis
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.

New Build Window
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.
New Inline Errors
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.
Improved Documentation
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).

Other Bits & Bobs
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.
Overall
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.