Weblog

Stream of consciousness from the minds of es

Xcode; the app we love to hate

Monday, June 26, 2006

Let's first get this out of the way; I find using Xcode to be a generally pleasant experience overall. Furthermore, having free dev tools is amazing and makes the barrier to enter the Mac programming market basically nothing. The amount of good shareware increases every day and that's in large part to Cocoa and Xcode. Apple should be commended for allowing this to happen.

That said, everything is not roses in Xcode land. When I was only doing shareware development part-time for the software you find on this site, I had no complaints with Xcode. In fact, I thought it was good...not as good as Project Builder mind you, but good enough. When Wade would complain about Xcode from time-to-time I would almost always respond with, "I don't see that problem." Cut to 9 months ago when I was hired on by Panic full-time. I found myself quickly seeing Xcode in a different light. :) For the last week, I scratched down a note whenever I ran into a problem or 'unexpected behavior' in Xcode. Without further ado I will present to you, my humble reader, this list in no particular order.

Setup: Xcode in All-in-One layout, dual 2 Ghz G5, 1 GB RAM.

- Splits are not always remembered when clicking the warning/error button in the status bar.
- Hangs when opening a framework project if another project is open (have to force quit Xcode 4-5 times a day when working on this framework - new in Xcode 2.3).
- Loading large projects is very slow (new in Xcode 2.3).
- Very slow loading the application into the debugger.
- Doesn't always stop hitting breakpoints when they are removed in the debugger.
- Xcode doesn't visually show hit breakpoints in the UI if they are too early in the code execution (read: GDB is stopped on the breakpoint, but the UI doesn't show it so you can't debug in the UI).
- SCM support ends renaming every half second or so when creating a new group in the project file (read: type one character, it ends editing, type another, end, type, end...).
- Fix and Continue doesn't work with a mysterious dylib linked into the project. Xcode simply says "dylib not found." We link against several, which I can assure Xcode, exist.
- In some version Xcode it stopped allowing you to include Applescript files in the resources folder.
- The text editor randomly stops showing edits. Type, nothing happens in the UI but the file is changed. Have to restart Xcode.
- Counterpart button doesn't always enable when it should. Doesn't work with linked in framework headers (I think it should be smart enough to figure out where the counterpart is in the framework).
- After Fixing and Continue the next breakpoint stoppage sometimes will cause the app to crash.
- Doesn't remember turned on columns in SCM Results list.
- Sometimes resets column size in the Detail list to 'very small.'

These issues alone may not seem that big or annoying. However, when you compound them by 8 hours a day, 5 days a week, they become salt in the wound called Xcode. This wound is not life threatening, but it sure is chronic with no healing in sight. I long for the day that I can sit here for a full day without hearing the words, "Why does Xcode suck so bad?".

cheers, will

comments posted at 11:38 AM

Comments:

Reply by cflake : 3:24 PM

And the bug numbers for these are... where? :)

Reply by Will : 10:42 PM

cflake - The problem is most of these bugs don't repro all the time so they are hard to log. That said, I have logged the framework hang bug, but alas, I don't have the bug number handy. :)

You use Xcode all day, don't you see some of these issues? I believe you have an ADC account as well. ;-)

Thanks for keeping me honest tho.

Reply by Tim : 11:00 AM

I can confirm the slowness loading large projects. I created a project containing the entire NetBSD source tree as a folder reference, and it takes a good several minutes to open on my G5 Quad. CPU utilization is not the issue; it's mostly disk I/O and it consumes nearly all of my 2GB of memory during startup, before settling out around 1.22GB VM / 753MB Real Mem. Apparently Xcode traverses the entire directory tree when the project is opened. The UI is locked the entire time, so it must do all this work on the UI thread. That said, once the project is loaded the performance is not bad (until you need to do a SCM refresh (svn)).

Maybe I'm doing something wrong, but one problem that's really bugging me in the context of this project is that changes made to the filesystem (e.g. files added, SCM status changed) outside of Xcode are generally not correctly reflected in the UI until the project is closed and re-opened. If nothing else, it would be nice if there were some sort of 'Refresh' menu item that worked with individual folder references.

Bug ID# 4747423

Reply by Sonic : 12:34 PM

well i've met some of those xcode bugs too, the Fix and Continue is actually like a candy - it's there but you cant have it! it allmost never works for me - only in the case i comment one line out, man

If i also sometimes get the old file build when i press build before i press to save like less than .4 seconds! now i dont save and wait for it to ask me and they, yes please save it!

so i would be happy to report em, but it's not so easy as in comparison for DVD player (for tiger), where you go to the menu and click report bug! apple is taking it too easy with xcode, i give up if i cannot find bug report within three clicks

Reply by Sonic : 1:04 PM

BTW you can report bugs over here:
http://developer.apple.com/bugreporter/
(click on Apple Bug Reporter)

make sure to read the best practises doc, its midly intersting for a developer i guess too
http://developer.apple.com/bugreporter/bugbestpractices.html