

Is anyone actually using Xcode? - geeko
http://warpspire.com/tipsresources/programming/do-people-really-like-the-window-management-in-xcode/

======
demallien
I always suspect that part of the problem is that people come to xcode from
other environments, expecting to use the same workflows that they previously
had, and it just doesn't work. Personally, I don't think it would be a bad
thing if Apple made a bit more effort to reach out to programmers coming from
other environments, but honestly, I suspect that they figure that any
programmer not capable of dealing with this is probably not a great loss for
the Apple ecosystem.

It is a point worth remembering that all of Apple's own software is built in
xcode. That all by itself shows that the app isn't fundamentally broken, even
if one may feel like there is room for improvement.

On a sightly different note, I'm always fascinated by this type of rant, of a
programmer complaining about their programming tools. I mean, you're a
_programmer_ , if you don't like the tools, roll your own that are better. Or
write some scripts that ease the pain in the tool, or adapt a 3rd party tool
to do the task. For example, this guy could quite easily prepare an iPhone dev
plug-in for Textmate, if xcode really is as bad as he says. Here's an example:
[http://www.pathf.com/blogs/2008/11/iphone-sdk-testing-
with-t...](http://www.pathf.com/blogs/2008/11/iphone-sdk-testing-with-
textmate-gtm/)

Complaining about dev tools for me sends up a whopping great big red flag that
the programmer isn't as good as they think they are.

~~~
kneath
[Author of the article here]

That's an interesting viewpoint, but if I may offer some counter points:

By nature, I am a designer. Most of what I do day-to-day involves sculpting
the user experience. I know that as much as we want to say that "we have X
experience and this is the best way" often times brand new users offer the
best insight _because_ they are unfamiliar with your design. A person who has
been using XCode for years now has probably grown to ignore the rough spots.
Much like you can learn to ignore a train's noise if you live by the tracks.
New user's feedback is usually the most valuable feedback you can get.

Additionally, I am a huge open source advocate and would gladly help hack and
improve upon XCode. Sadly it's not open source. It seems silly to propose that
I rebuild, by myself, the 95% of XCode that is awesome in order to improve
upon the 5% that needs work. Complaining about a highly extensible open source
editor like emacs is indeed just complaining -- just fork the project and
implement your code. But choosing to persuade those with power (Apple) to
improve upon a product with hundreds of thousands of man-hours already
invested instead of rewriting the whole thing myself... well, I'd call that
smart programming.

I'd also like to point out in the conclusion paragraph, I mention that I _am_
using TextMate for the time being.

~~~
demallien
I would have found your article far more interesting if instead of ranting,
you had undertaken an in-depth analysis of what your workflow actually is, why
the current xcode doesn't meet your needs, an explanation of why your workflow
can't change to fit in better with xcode, etc.

Even better would have been an article where, having analysed the problem, you
have come up with a solution. For example, you seem to want a better mechanism
for switching between source files in a project. How about a script for xcode
that opens up a little search box where you can type in a file name from your
current project - it auto-completes the name, and then opens the file? Way
faster than clicking on a tab. It'd basically be a copy of the way Spotlight
can be used to launch applications - Command-Space, type the first few letters
of an app, and hit enter. Done in less time than it takes to reach for the
mouse. As a bonus, it doesn't waste screen real-estate on tabs, and can be
used to switch even to files that you haven't opened yet.

This is the point I was trying to get at in my first post. You're a programmer
- this type of script is almost certainly well within your capacities. You
could probably generate it in the time that it took to write your article.

~~~
kneath
demallien, I actually did offer a better solution: Xcode needs to implement
tabs. As for your script idea, Xcode actually implements this via the "Open
Quickly" command, but this doesn't solve any of the issues I outlined in my
article.

There is a difference between open ecosystems that you can change at will
(emacs, vim) and closed ecosystems that you can only change so far as the
manufacturer lets you (Textmate, Xcode). To propose I "just write a script" is
really to ignore my entire post and it's detailed explanation of why different
window management systems work in different climates.

