Xcode vs. AppCode

<< Prev: The Other Shoe Drops       Next: Compiler Directives >>

Xcode: just plain awful, or actually unusable?

All right, they moved my cheese again. Maybe I'm just not used to it. I'm definitely not used to it.

Some of the things I don't like:

• Right-clicking to navigate from a name (struct, function, variable, etc.) to where it's defined (using the mouse as opposed to a keystroke)
• An editor area with only one file at a time (as opposed to tabs), forcing me to navigate a large project with the whole project view instead of quick-switching between a subset of files.
• The alternative of opening a jillion separate source windows, again with no convenient way to switch to just the one I want
• The project settings, which is sort of inexplicable and has a monstrous number of options with no description or help
• The lack of an obvious place to map all project files to source/resources/syntax highlight but don't include in output, etc.
• The inexplicable use of includes and frameworks. You can #include seemingly anything you like. You can also add frameworks to the project, though it's not clear what that does. It doesn't seem to alter which includes work, and it doesn't seem to put the frameworks into the list of required frameworks in the Info.plist
• The way the plist editor defaults to an unusable tree view (where among other problems, it takes between one and three clicks on a control to activate the control), and the plain text view is hard to find
• Lack of an easy way to rename files
• Odd Git integration, where files you add and edit are sometimes added and sometimes left untracked
• Strange separation of source code directories and project "groups"
• Completely inconsistent build results where a project with a trillion errors can emit just one output error, and the if you fix that you get a different one, and then if you fix that you get 60 errors and a message that you've reached the error limit, but then if you fix one of those you get 35 errors and a message that you've still reached the error limit, and etc.

I could probably go on. Every time I use it, it seems like something comes up. And I spend my time hunting around or Googling or endlessly clicking and scrolling instead of doing something useful. I don't mean to just bash the product, but I don't feel productive with it.

On a side note, I once didn't feel productive with IntelliJ either. But when you start IntelliJ, it offers an endless list of tips that ease you over the learning curve. Keyboard shortcuts. Functions otherwise hidden in menus you might not think to look at. Features that make you more productive. Sometimes I just dismiss that dialog without looking, but at least a couple times I've sat there and clicked through it for a while, and I've been rewarded. Where's the "100 ways to be more productive in Xcode" in Xcode?

So then I thought to look over at the JetBrains Web site. I know they've branched out into IDEs for other languages besides Java. Could there be one for C and C++?

There could! Actually, there could be two, which was a bit of a problem because which do you pick? Choosing the more OS X-oriented one, I went with AppCode. When I fired it up and went to create a new project it offered an option to build an IOKit kext, just same as Xcode. That made me think I probably picked the right one.

Well, that might be true, except I quickly found there are two near-crippling bugs in AppCode 3.3 and 3.4 EAP (as of this writing).

1. If you #include IOKit features such as IOKit/IOLib.h or IOKit/pci/IOPCIDevice.h, AppCode doesn't recognize them. They're shown in red, and code highlighting also shows anything that came from them in red. This has a huge trickle-down effect, as basic data types such as u32 aren't found, and a lot of errors crop up like "incompatible assignment UInt32 to int". It means in a typical source file, there are hundreds of lines highlighted as errors, and the right gutter in the editor window is nearly solid red. Among other things, this makes the scroll knob nearly invisible, depending on the editor color scheme.
2. When I do a build, I often get on the order of 2 errors and 500 warnings. Unfortunately, the build messages window shows the chain of includes for every file that has a warning or error, often several times. The bottom line is, the build output window has (in the test build I just did) 1665 lines of output, including 2 errors. It shows perhaps 15-20 lines at a time. It normally does not jump right to the error. Using the "don't show warnings" control reduces that to only 908 lines. Somewhere in those 908 lines, of which we'll be generous and say you can see 20, is your error. It might take longer to scroll around and FIND the error than to actually fix it!

The first problem I assume they'll just fix someday.

The second, I'm not so sure. In this one area, it made me really appreciate Xcode, which after a build lists every file with a warning or error exactly once, with a red symbol next to the ones with errors. It's completely obvious where the errors are.

So I'm left with a tough choice.

But at the end of the day, I find that while both IDEs bother me, AppCode bothers me less. Maybe I should go to the trouble of identifying the context-menu option in Xcode to navigate to the definition of a name, and assign a keyboard shortcut to it. Then if I could get Find in Xcode to navigate results as easily as Incremental Search in AppCode, I might stick with Xcode until they fix the syntax highlighting problem in AppCode.

Or, I suppose, I could try to use emacs for more than just text editing. I hear some people use it for code, too.   :)

<< Prev: The Other Shoe Drops       Next: Compiler Directives >>