by , 10:00 AM EST, October 29th, 2003
In the beginning...
There have been two sets of developer tools that have dominated the Windows and Mac worlds for the last several years: Microsoft's Visual Studio line of products, and Metrowerks' CodeWarrior line.
While CodeWarrior is not only credited with saving Apple's bacon when the company moved to the PowerPC in 1994, it has also long been considered the Cadillac of Mac development tools. Apple's own development tools were considered a joke, at least in comparison. Cumbersome and poorly documented, Apple's development tools were weighed down by legacy APIs that often conflicted, while many veteran Mac developers simply accepted it as a matter of course to have to work around especially cranky aspects of the Mac Toolbox.
Microsoft does it right, sort of
Contrast this with Microsoft, which has gone to great lengths over the years to make life as easy as possible for its developers. Big Redmond considers those developers with whom they aren't competing to be vital partners, and after the company stole as much of Borland's brain trust as it could, it poured immense resources into making it as easy as possible to code for Windows.
In most ways, that paid off for the company, as there are extraordinary quantities of Windows software on the market. On the other hand, because Microsoft has made it so easy, a coder doesn't have to be a good coder to crank out that Windows software, which is why so much of that code is junk. This writer has seen that first hand on many occasions.
In the meanwhile, on the CodeWarrior side of things, there was a bit of a hiccup in the move to Mac OS X. CodeWarrior didn't initially support all of Apple's native Mac OS X technologies, which left those developers wishing to code using Cocoa and Objective-C having to resort to Apple's development tools.
Fixing what's broken
Apple, however, had been working to clean up the developer mess since the return of Steve Jobs. One of the first things the company did was to clean up the Mac Toolbox, and get rid of the legacy and redundant APIs that made coding on the Mac harder than it needed to be. As part of that process, Apple introduced Carbon, a set of APIs that worked in OS 9 and Mac OS X, a key tool needed to make migration to Mac OS X smoother for developers and end-users alike.
NeXT, if you'll pardon the pun, the company has also been working on integrating the development tools it gained with the acquisition of NeXT, a process that has been ongoing. NeXT developers swore by NeXT's tools, and Apple wanted to bring that same level of quality to its own line of development tools.
That brings us to today, because Apple has ushered in a new era in developing for the Mac platform. The introduction of Xcode with Panther's release has reset the rules, and in our opinion has placed Apple on equal footing with CodeWarrior, and perhaps even Microsoft's Visual Studio suite. More importantly, through its actions, Apple is demonstrating that developers are important to the company. That's an important message while the company works on building Mac market share.
Inside Xcode
Xcode is an entirely new set of tools for Mac developers. From the interface, to new technologies Apple has built into Xcode, the company's free tools have changed the face of Mac coding. Xcode offers a new interface, and new time saving features, some of which border on being revolutionary in that "Why did this take so long" kind of way.
--iTunes--
When looking at where Apple is going with Xcode, we must first harken back to iTunes. What does a consumer music management and playback app have to do with an Integrated Developer Environment? According to Apple, everything.
We sat down with Wiley Hodges, Apple's Senior Product Line Manager - Developer Products, who told us that Apple turned to its other products to see what it could bring to the developer world. According to Mr. Hodges, the company realized that the iTunes metaphor for managing your workflow would translate well into other areas. For instance, iPhoto and Panther's finder also use that metaphor, with navigational lists and groupings in an always-accessible list on the left, a toolbar across the top, and a details window for the thing you are working on in the main portion of the window to the right. This is how Xcode is set up, as well.
The main project window in Xcode has a Groups & Files area that displays what Apple calls "Smart Groups," as well as files from your development project. Smart Groups have the disclosure triangle that is used throughout Mac OS X. Click on any of the items in the Groups & Files area, and you get the corresponding info in the Details window. From the Details windows, coders can work directly on whatever aspect of the project they need to. Searching is just like iTunes' searching feature, too; it's fast and intuitive.
While the interface itself is not revolutionary, and other IDEs have some of the tools that Apple includes, Xcode brings it all together and offers a working environment that many reviewers are saying is as good or better as any other IDE on the market. It all fits together, puts everything you are working on at your fingertips, and it all makes sense, like a good Mac app should.
Time
Developers spend a lot of time working on their projects, but a lot of that time is spent waiting. In particular, the linking and compiling processes can take lots of time, and that's time not spent on doing what coders do best, writing code.
--Zero Link--
Apple has introduced a new concept in Xcode called Zero Link. To quote from Apple:
Zero Link technology in Xcode links only the few pieces of object code needed to launch the application. The result is that for incremental development builds, linking is usually eliminated altogether, resulting in substantial time savings and rapid turnaround during debugging.
That's a big time saver for developers, especially during the debugging process; but an even bigger time saver is a technology Apple is called "Predictive Compile." This technology will likely be copied or emulated in other IDEs in the near future, but Apple has it now.
--Predicitive Compile--
Predictive Compile allows Xcode to work on compiling code while its being edited. According to Apple, this means that once the coder is ready to test out his new edits, most, if not all, of the compiling has been completed, and the app will be ready to run. This too represents a big time savings for developers, and allows them to be more productive.
--Fix and Continue--
Another time saver Apple has built into Xcode is something called Fix and Continue. Similar technologies have existed in other IDEs, and Apple's inclusion is important for the company's DevTools to be taken seriously. Fix and Continue basically allows a developer to run his app until a certain point, say until he or she hits a bug, edit the code, and then continue running the app. As with the other two technologies mentioned above, this represents a major time saver for developers during the debugging process.
Revolutionary
So far, these technologies and features are all very important, but hardly revolutionary. Predictive Compile is the newest and most interesting of them, while Xcode's interface may be the least noticed, but most effective of the new features.
What we think could be considered revolutionary, is something Apple is calling Distributed Builds, or rather, the fact that Distributed Builds requires a one-time, one-click configuration. As the name implies, Distributed Builds allows software projects to be linked, compiled and "built" across two or more Macs on a network. Now that in and of itself is not revolutionary; distributed compilation technologies have existed in the Unix world for many years. What is revolutionary is the way Apple implemented it.
Using its own Rendezvous technology -- the same technology that makes sharing playlists across a network so easy in iTunes -- Apple has made Distributed Builds a point and click issue. That is revolutionary.
Say you have a small company of four developers (including the CEO), along with a sales force of three, a CFO, and a receptionist. With Xcode installed on each of those ten Macs (nine, plus the company's file server), the developers can utilize spare CPU cycles from up to all ten of those Macs.
During lunch, while a salesperson is out of town, or after hours (and we all know that developers do most of their work after hours), or in some cases even while the receptionist is typing out an e-mail for the CEO, all of these machines are not being fully utilized. By spreading out compilation time via a couple of clicks, developers can shrink build times by a factor of ten, in the scenario above. Add in a rack of Xserves to the equation, and it's an even bigger deal (during our briefing, Wiley Hodges joked that selling Xserves was the real purpose of Distributed Builds). Even single developers working out of their house often have at least two or three Macs lying around, giving them dedicated compilers.
For just about any Mac developer, Distributed Builds will greatly decrease build times, and time is almost always money.
This is why it's such a "Why did this take so long for someone to come up with this?" kind of thing. Again, distributed processing has been around in the Unix world, but our research found that it is considered difficult to set up and a hassle to use. Apple has made it beyond easy. Why is it that no one has thought about making it this easy before?
Well it's here now, and it could be a big deal to many developers.
In conclusion
The process of making Apple's developer tools began several years ago. Like so many of the things Steve Jobs and his team have been working on, it has taken a long time for everything to come together. Apple's retail strategy, making OS X so cool it hurts, bringing the platform ahead to the G5, the iPod, iTunes and the iTunes Music Store...All of these things have taken time, and they are here today. Now Apple has taken care of its developers, too. Project Builder was a stopgap that was hip-deep in its NeXT roots, but Xcode is a Mac OS X app through and through, and it brings together so many different improvements that it puts Apple on equal footing with CodeWarrior, and probably even Visual Studio.
According to Mr. Hodges, approximately 95% of Mac developers are using CodeWarrior. In our opinion, those CodeWarrior developers who stick with CodeWarrior will also benefit from Xcode. Metrowerks is an outstanding organization that makes money for its Motorola masters (Motorola bought Metrowerks several years ago). CodeWarrior has never had real competition on the Mac, and we think that this new competition from Xcode will only lead to an improved CodeWarrior.
That is good news for developers, but it's also good news for Mac users. For Apple to compete with Windows, Mac developers have to have best-in-class developer tools. With Xcode, Apple has assured that this will be case. It may be subtle, but welcome to the revolution.
You can find more information on Xcode at Apple's Developer Web site.