------
allenbrunson
I've used Xcode for years now. (You're not capitalizing the name the way Apple
wants you to, by the way.) I actually kind of like it. It crashes more often
than I'd like, especially when using the organizer window for iPhones, but you
can't have everything.

------
hboon
I drag the divider in the project window to just show the groups and files
(tree) section and no code. Double clicking in the tree opens new editor
windows. I move the project window to a secondary monitor, open two primary
editor windows side by side in the primary monitor. From that point onwards, I
can either double click on the tree or use the open quickly shortcut, cmd+dbl
click on method/classes to open new editor windows. Seems pretty alright to
me. I used to have 10+ windows when using Dolphin and it seemed ok too, maybe
it's just me.

> Windows mean different things. Some mean code documents, some mean visual
> aid, some mean a kind of “project” that groups all things.

I end up with only the project window (only the navigation tree and it's a
slim and tall window), editor windows (the only windows with code, half a
screen width, usually full screen height) and the occasional Xcode
documentation window.

> The project window continually morphs it’s state as you enter and exit
> debugging. It’s appearance is different, not upon your application’s state,
> but rather the toolbar button in the upper left, that automatically changes
> (one-way).

I hardly use the project window since there is the open quickly shortcut. I do
use it to open when there is less than 2 editor windows open (Xcode oddity, it
will open the code in the project window in this case, and because I only show
the tree, it looks like nothing happened. Took me a while to figure that out).

When I run the app in debug mode and hit a breakpoint, I just use the shortcut
buttons on the top of any editor window to pop up the debugger, not touching
the project window.

> All the code looks the same. There is no unique identifier in Exposé mode. I
> must selectively hover over each file and read it’s filename. Or, I can
> exposé to try and find the project window (which can look much like a code
> window too), and then open a new document.

The code windows are not labelled in Exposé, but does hovering over them break
the flow for you? Or is it because all the windows, including the project
window look the same to you?

> If I accidentally Cmd-W the Project window, I have to start from scratch,
> opening the whole project and each document again. This often happens as you
> accidentally open windows and want to immediately close them.

That's strange. If I close the project window, all I have to do is open it
again and all the editor windows open up as they were previously

------
dchest
My setup looks like this:
<http://www.flickr.com/photos/chestnykh/3525052710/sizes/o/>

There's a project window with code editor on the left, console on the right,
and documentation on another space. I rarely use more than one editor window.

Frequently used shortcuts for navigation:

    
    
      Cmd+Opt+Up — toggle between .h/.m,
      Cmd+Opt+Left/Right — go to previous/next opened file,
      ^2 — quickly jump to methods,
      Cmd+0 — navigate the project tree.
    

I rarely use Debugger (which is a separate window in my setup) as I prefer
logging to console for debugging.

Finally, Xcode has different layouts: Default, All-In-One, and Condensed (see
General Preferences, I use Default).

