Whither Xcode?

Rick Schaut, one of the devs I work with, had an excellent post back in March about the MacBU’s transition to Xcode. Now that Apple has released Xcode 2.3, I thought I’d chime in with a little more info on our progress.
First, let me acknowledge that as an employee of the MacBU at Microsoft, I too am under NDA both with Apple and with Microsoft. As such, there’s a lot of specific detail I can’t comment on publicly.
I want to start by telling you about my role here. I’m a development lead in the MacBU, with a team of 4 devs reporting to me. (No, Rick is not one of them…) Part of my team’s responsibility is tool evaluation and maintenance. For the last few years I had been our point-of-contact and liaison with Metrowerks. My team tested their pre-releases of CodeWarrior, filed bugs with Metrowerks, updated our code to adhere to their ever-stricter-and-more-standards-compilant compiler, and rolled the updates out to the MacBU as they shipped. Given my experiences with that aspect of our tools and external dependencies, my manager asked me to take the lead dev role in our coordination with Apple as we investigated switching to Xcode.
So, we created a virtual team for me to lead (virtual in the sense that the other devs on the team did not report to me in the official ‘chain-of-command’) and we dug into our source to see what the impact would be. Apple’s announcement last summer about switching to Intel chips took us by surprise. I mean, sure, we had seen all the commentary on the rumor sites and whatnot in June 2005, but way back in early 2004 when we were planning out the schedule for the version of Mac Office to come after Office 2004, we had no inkling of the impending switch and thus had not put any time into our schedules for it! This meant that our early investigations had to not only identify what code would be affected, but how long it would take to change over and how that would affect our shipping schedule. Now, I can’t give any details here, but suffice it to say the changeover would not come for free!
The decision to switch dev tool environments was pretty much a slam dunk, especially after Metrowerks announced they were getting out of the Mac dev tool business and would not be producing any Intel tools. That then set us up to start working with Apple, getting early seeds of what was then Xcode 2.2, and running our code through it.
wwwwwwwhhhhhhhiiiiiiiiIIIIIIIIRRRRRRRRRRRRRRRRR!
That was the sound of the fans in my G5 taking off after trying to compile Mac Office in Xcode! You see, Xcode uses GCC, and one of the great things about GCC is that it is incredibly standards-compliant. Unfortunately, one of the really annoying things about GCC is that it is incredibly standards-compliant. Parts of Mac Office date back to the mid-1980s (Remember Excel 1.0 for the Mac?). Office is so large that the older code hasn’t necessarily been brought up to modern styles/conventions/standards, and we routinely migrate code from Win Office into Mac Office. Win Office uses Visual Studio, which wasn’t always so compliant itself, meaning that we sometimes inherited code that needed some friendly compliance coercion. 🙂 Our first passes at compilation generated almost a million errors and several million warnings!
Then, there were the issues in the Xcode IDE itself. Now, I want to be very clear up front that Apple has done a heck of a job with Xcode. They have been incredibly helpful and have provided a ton of assistance to us as we work on the transition. Apple has done a huge amount of work on Xcode in the last couple of years. Xcode, however, is a relatively new IDE whereas CodeWarrior has been around for over 10 years and had become pretty mature. In the last year, we’ve worked with Apple on literally hundreds of feature requests, trivial bugs and critical bugs, suggestions for future releases, documentation clarifications, etc.
That last bit is actually one of the neatest things about this transition from my perspective. Apple’s tools, being so nitpicky about code standards, have helped us find and fix bugs in our code and make the next version of Office a better product. At the same time, the sheer amount of code we’ve thrown at Xcode have enabled us to help Apple make Xcode a better IDE, which in turn helps us be more efficient, write more features, and yes, make a better product! Our two companies can and do help each other improve. It’s a great concrete example of how positive our business relationship really is.
So, where are we now? Almost done. Yes, Apple has shipped Xcode 2.3. No, the MacBU is not totally done with the transition (more of those picky details I can’t actually talk about.) But we’re close! Perhaps one day soon I’ll get an email (I’m at home on parental leave right now) saying we fixed that last line of code and we’ll be fully on the Steve bandwagon.
With that, I’ll close this out for the evening. Its 12:30am and my new baby daughter is starting to wake up and ask for her next bottle, and the bottle always has a higher priority than the blog…