Recently, the
DotNetRocks Podcast had an episode where the guest spent an hour slamming Xcode, Objective-C, and the Cocoa frameworks, and how awful iPhone development was in comparison to Visual Studio, C# and .Net. The guest went so far as to diagnose anyone enjoying the iPhone toolchain with
Stockholm syndrome.
I wrote the hosts a scathing e-mail, pointing out that I had used a lot of frameworks, and a lot of IDEs—including regular use of Visual Studio for the last 7 years—and that the iPhone coding experience, with the exception of the annoyance of code signing, was second to none in fun. Apparently, the folks at dotnetrocks have a policy for dealing with over the top ranters, they invite them on the show. I'll be recording an episode Monday.
This blog post is part of the process of organizing my thoughts for that show. If I go on and say I like Xcode 3.1 better than Visual Studio 2008, the question will immediately become why. And the reasons behind that are either absolute i.e., that some aspect of Xcode allows me to do a better job than Visual Studio just by having a better thought out design, or personal in that Xcode is embedded in a Mac, and I love my Mac. This post cannot hope to be inclusive and I'll focus on things I don't like about Visual Studio that are done well on Xcode 3.1.
Project Properties
I recently needed to turn off the "/GL" flag in the release build of a C++ project on Windows (because a google of an arcane linker error code said that flag was involved.) So, I had to find that flag in the project properties. And, of course, in Visual Studio, if you don't know where a property is kept, you have to click through all the categories and subcategories until you find it. In this case, despite being about linking it was under Configuration Properties:C/C++:Optimization:Whole Program Optimization
BTW, all these web ready PNGs are just the way OS X takes screen shots. If only I knew how to make Windows XP take partial screen shots directly into PNG.
On Xcode on the other hand, all the properties are visible at once:
And what's that at the top of the page? A search field, you mean I can just paste in the parameter and it will find it? Yes, yes I can.
And what's this thing in the corner "Based on", you mean if I have a project (a solution in Visual Studio speak) with a bunch of sub-projects (a project in Visual Studio speak) that I can create a set of configuration files that are shared amongst some of them and overrided as needed and not have to go to every single project and change its settings when I want to add a path?
And speaking of paths, doesn't this include path dialog dialog look a bit small? Oh, you can resize it like nearly every other window in Xcode
Why? Because Xcode was written in Cocoa where resizing views and windows is easy.
Hey it looks like the Visual Studio include path dialog is resizable too. But only horizontally not vertically, I guess people only need two paths. [Update: turns out it was just really hard to resize, at least for me. The traction corner was not the proper target.]
Profiling
As anyone who's ever coded with me knows, I believe in the power of profiling. It is something I do as part of my personal development process. Both Xcode and Visual Studio have profiling tools. Xcode's tools go by the name of Instruments and they are prominently available in the Run menu.
Here is the Object Allocations Instrument where I can ferret out performance problems indicated by too many object allocations or having objects hang around too long. For instance, earlier in the year, I ran into a problem where I was adding a timer to my run loop every tenth of a second, this was not technically a leak and would not have been solved via garbage collection but did show up in the allocations instrument as a worrisome growing number of CFTimerRefs. Notice that you can analyze and experiment on a running copy; you do not have to deal with after the fact reports.
And you can find the stack trace of every allocation.
As for Visual Studios profiling tools, well I know they are there, as I have used them in the past to find some performance problems and leaks in C++, but I can't even find them right now; that's how ill layed out Visual Studio is that something as critical to the development process as profiling is hard to find. Regardless, as I recall, the tools included were of the old fashioned variety where you ran the app, quit and the profiler would crank away for a minute or two and give you a report which you could browse through and dig into call sequences to find out for instance what fraction of the time was spent in a given method and its children. Useful, but really bare bones. And this
article on Microsoft's site indicates the situation is similar when doing .Net development.
Static Analysis
It is a good idea to run your code through a static analyzer every now and again to pick up the little bits of idiocy we all suffer through. In .Net, the popular analyzer is
FxCop and while I haven't personally used it, I have had our outsource team run analysises and the results have been quite useful especially when dealing with the code of junior engineers. You can get a free static analyzer for Mac and iPhone development too:
Clang and I have used it and it's great at making sure your code is following the rules. Please run it before every release.
Layout
It probably is redundant, that I, a Mac user since high school, prefer the appearance and layout of Xcode to Visual Studio. It's also pretty much a given that where I see large mouse targets and esthetically pleasing use of space, a Visual Studio aficionado will see wasted space and a lack of important buttons. (BTW, if you are a PC user new to the Mac, use your left thumb to hold down the command key not your pinkie like you would if it were the CTRL key. Yes habits are hard to break, that does not mean the Mac's primary meta key is in a stupid place, far from it.)
My biggest peeve about Visual Studio is how easy is to undock an embedded subwindow while doing something else. Honestly how often does one rearrange their project panes? And then I have to figure out where to drag the window back to given this onscreen display:
My second peeve would be the amazingly small tool icons. Monitors are large and getting higher resolution. Icons 4x as big as these would be more appropriate for today.
Number 1 Favorite Features I'd Like to Find in Visual Studio
The open quickly dialog (command-shift-D) in Xcode used to be functional, but a bit lame compared to the one that had been in Metrowerks CodeWarrior, now it's one of the greatest things ever. Just open it up and start typing and as like as not, you will find the file you are looking for in a dynamically filled search list. And it is amazingly fast.
I say like to find, because Visual Studio is so filled with impossible to discover features, it might just have it already.
[Update: Philippe writes to say
Also, a neat trick in Visual Studio that mimics "Open Quickly" is this:
1. Set the focus to the Search field in the toolbar
2. Type ">of " followed by the filename (e.g. ">of MyF")
]
Getting Better All The Time
Long time Mac coders will recall that when Xcode first came out it was much worse (at the very least as a C++ IDE) than the product it killed: Metrowerks CodeWarrior which was a refined, lightning fast IDE beloved by most. But over the years, Xcode has gotten better by fits and starts. And since the iPhone took off, it's been getting better by leaps and bounds. Code completion, which used to be useless is now indispensable. The linker has gotten much faster and memory savy. The new llvm compiler which replaces gcc is fast, stable, and thankfully even tougher on iffy code. I've actually started using in-editor debugging to look up variable values, and like I said before the Open Quickly dialog is fantastic.
To Sum Up
I like Xcode. It is an Apple product, with all the good that entails: esthetics, selective choice of features, performance, ease of use. From a base of high quality, it continues to improve. I suspect it will soon integrate such technologies as Clang or openCL and become even better. PC programmers moving over to iPhone development should give it a chance and try to grok how and why it is the way it is.
[Update: content updated since first post]