My wish: move Documentation to an external app (sometimes I press Cmd+Tab
instead of Cmd+` to switch to Xcode from Documentation).

------
jjs
Xcode is much more manageable when you're using Spaces, and set up one desktop
exclusively for Xcode, and an adjacent one for Interface Builder.

~~~
gecko
I agree with you, but let's admit that what we're saying is that Xcode window
management does, indeed, stink--so badly, in fact, that the only sane way to
use it is by itself, in isolation, with no other app on the same desktop. I
don't know any other application that I give its own space, but I sure do that
for Xcode, just as I did for Project Builder before it. I had hoped that Apple
would fix this problem for 10.6, but with the API freeze today, and no
improvements to Xcode, I'm not raising my hopes.

------
GeneralMaximus
Even I felt Xcode's window management was out of place when I started using
it. Learning some keyboard shortcuts eased the pain.

Here are some links: [http://cocoasamurai.blogspot.com/2008/02/complete-xcode-
keyb...](http://cocoasamurai.blogspot.com/2008/02/complete-xcode-keyboard-
shortcut-list.html)

[http://groups.google.com/group/des-moines-
cocoaheads/browse_...](http://groups.google.com/group/des-moines-
cocoaheads/browse_thread/thread/db4d6497a40ddd07#)

Additionally, you can script Xcode using several scripting languages. You can
also write plugins for Xcode using AppleScript.

------
unwind
The title of this post really doesn't match the title of the linked-to
article, which is confusing.

------
markessien
Learn to use your tools, don't expect the tools to adapt to you. I can switch
easily between Eclipse, Visual Studio and XCode because I don't customize
them. I accept them as they are, and after a while your mind switches the
context with the tool and you can be as productive as you want without forcing
paradigms from one environment to the other.

~~~
geeko
Switching context requires brainpower, which I'd rather use to make my code
better.

~~~
markessien
If you do it long enough, you can do it automatically. It's like switching
between using an electric hammer vs a manual hammer - once you understand the
difference you associate the tool with the behavior. Brainpower is not
required.

------
geeko
I'm doing the stanford lectures on iphone development these days and XCode
seems to be the IDE of choice. Mildly put, XCode feels rather unfinished. Is
anyone here having a better/less painful alternative and managed to build real
world apps for the iphone without using apple's IDE?

------
gtufano
I reached a good compromise with Xcode and its dreaded windows management
using Witch <[http://manytricks.com/witch/>](http://manytricks.com/witch/>).
At least now I can have cycling through the XCode windows with a list, better
than, as the author says, try to understand in Exposé where is the code I'm
looking for. Worth a try, almost solved the problem for me.

~~~
stafftool
yeah, witch helped a lot whenever I've used Xcode.

------
weaksauce
single window mode and a bunch of keyboard shortcuts make it bearable though.
mapping command-1 to project and command-2 to debug makes it work well.

~~~
tolmasky
single window mode is a must with xcode if you ask me

------
spitfire
I'm using XCode. I rather like it, it's not as "enterprise ready" as eclipse.
Which is a very good thing in my mind. Less bureaucracy/ceremony. But not as
freeform/DIY as emacs.

For cocoa/iphone work it's lovely, I wouldn't try to build a web app in it
though. It's just the right tool for certain jobs.

------
cliff
Office Mac is developed and compiled solely on XCode.

~~~
immad
Office Mac is really bad compared to real Office. Maybe this is why :)

~~~
rbanffy
No. It's because Microsoft wants you to run Windows.

Office for Mac is just a way for Microsoft to prevent Mac users from using
formats incompatible with Office for Windows and creating pressure on
Microsoft's format monopoly. It has to be usable, but must never feel better
than the Windows version.

~~~
halo
Same reason as iTunes for Windows and the iPod monopoly then.

On the other hand, Office for Mac likely has <5% marketshare at most, so
Microsoft could legitimately justify less development resources as making
financial sense, similar to how Mozilla and Google treat Windows as the
primary platform for Firefox and Chrome respectively. On the other hand, I
wouldn't be surprised if the marketshare for iTunes on Windows exceeds that of
iTunes users on Mac OS X, so there's really no excuse for that particular
half-arsed port.

------
cubicle67
You've probably seen this before, but here it is again.
[http://cocoasamurai.blogspot.com/2008/02/complete-xcode-
keyb...](http://cocoasamurai.blogspot.com/2008/02/complete-xcode-keyboard-
shortcut-list.html)

I find it invaluable

------
e4m
Can anyone link statically in XCode? Why did Apple break static linking in ld?

~~~
dchest
Sure. Just get rid of .dylib (dynamic library) and use .a (static library).
The difficult part is that Xcode will automatically use the first found .dylib
in PATH instead of .a, so to workaround you should put .a in PATH before
.dylib, or just rename .a to something else (libcrypto.a -> libcrypto-my.a)
and link with renamed library.

------
travisjeffery
Just about every Mac/iPhone developer I know does. You get used to it.

------
TweedHeads
All-in-one layout

[http://meandmarkpublishing.blogspot.com/2007/06/reducing-
xco...](http://meandmarkpublishing.blogspot.com/2007/06/reducing-xcodes-
window-clutter.html)

