This is my usability review of Xcode 4, a software development environment from Apple. If you’re not a techie, this will probably lose you quickly. I don’t usually write posts this geeky here because it’s not the theme of this blog, but I do post things related to my interests, and Xcode 4 is a huge part of my daily life as a Mac OS/iOS software engineer.
This is an entirely subjective review based on my preferences. I’m going to focus on conceptual usability of the tool. Wherever it seems objective, it is only because you have found something you agree with. 😉
Note also, I’m still getting used to Xcode 4. If I happen to get any information wrong here, I apologize.
What Is Xcode?
If you want to try your hand at coding for Apple devices, you need to get yourself a copy of Xcode. This is the tool you’ll create and test your application with.
The good news is it’s cheap, $4.99 on the Mac App store (up until this month it was free – I’m told the charge is because of legal issues related to putting it on the Mac App Store and laws enacted due to the Enron debacle regarding earnings statements, blah blah blah ). Tons of documentation comes with it and much more help is available on the web to guide you. After you’ve wrapped your head around things a bit, you’ll be amazed to see all the goodies you get for free from the operating system to make your killer app. The trick is in being clever enough to get people’s attention. Everything easy has been done a thousand times. You have to find a new angle or idea that makes people grin and wave their friends over to come see.
Writing software is not just work to me. It’s something of an artistic pursuit. I started learning when I was 13 on the Apple II+. In high school I did work for my school on TRS-80s. I had some experience on the original IBM PC with DOS. My entire professional career I’ve written for the Mac, and most recently for the iPhone, iPod Touch and iPad. I’m not a Windows engineer or Java engineer, so I can’t compare Xcode 4 to Visual Studio or Eclipse. I’m just going on my experience with the previous version of Xcode and other tools used for Mac software development in days of yore (the 90’s).
Here are a couple of other Xcode 4 reviews I think are worth reading:
Ars-Technica – Xcode 4 hands-on: be sure to RTFM first – John Timmer
Pilky.me – Xcode 4: the super mega aweseome review – Martin Pilkington
You should go read those, just because I’m going to skip a lot of stuff these guys covered. I’m only plunging into some core usability issues here. I don’t have enough time available to write a full technical review.
Let’s Dive In
Xcode 4 is a radical overhaul of the IDE (Integrated Development Environment) and one slick piece of engineering. And by integrated, they mean integrated. It’s kind of mind blowing just how much functionality is leveraged into a design intent on providing everything within a single window.
The release offers some truly remarkable improvements and holds promise for even better things, but it’s not all hugs and kisses. My experience using it the past several weeks has been a mix of joy over the cool new and/or improved features versus extreme frustration with its limitations, and in some cases plain old bugs.
Now, any meathead can complain. I know from my own experience that developers can be the worst patients. They’re generally smart and opinionated; a tough crowd to please. What makes it really hard is we often disagree. We have a lot of different ideas about how things should be and often those ideas contradict one another.
I worked on a developer product years ago. I recall developers pushing hard for changes without understanding or considering how others use the product. They get caught up in what they are doing and want what seems most conducive to achieving those goals. The problem is that what one group wants can significantly pain another. And people will let you know if you mess them up. When you make design decisions, benefits must be weighed against the costs for the whole, not just one group. You know you’re making progress when you find a way to bridge many different interests.
The designers of Xcode 4 put a lot of thought into it. They released preview versions nearly a year in advance of it’s public release, giving developers time to comment on it while they worked. But overall, its clear to me that it needed to finally land somewhere as a GM, a 1.0 if you will, before Apple could focus on bridging their design goals with its practical deployment in the outside developer community. They had to get the design out the door. Now it’s time for optimization.
After working with this release, I think of it as a place to start. I’m not ready to adopt it completely. I want to, but it’s not there for me yet. I can use it, but I still need Xcode 3 on standby. I’ll clarify why as we progress through this review.
What Should An IDE Do?
Getting down to brass tacks:
The IDE should facilitate my ability to access and manipulate data so I can produce a product.
- Anywhere it facilitates, it’s awesome.
- Anywhere it hinders, it sucks.
As a rule: The developer mantra is that everything sucks and we’re here to make it better. 😉 (And then after that, what we did now sucks and we have to start again.)
What Does Xcode 4 Do?
If you haven’t read it, take a look over the Xcode 4 User Guide.
The first image you’ll see is a diagram of the main window called the workspace window. This is where you’ll live in Xcode 4.
Once upon a time Xcode was called Project Builder. When NeXT bought.. er.. when Apple bought NeXT in order to bring us all Mac OS X, Project Builder was NeXT’s IDE. In the early days of OS X Project Builder was locked down to a single window design. Being able do it all in a single window is useful, but not being able to break things out, like open source files into separate windows when desired, greatly frustrated classic Mac developers.
Mac developers at that time were predominantly using CodeWarrior to create Mac software. Apple had MPW before NeXT and some may have continued using Symantec’s THINK C/C++, but most gravitated to CodeWarrior. In any case, none of these environments were designed for single window operation. Suddenly not being able to open a source file in its own window to edit or view made Project Builder’s one window to rule them all approach feel like a prison. Devs complained loudly and Apple begrudgingly adapted Project Builder to allow multiple windows.
I’m told Visual Studio and Eclipse are single window IDEs. A lot of developers are coming to the Mac and iOS with experience using it to create Windows and Android/Java software. The single window experience is what they know and are comfortable with. Using multiple windows is a paradigm shift for them.
Xcode 4 flows from this design philosophy. It is capable of displaying multiple windows, but multiple window support is an afterthought.
Does it matter?
I’ve been asking myself this question repeatedly as I use Xcode 4. It takes time to get comfortable with something new. You have to learn where the rocks are. Reminds me of this joke:
“A priest, a rabbi, and an atheist went fishing. They got in a boat and rowed out to the middle of a lake and began. As the day progressed, the priest announced that he needed to use a restroom. He proceeded to climb out of the boat, walk across the water onto land, and to the restroom. A short while later he came back to the lake, walked across the water, and got back into the boat without saying a word.
The rabbi never looked up. The atheist stared, eyes agape, but he didn’t say anything.
Later, the rabbi announced he needed to use the restroom. Just like the priest, he got out of the boat, walked across the water, went to the restroom, then came back, walked across the water, got back into the boat, and started fishing.
The atheist was blown away. Suddenly, he jumped up in excitement and screamed, ‘I believe! I believe!’ He jumped out of the boat onto the water… and sank straight to the bottom.
The rabbi turned to the priest and said, “I think we should have told him where the rocks are.” –– Dave Allen
Many developers prefer a single window design. It’s also true that keeping multiple windows open often leads to clutter and disorganization. There are distinct advantages to full-on single window integration. It’s also really nice that in Xcode 4 a plethora (flashback to Three Amigos…) of utilities are readily at hand, so you don’t have to continually find and launch a bunch of outside applications. You want to analyze memory usage? Threads? Performance? Just select the Profile scheme and run. Want to build your GUI? Now Interface Builder is built right in. It’s nice.
So, yes, I get it. Being able to do everything within a single window is a feat and quite useful. +1 for facilitation. On the other hand, just because you can do something doesn’t mean you always want to do that.
Take a look yourself. The proof is in the pudding. Go back to my link above to the Xcode 4 User Guide. Take a good look at that first picture diagramming the Xcode 4 workspace window. Then, go through the user guide and look at all the pictures. Notice how most of the images show the workspace window looking very different from the original diagram? Someone has taken time to adjust the window to an ideal state for the task at hand in each instance. That’s great. That’s what you want. You want the window to be in the state most conducive to what you’re trying to do, otherwise you’re being hindered by what a friend of mine calls “a postage stamp interface” where everything is too cramped to be useful.
Let’s look at the workspace window.
The image above shows the window in a non-optimized state while debugging. You could work with things as shown and debug, but you’ll probably want to make some adjustments. You don’t really care about the Utilities area on the right, so you click on the segmented control in the toolbar where it says “View” to deselect the far right item. Ah. Now more space to see your source and the debug area. You want to see the stack crawl, so you go the Navigators area just below the tab bar on the left and figure out which icon to click on to see the stack crawl. Now things are looking good. You’re reasonably happy.
But there are some caveats here. You can drag sliders around and click things to make adjustments for your own convenience, but then you think, “Gee, I’d like to keep an eye on values in some nested object in the var list. If you stay in this window you’ll have to disclose the values of each object in its hierarchy until the value you want is revealed. Then, you may have some other values in the list you want to watch, but now with things all disclosed the list is pretty long. Now you’re scrolling up and down continuously to examine the values. And the print is pretty small. It’s a challenge to identify the precise thing you’re looking for. Oh, if only I could just open these values in some kind of separate personal, oh I don’t know, expressions area or window, gosh that would help. But you can’t.
What you could do is open a new workspace window, customize it down to what you want to see, and keep that open. Or you could create a new tab, customize that down until you see just what you want to see, then switch back and forth as you debug. Bleah.
Suppose you want to enter a custom expression? Good luck figuring that out. I’ll save you some time. Control-click or right-click on the vars list and you’ll see an “Add Expression..” item on the contextual menu that pops up. Only your expression is going to land in the vars list, so you’ll have the same potential issues as above. And Xcode is really weak about keeping context, so the useful life of your expression using a var symbol, which is actually a pointer in the current context, to look at a struct value or something may only last for the current stack frame.
If you’ve stayed in the same window through this, you now notice something when you stop debugging. Your workspace is all setup for debugging. Now you need to customize it so you can work on your sources. Click, click, click, drag, drag, drag. Ok, all better. Wait, I want to debug again. Click, click, click, drag, drag, drag.
You can start creating tabs or open more workspace windows to generate the customizations you want so you don’t have to continuously readjust a single window to get work done. Unfortunately, Xcode 4 has major inconsistencies at restoring things to how you had them the next time you open the project. This will drive you batty. Another problem I have is failing to notice which tab I’m in and messing up the state I went through the trouble to create. Then when I realize I’ve adjusted the wrong tab I start muttering things I won’t post on this blog.
So here’s the score on the workspace window:
- Every workspace window can do it all as needed.
- You can open up multiple workspace windows for the same project as desired.
- You can create multiple tabs in the workspace window and get all the same functionality available in each.
- A single workspace view’s organization is not optimal for every task. You will require customized views for ad hoc purposes to work effectively, but Xcode is poor at preserving your optimizations. You will spend a lot of time recreating your steps.
- Xcode does not let you separate out just the data you want to keep an eye on from piles of other data. It’s a real hassle.
- Xcode has never been much good a resolving expressions involving dereferenced object values beyond the current stack frame.
What Would Be Better
As a developer, my work patterns are pretty static. I script things I need to do repeatedly so I don’t have to waste my time and energy on the mundane. This is true for pretty much any developer. I don’t want to spend my time thinking about the tool. I want to spend my time thinking about my products.
- Xcode 4 needs to allow me to define a base workspace window setup that includes tabs whose state I can rely on. I would be thrilled if I could establish this as my own factory default. So I could do it once then any time after, hit a short-cut and voila, my workspace window and all of its tabs are restored to my pristine work state. I would extend this to allowing an individual tab to be restored to just its original pristine state. (Note: Xcode 4 lets you drag tabs out to open them in a new window, so when I need to see data from two windows in their optimized states, I can any time I want. That’s cool. It would also be cool if I could hit a key and pop them all out into separate windows in one shot, if desired. However, in both cases I’d like a preference to allow keeping the original tabs in the workspace window even after.) – Apple Bug Reporter ID# 9159512
- Xcode 4 needs to support a custom expressions area that I can add any var expression to at my leisure. This way I can avoid endlessly scrolling to find values when I’m looking at nested data and keep an eye on just the data I care about, without distraction. – ID #9159532
- Xcode needs to get a handle on the context of dereferenced objects in expressions so that when that stack frame comes back around again it can properly figure things out and display the current value. I’ll grant the pointer value may have changed, but the symbol name hasn’t. It should be able to do this. CodeWarrior did. – ID# 9159538
- I would like to see tab previews in Xcode. The problem with opening more windows is clutter and disorganization. The problem with tabs is you can’t view more than one of them at a time. Netflix previews are a really great example of dealing with a similar issue. You can just hover over a movie title and bingo, there are the details. Move the cursor away and it’s gone. No context switch. No hassle. Very nice. – ID# 9159525
Besides the workspace window the biggest paradigm shift in Xcode 4 is the introduction of Schemes.
In the upper left corner of a workspace window you’ll see these controls:
It seems familiar to users of Xcode 3, but this is not the droid you expect. Welcome to Schemes.
What Is A Scheme?
From the Scheme Editing Help section in Xcode:
“A scheme is a collection of settings that specify which targets to build, what build configuration to use, and the executable environment to use when the product specified by the target is launched. When you open an existing project (or create a new one), Xcode automatically creates a scheme for each target.”
The Schemes paradigm is going to take some time for experienced Xcode users to adjust to. Schemes create a layer of abstraction that wasn’t there before. They change the focus away from “What do you want to build?” in the sense that we’re used to and reframe it as “What do you want to do?”
My first thought as a dev was more muttering and complaining. I felt disconnected from my prime objective. I wasn’t sure what I was building. I want that information in my face. “Hey, you’re building a debug version of this app!” The layer of abstraction caught me by surprise. But the more I’ve thought about it, while there are some things I’d like to see improved, I think Apple is on target with this one. I just haven’t played the game this way before. It’s still very uncomfortable, but I’ll adapt.
As my colleagues in the reviews I mentioned above noted, you will need to read the manual on this and retrain your instincts to some extent.
On the left in the Scheme Editor window you see a list of named build Actions. These show up in the workspace window as options you can select when you click and hold the Run button in the upper left corner.
The items on the menu correspond with defined Schemes for the workspace. You can select them to trigger a particular build. If you simply click on the Run button without holding it will build for running and run your executable. If you select a different Action from the popup it becomes the current selection and clicking the button will trigger that build and type of Action tied to the current selection.
Confusion: While you are debugging, when execution has stopped at a breakpoint or is paused and I want to continue, I just can’t seem to break myself from clicking on that Run button to continue. But that’s bad. It is not connected to the debugger. It will want to relaunch your executable when you do that. Very annoying.
What I don’t get about the current state of Schemes in Xcode 4 is why I can’t define my own build Actions as well. As far as I can tell you are locked down to the default options. You can edit what these do, but not add more Actions. What if I want to keep around a Run action for my release build? Why can’t I do that? There are times when I need to fix a bug that only shows up in the release build.
[UPDATE: It was pointed out to me that rather than create new Actions, you can create additional named Schemes to accomplish the above. Good point.]
Actions let you define Arguments and Diagnostics as well. So, it would be nice to have a Run build that sets some arguments or diagnostic flags that another doesn’t. It’s very inconvenient having to scuttle back and forth to the Schemes editor to toggle simple settings like these.
As you can see, there is a lot encapsulated by this design idea. I like it. It cleans up a lot of ugliness that was in Xcode 3. It just needs some kinks to be worked out of it.
- Schemes encapsulate a lot of settings and groups them together nicely into a manageable UI.
- You can’t define your own build Actions.
- Toggling arguments and diagnostic flags is a bit tedious compared to Xcode 3.
- The Run button is not aware of the current run context.
What Would Be Better
- Xcode should allow devs to add their own build Actions. – ID# 9159545
- It wouldn’t hurt to have a default build Action to run the release build. – Also #9159545
- It would be nice if the Run button would continue if there is a running executable that is stopped. – ID# 9159552
Odds and Ends
I’m just about out of time available to write this, so I’m going to have to stop. There’s plenty of other things worth writing about, but I’ll just sum up with a list of my own yeas and nays about Xcode 4.
- Auto-complete in Xcode 4 Rocks! I now use it. It’s smart and usually presents exactly what I was planning on typing.
- Xcode 4 lets you add your own code snippets collection. Create your own auto-completions. Sorry TypeIt4Me. After 16 years, I no longer need you.
- The Clang compiler front end provides better diagnostic messages, an awesome static analyzer and faster compiles.
- The LLVM back end matures to version 2.0, providing highly optimized code at link time.
- The app looks and feels nice. It’s organized. Xcode 3 menus alone were an unholy mess.
- Interface Builder integration is sweet. I’m sure this will continue to improve.
- I’ve heard others have had problems with bugs, but I’m very happy with SCM support for Subversion in Xcode 4.
- Xcode 4 now has a built-in hex editor. ‘Bout time!
- In Xcode 3 it was easy to view a flat file listing of all files in a project or folder. That’s missing and needs to be remedied quickly. ID #9159559
- It’s not easy in Xcode 4 to quickly identify which files are included for a given target nor toggle which are included. Another real pain. ID# 9150560
- Xcode 4 is still buggy. It shares bugs with Xcode 3 plus has more of its own. For example, if you open a project set to use an OS SDK not installed (Xcode 4 only includes the 10.6 SDK) you’ll see “Base SDK Missing” messages. If you go and set the SDK to the current available OS SDK, those should go away, right? But they don’t, at least not until you close the project and reopen it. ID #9159564.
- The debugger is still flakey, sometimes going to lunch when you step forward, sometimes continuing instead of stepping, especially if stepping into a function call. (No need to log this… many, many have already.) Of course, I’m not using LLVM or LLDB, so maybe things are better there.
- I desperately hate dealing with Find in Xcode. I haven’t put enough thought into what I’d do to fix it to comment on it intelligently, but I don’t like using it.
- Other engineers are telling me the Help system in Xcode 4 is deeply flawed. I haven’t dug into that enough to comment.
It’s great but it’s a 1.0 in a 4.0’s body. I want to use it, but its problems force me to fall back to Xcode 3 when I need to get around them. (Fortunately, Xcode 4 does not prevent me from going back and forth. The project stays compatible. Big + for facilitation.) I’m really looking forward to the day when it is polished enough that I can forget about 3 and enjoy what Xcode 4 offers.