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...
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.
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.
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.
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.
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.
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).
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.
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.
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.
The brain has an automation feature called "practice". It's easy to access: just repeat good forms until they become permanent. Once they have, your brain power is freed up to do other things. Jazz musicians use this a lot. There's nothing that would prevent one from applying it to IDE idiosyncracies.
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?
I reached a good compromise with Xcode and its dreaded windows management using 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.
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
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.
And - while we're kvetching - Office 2008 takes just as long to start up as Office 2004 on my Intel Mac... even though the '04 version is PowerPC-only, and is therefore running under Rosetta emulation.
Yes, that's right. The '08 version manages to be slower than emulating the previous version.
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.
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.
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.
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...
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.