Ten Things I Dig About Xcode
by James Duncan Davidson, author of the upcoming Running Mac OS X Panther10/24/2003
Following in the footsteps of the Ten Things I Dig About Panther article that was published on October 10, and to celebrate the public release of Mac OS X today, I've decided to focus in on the eleventh item from that list, the revamped IDE, called Xcode. There's a lot to like about Xcode, and the rest of the toolset now known as the Xcode Tools.
As with the last article about Panther, this is by no means an exhaustive feature-based review. To be honest, it's going to take a bit of time to pull together a really good review of the new Xcode IDE and to explore all of its capabilities. But, in the short amount of time that I've played with Xcode so far, these are the things that I've found myself really digging about it.
1. New User Interface: The first and most obvious thing you'll notice about the new Xcode IDE is that the Project Builder interface of old has been totally replaced with a new and much more polished UI. The old Project Builder interface was functional--good enough for day-to-day work, but evidently was not something that Apple was happy with. So they brought in their UI experts--the same ones that worked on the new Finder and iTunes--and rethought how the IDE should go together. The result is something that just plain feels a lot more polished and honed.
|
2. Smart Lists: The new UI is more than just window dressing. The Xcode team is out to make sure that you can drill down to just the code that you want to focus on. Think about how Smart Playlists work in iTunes. Now, apply that to an IDE and you have an idea of how these lists work. For example, if you click on a target in Xcode, you'll just see the files related to that target. It's a small thing conceptually, but in large projects with lots of targets, it's quite handy to drill down to just the code that you are interested in at the moment.
|
3. Symbol Browsing: So far, my favorite mode of working with code in Xcode isn't a bullet-point item on Apple's web site, but it should be. It's the Project Symbols view--instead of navigating your project file by file, it allows you to take a look across all the symbols in your project--the classes, methods, functions, and variables that make up your application. In the short time that I've been playing with Xcode, I've used this feature more than any other to navigate through the source code in my projects.
|
4. Fast Search: Just like iTunes, the Xcode IDE sports a quick-find box in the toolbar that allows you to drill through the items in the main list. Combined with the smart lists, this will let you find anything you are looking for in a snap.
|
|
Second, the errors and warnings are flagged with icons in the gutter of the text editor. This indicates quickly what line an error is on while letting you just work with the code, without a lot of clutter in the way. Very elegant and nice.
|
6. Three Pane/One Window Use: Even though by default Xcode opens source code in separate editor window, you can activate the one feature I really liked about Project Builder: The ability to have a single window for navigating and editing your code. To enable this, simply hit the three-pane icon in the toolbar.
|
7. Documentation Viewer: Lucky seven and one of the best. Again, this isn't a feature that's been pushed on the Apple web site before the release of Panther, but it's one that I think is the biggest help of all--the ability to quickly and easily go through the Apple developer documentation. The documentation viewer sports a quick-find box in its toolbar (like Finder and iTunes and Mail and... you get the point) and it lets you blaze through the documentation in a flash. Before this feature I was a regular user of both Cocoa Browser and AppKiDo. Now, I find myself using the built-in documentation viewer all the time and prefer it over either of those two tools that I used to rely on so much. Both Cocoa Browser and AppKiDo have features that aren't in the Xcode documentation viewer, but the single ability to quick search through the documentation makes those features less critical to have.
|
8. Code Completion: Finally this useful, and long overdue, feature comes to the Apple developer tool suite. I've always been a fan of being able to save keystrokes, and the code-completion features in Xcode promise to help shave off a bit of time--as well as repeated trips to documentation to remember how to spell a particular method. There are a few key sequences you can use to activate code completion: Hit Control-. (period); Option-Escape; or F5 (or fn-F5 if you are on a PowerBook). These keystrokes will pop up a window from which you can pick the appropriate item. You can also turn on code completion full-time in the Navigation section of the Xcode Preferences. I'm sure that this will cause a slight performance hit on slower machines, but it seems to perform well on my PowerBook.
|
9. Predictive Compilation: I'm a big fan of letting the machine do as much work as possible in the background while I'm thinking about other things. Instead of making me wait on a compile, predictive compilation promises to speed up the process quite a bit. Instead of waiting for you to hit the build button, Xcode will go ahead and compile changes in the background--and then commit them to disk when you hit the build button. I haven't had the chance to exercise this feature with a large project, but so far, it seems to work as advertised.
10. Revamped /Developer/Applications Directory Organization: The /Developer/Applications directory was getting a bit crowded. In Jaguar with the developer tools, it was always a crapshoot whether you'd have to scroll in column view to find the Project Builder icon. Apple must have realized that 90 percent of the time, when you go to that directory, you want to launch Xcode, so they cleaned it up and moved the various accessory tools to their own subdirectories. Now just Xcode and Interface Builder applications appear in this directory.
|
Just like with the Panther article, it's too hard to limit myself to just ten items. So, here's one more...
11. Rendezvous-Enabled Distributed Builds: This one is probably the excuse that I'll use to go ahead and buy that dual G5 machine I've been lusting over. At MacHack this year (which was the weekend before WWDC), there were a few of us gathered around talking about our hacks. One guy had the idea of doing distributed compilation with Rendezvous. He didn't finish his hack, but just a few days later we saw the same idea demonstrated at WWDC in a demo of the axiom that great ideas show up in more than one place at once. It's nice to see Rendezvous being used for more than just chatting and music sharing (much as I use those two features all of the time). I foresee lots of interesting things in the future when it comes to Rendezvous and Xcode.
|
Mac OS X 10.3, widely known as Panther, is available from the Apple Store. Apple includes the developer tools with the operating system, so you can start working with Xcode right away. |
There are so many other cool features that I could talk about here. Zero Link and Fix and Continue come to mind. But so far, these are the ten, 'er eleven, things that I've really been enjoying about using Xcode. It definitely represents a major shift in Apple's IDE and I think it will take people a little while to get used to this new tool. It's also different enough than Project Builder and other IDEs that it's going to take a few months to really start getting the hang of how to best utilize it, but there's some serious potential here and I'm really happy to see Apple investing the same kind of attention into the IDE that it put into iTunes, iChat, and the rest of the applications that ship with Mac OS X.
Of course, as great as the new Xcode is--and how far things have progressed since the last release of the developer tools--there is always more that could be done. There are many things that I would like to see in future versions. Here are a few of them:
The ability to build a distribution build directly into a package without having to use Package Maker externally. It should just be a one-click build command from within the IDE to make a complete, ready-to-ship binary.
The ability to define subprojects or declare dependencies on other projects. Sure, you can structure targets together for quite a bit of flexibility, but there are several bits and pieces of code that I reuse among many of my projects and I'd like to just declare a dependency on that project instead of either creating a target separately in each project or importing the code.
The ability to integrate unit testing tools into Xcode. Agile programming is all the rage these days--and for good reason. Test-first development has changed the way I create code. Currently, the existing tools have had a limited amount of integration with Project Builder. What I'd like to see is the ability to design unit tests alongside the code, and have the test errors show up in the "Errors and Warnings" list as well as in the editor gutters. There are a few ways this could be done, but Apple is probably going to have to expose a bit of functionality for the tools to plug in nicely.
However, I'm willing to wait a little bit for these features to hopefully come to the toolset. This release of Xcode is a welcome improvement and a big thumbs up goes out to the Apple Xcode team for all the hard work they've put into it.
James Duncan Davidson is a freelance author, software developer, and consultant focusing on Mac OS X, Java, XML, and open source technologies. He currently resides in San Francisco, California.
Return to the Mac DevCenter
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 15 of 15.
-
it's a shame..
2003-11-26 17:27:39 anonymous2 [Reply | View]
from the point of view a java programmer, it's interesting to note that project builder's achilles heel was its lack of code completion.
i was going to say that i was a fool to think that code completion would work this time (java). but now that i think of it, i wasn't a fool; i was simply lied to.
not only was the product renamed, hyped, but it advertised code completion!
having read the discussion threads to this article, i now realize that of all features, code completion is not even addressed for java programming (and care must have been taken to hide this information (side note: i'd rather be told it not work than be lied to)).
what exactly does this say about this "xcode" product? my conclusion is that java developers should not hang their hopes (and waste their time) on ide's with the apple brand, unless they submit to writing proprietary code.
well, at least there's a java runtime on this os.
i should have listened to uncle bob when he said: get either of these two ide's: intellij idea or eclipse
-
Adding Additional Libraries
2003-11-05 03:48:00 anonymous2 [Reply | View]
My question does Xcode offer the ability to plug-in libraries or API's, for example, ColdFusion or ActionScript?
-
J2EE
2003-10-30 10:23:25 altjeringa [Reply | View]
Where did J2EE go? Did I mess something up on install or did Apple drop J2EE Xcode support when they went GM. It was there in the Developer releases. Oh well, looks like JBuilder is finally releaseing for OS X again.
-
XCode NRFPT
2003-10-30 09:35:21 anonymous2 [Reply | View]
I have been using XCode since the original release, and I'm afraid that it is mostly smoke and not much fire. Most of the much-promoted features (distributed compiles, zero-link, fix-and-continue) either don't work or don't deliver on their promises, and the UI is a mess compared to PB, which wasn't any prize.
IMHO, Apple should have simply added the speed features to PB and _called_ it XCode -- the UI didn't need to be made both more complicated and less useful. The manhours saved could have been used on making the speed features actually work correctly.
Simple, basic example of the klutzy new world of XCode:
Say you notice that you have several files in the source-code list that are "dirty". You command-select them all, and attempt to "Save", because XCode has an annoying habit of crashing at bizarre moments.
Oops, Save is not available -- the only way to select Save is one-file-at-a-time, and the file editor itself has to be the first responder, not the file list. Really dopey.
So you go to Save All -- and instead of Saving All, you get a window asking you if you REALLY WANTED TO SAVE.
How stupid is this?
A giant step backwards in fundamental usability.
We won't even talk about how the Find functionality has been gutted.
And if anyone can tell me an easy way to embed a framework in an application while not including the headers, I'm all ears. I would use a static library, but of course static libraries don't import objective-c categories correctly -- an amazing bug that should have been targeted a long time ago instead of wasting Apple man-hours on replacing the PB UI with an inferior one.
And while I'm whining, what genius decided that "Project>AddFiles..." would disallow adding a file from inside the project folder? How brain-dead is that? Someone actually had to DECIDE to do this. Actual man-hours were spent implementing this silliness!
I find it hard to believe that Apple's own development team is using XCode -- every time I try to do something new, I spend hours fighting the development environment.
-
XCode
2003-10-29 13:31:33 anonymous2 [Reply | View]
I like XCode and had no problems moving from Project Builder whatsoever with my Giant Java Project. That's the first time moving from one IDE to another, or even moving within the same IDE from version to version, hasn't required me to rewrite at least one line of code before a successful first compile. I eagerly await the "native" Java target for the IDE, so that I can play with the runtime relinking too! Congratulations, Apple, and thanks!
-
This is a general problem with the Mac GUI
2003-10-29 08:55:42 anonymous2 [Reply | View]
"when you edit multiple files, you ask to compile, you get the window asking to save the files, but hitting enter does not "click the default button" of the dialog. Instead, you have to click manually with the mouse."
I hate to say anything nce about Windows, but in Windows keyboard navigation is a first class citizen, not an afterthought. Regardless of the API you use, what apple calls "full keyboard navigation" is enabled... and it goes far beyond what Apple provides.
I use a Mac at home and Windows at work, and every morning and every evening I go through a frustrating readjustmant. On the Windows side it's the usual "you never know what the h*ll Windows is doing" problems. On the mac it's going back to the "one hand on the keyboard one hand on the mouse" navigation... not only does Apple have lousy keyboard navigation, but if you're mousing around you have to keep your fingers ready for option-click and command-click.
-
xCode for ObjC/Cocoa App
2003-10-28 22:53:16 anonymous2 [Reply | View]
I actually liked Project Builder, but made the switch to xCode to keep up with the Jone's. The transition has gone smoothly. I am not seeing all the crashes that some have reported.
My application is a straight forward Cocoa ObjC development. My Project Builder project imported nicely into xCode keeping all the build styles. The debugger doesn't seem quite as reliable.
I turned off the auto code completion as it was slow and just wasn't intuitive enough.
One thing I liked about Project builder was containing everything to one window. XCode seems to allow editing in one window, but that's about it.
I don't really see Xcode as an improvement, just a change. So for now I will stick with xCode.
I considered using Java for the development, but the performance was so substandard to the native Obj/Cocoa API's.
-
XCode java and Extensions
2003-10-27 19:48:21 anonymous2 [Reply | View]
How does XCode handle Java Extensions.
For example, if I drop in a .jar file into
Applications/Java/Extensions/HttpUnit.jar
will XCode pick it up, and will I be able to
import com.meterware.httpunit.*;
We need a java documentation update for XCode.
-
not really...
2003-10-27 06:33:31 saneh [Reply | View]
XCode has what looks like a lot of cool features, but the UI is so buggy, it's extremely painfull to use. I'm keeping a jaguar box to do developement until usable version comes out.
Amongst unbelievable UI bugs:
- when you edit multiple files, you ask to compile, you get the window asking to save the files, but hitting enter does not "click the default button" of the dialog. Instead, you have to click manually with the mouse.
- when you ask for a single window to edit file, the tool insist on opening a new window every time you ask for a new file from the keyboard.
it goes on and on... This tool *IS* unusable!!! unless you are willing to put up with at lot of frustration.
stephane
-
Errors and Warnings
2003-10-26 11:04:51 anonymous2 [Reply | View]
I too can't seem to get the "errors and warnings" smart list to work.
I'm compiling a Java project, and any errors show up in the "detailed build results" window, but not the "errors and warnings" list, which is greyed out 90% of the time and filled with bogus errors the other 10%.
Anyone been able to get this to work?
-
Am I the only person who's baffled by the new Xcode?
2003-10-26 09:43:43 anonymous2 [Reply | View]
Hi,
I'm an avid, albeit hobbyist, programmer -- relatively new to OSX (coming from linux) and have written code for several platforms (embedded motorola chips, win32, java, BeOS). So, for what it's worth, while I'm no professional, I have quite a bit of experience with different IDEs as well as the good old configure/automake/make triumvirate. I've made a lot of IDE/build environment transitions, and I always manage to blindly grope my way through.
Coming to OS X, the best thing, I thought, was how straightforward Project Builder was -- it only took me a couple weeks to grok it; hell, most of it I figured out just porting over my old code from linux. I learned it by using it. I also bought some O'Reilly books, of course, to familiarize myself with Cocoa and Darwin.
Anyway, I've been hammering on Xcode for the last couple days now, and frankly, I feel like a babe in the woods. It's not like I'm averse to change -- it's just that PB was *simple* enough that it was easy to do a number of diverse things... dare I say: PB seemed lightweight. Xcode seems more like... emacs (if PB could be compared to VI). I'm lost! It's like having your dishwasher be replaced with an industrial autoclave.
Thank god my old PB projects build still, but I'm having a hell of a time doing the simplest things like making a new dynamic library and having it "see" internal project dependancies correctly. I'm working on a system that's heavily dependant on plugins, and while my *old* plugin targets still work, I can't duplicate them -- the vanilla "Library" option is gone. The old ones seem to have been given a legacy "grace" target of some sort. And the new library options won't build.
Well, I'm sure that given a couple weeks I'll figure this hoo ha out. But it's a shame that it's going to have to be like going through high-school all over again. Confusion, akwardness, shame, and failure. A big waste of time.
Personally, I'm ready to shell out whatever it costs for anything O'Reilly publishes that purports to teach me Xcode. I'm excited about the improvements Xcode delivers... particularly in regards to live searches and better SCM. I just wish the Xcode docs had a "what's new and how to grok it" section.
Sincerely,
A baffled programmer.
-
Subprojects and Unit Tests
2003-10-25 10:02:17 iapole [Reply | View]
Nice article; good quick overview.
As for your wants, I should note that there was something in the Xcode release notes about subprojects. I believe that you can now add a project to another project and have your targets in the enclosing project depend on targets in the subproject.
Also, there are unit testing frameworks available which do just this. I don't know much about them, but OCUnit and ObjCUnit (I think) are both just exactly like that. As to whether they work in Xcode yet or not, I dunno.
-
Uhh...
2003-10-25 09:35:45 anonymous2 [Reply | View]
Great review, except you forgot to mention that because of many bugs Xcode is almost unusable in many aspects. It is of course understandable, as it's in early iterations and can be compared to early ProjectBuilder in Mac OS X 10.0, but still it is riddled with various bugs, small and big. I am sure Apple will be improving the situation, though, but Xcode in it's current shape cannot be recommended as a development environment as-is, IMHO.







there are a few patterns you can notice about any review of ' free software'. the 'good' items are basically "this feature is a good idea and they have a good start on it" or "this feature is great, and as this is only an alpha version im sure it will be fixed". the 'bad' items are all things like horrible user interface, crashing, etc. the problem here is that unix people, and free software people in general, do not care. they dont care what you think of the UI. their attitude is to tell you to go use windows. now if you say it crashes, they will call you a moron and say you were using it wrong and say 'shrug' it never crashes for them, must be your configuration.
if you point out that other products have good features and dont crash, then they will tell you 'then go use those products, nobody is forcingg you to use this free software'.
if you try to point out that claiming 'this product has feature x' actually implies that the product has feature x, then the linux zealots (im sorry, unix, free software, they are all the same basically) will start screaming at you. you can call it a 'lie'. everyone in the civilized world knows its a lie to promise somethign and not deliver. except in the IT world we know that 'lie' has taken on a special meaning, as has 'promise'. but in unix/free-software 'lie' and 'promise' are useless abstractions. to mention these words is like speaking in cherokee about health care to an audience of chinese cabinet makers at a woodworking convention. the concept of 'lie' and 'promise' are as alien to the world of unix software development as a razor is to richard stallmans face.
thats all well and good. its a free country. you can make horrible products and scream at people for pointing out their flaws, and its a free country.
but apple is a company. they supposedly want people to use their product and they supposedly care about peoples feelings, or at the very least they care about their credibility amongst professsionals who are trying to use their tools.
it is as though merely by using unix, they have allowed themselves to become polluted by the unix ideology of software development: hate users, make half-assed horrible GUIs that crash all the time, and ignore the consequences: the cconsequences being that everyone says 'screw it' and goes and uses Windows instead.
maybe the apple shareholders should read this page, because i am sure the ravneous gnu hippies that have infested Apple are sure as not going to do anything about these problems. they ARE the problem.