AppCode UI Overview

Thanks a lot review. There are some issues we haven't thought of indeed. Some are easy hangers while other might be prohibitively hard to fix. We'll try nonetheless.

Yeah, I've done some Java GUI dev myself in the past, so I know what it can be like to do some things. Ultimately it depends on how much you want to share code between your various apps vs how much you want to go Mac native. There is an open source Java wrapper for Cocoa called rococoa, that is used by the likes of the Cyberduck FTP client, that may or may not be useful for some things.

Would you please comment on why you like Xcode's code completion more than AppCode's?

Sure. It's lots of litte things really. The 3 main ones that come to mind are:

1. Code completion for method signatures in .m files. As I start typing a method signature Xcode offers completions. It filters these completions, ignoring any where the return type doesn't match that already entered and ignoring any already implemented methods.

2. Smarter code completion for @synthesize statements. If you type @synthesize then bring up code completion, Xcode only shows property names. AppCode also shows some other stuff (granted it's a lot better than Xcode 3). It also only shows the property names of properties that haven't yet been synthesised.

For example, say I have 2 properties: name and age. If I do @synthesize then bring up the completion, both Xcode and AppCode suggest name and age as completions. I select name, type a comma and then bring up completion again. Xcode only suggests age, whereas AppCode still suggests name.

3. Smarter code completion for return types. Say I have the following method:

- (id)testMethod {
     id testObject;
     BOOL testBool;
     return ;
}

If I start typing test for the return value, AppCode will suggest the testBool variable, as it is first alphabetically. Xcode however will suggest testObject, as it matches the return type.


Of course AppCode has benefits in terms of fixing things (such as importing headers for you) but on a lot of the tiny things Xcode is a lot smarter, though it does use Clang for its code completion/indexing.

Hi Martin,

awesome evaluation of the Mac-ness of AppCode. As a long time IntelliJ user (mostly on Windows), I haven't thought of many of the things that you mention, but you're spot on. I asked one of my friends to try out AppCode (he's a game developer, primarily uses Visual Studio and some Xcode), and he has very high expectations when it comes to the look and feel of Mac apps - he wouldn't touch AppCode with a stick as it is right now. Hard for me to understand, as I value the productivity factor over look and feel, and nothing comes close to AppCode in this respect. But when I read your evaluation, I kinda see what he's talking about. Also, over the 3 years that I have used a Mac as my primary PC, I have certainly noticed that *all* programs generally looks way better on Mac than on Windows (both paid and free software). I don't know whether this is because Mac developers put a lot more effort into the look and feel or if it's just because the Cocoa framework automatically makes applications look pretty.

A few comments on code completion:
- I really hadn't noticed the property/synthesize problem - I usually just declare my member variable or property and then hit Alt+Enter to automatically create the other as well as synthesize and deallocation statements. now *that's* productivity. I have never understood *why* it has to be such a pain in the *ss to add a variable/property to a class in Xcode. I know that now you can skip some of the steps (eg. declaring the actual member variable for a property) and then Xcode figures that out on compile time - I am not a fan of this approach, because you end up with some "invisible" source code - I prefer the explicitness, which is now *so* easy to accomplish in AppCode.
- I like the camelHump completion tht AppCode does - however when I need an NSString, and I start typing NSSt, the first suggestion is NSSymbolStringEncoding - has this been fixed in today's build?
- when I type something and AppCode feels the urge to help me code complete, I get a dropdown, where the first element is selected. When I press Enter, that element is inserted. This seems to apply everywhere except when declaring properties - or to be more specific when I declare the characteristics of a property (ie. nonatomic, retain, readonly, etc.) - the dropdown is shown, but no element is chosen, so hitting Enter just puts the cursor on the next line. If I use Tab to complete, it works fine though. Also if I press Ctrl+Space then the first element is highlighted and Enter works properly...

"Hard for me to understand, as I value the productivity factor over look and feel, and nothing comes close to AppCode in this respect. But when I read your evaluation, I kinda see what he's talking about."

Well, this is sort of the problem that many developers have if they aren't well versed in UI design. They can underestimate just how much the look and feel of a product has an effect on productivity. The aesthetics can help make something nicer to look at, if something is nicer to look at you like using it more than something ugly to look at. Then you have the feel. If things work as you expect then its less learning.

"I don't know whether this is because Mac developers put a lot more effort into the look and feel or if it's just because the Cocoa framework automatically makes applications look pretty."

A bit of both. Mac developers do generally put more effort into it, but Cocoa also helps as well. The default controls do a lot of stuff for you, and generally you only extend them to change appearance. But there's also the thing that Mac developers are more likely to say no, than to say yes. They look for ways to have fewer controls on screen, and to do progressive disclosure. Can you potentially take something that is spread over several parts of the UI and put it in once place. Can you layout things in a much clearer way.

A great example of this is changing fonts and colours. AppCode displays a plain list of syntax elements and then next to it are controls for foreground, background, effects etc. And then you have a large preview area below. Xcode on the other hand combines the preview with the list of syntax elements, and you edit them using a few controls below. So for example, instead of laying out the colours preferences like so:

http://dropbox.mcubedsw.com/skitchpics/AppCode%20Fonts.png

I would instead maybe lay them out this way:

http://dropbox.mcubedsw.com/skitchpics/Improved%20Fonts%20Example.png

So you'd have your schemes listed down the left, your preview and your syntax items combined and the options to change put into a more compact space. It offers exactly the same functionality but has fewer controls (11 vs 16), looks a lot nicer and also feels more like a Mac app.

Re 1 & 2. It's likely just different ways of working. The actions are very powerful and I like them, but I don't think they should necessarily be at the expense of the code completion, as when the actions fail (such as with protocols) ideally you want something to fall back on to.

As for 3, I did find it quite odd that you have several code completion "modes". I would have thought everyone would have wanted the smartest code completion possible all the time, including as they type.

Regarding your questions:

"- do we need to "advertise" our features to the people who might have never used them?"

Yes. Even if it's just a page like this: http://developer.apple.com/technologies/tools/whats-new.html . At the moment your 10 facts don't say too much about why I should use it over Xcode. Reading through them I would probably think the following:

1-6: Xcode has all of this
7: Xcode has refactoring (note that people may thing "change signature" is just a simple rename, like Xcode supports)
8. Xcode does on the fly analysis and offers to fix things
9. Xcode supports svn & git
10. Xcode has fast & intelligent code completion as well

You obviously need to mention them as they're key points, but they just make it seem no better than Xcode. The things I'd want you to tell me about are:

- Using actions to fill my implementation based on my header (or vice versa)
- Offers to import the header when you use a new class
- Allows you to find all usages of a method (I actually found a bug in my own app while testing where I was calling the wrong method ;) )
- Powerful code styling support
- Real tabs
- Extensible

Those are all things that AppCode has that Xcode does and even though some may seem minor, they are key things that will get people to look at it over Xcode.


"- are these features too confusing/complicated?"

That sort of depends. The biggest hurdle coming from Xcode is finding out where everything is and what does what. It would help a lot to have a transition guide/video that helps introduce people to AppCode, from the context of already using Xcode.


"- are they less functional comparing to Xcode features?"

Again, it depends. In fact this is sort of linked to the last question. AppCode doesn't have anything major over Xcode (well you can sort of count refactoring as Xcode 4's refactoring is so unreliable it might as well not exist), but it does have lots of smaller features that are fantastic and can really make the difference. The big problem is that Xcode wipes the floor with AppCode in terms of usability.

I often say that I prefer to use something that does one thing incredibly well, rather than something that does 10 things poorly. Or put another way, in a feature comparison chart AppCode would likely beat Xcode. But due to the complexity of the UI in may places (especially the preferences), many of those features might as well not exist. It's the same reason the iPod beat all the other media players, despite having fewer features.

I'll keep coming back to the changing syntax colours example, as it really tainted my initial encounter of AppCode. I wanted to change the colour scheme to what I usually use and to see whether it was more of less capable than Xcode. It took me several minutes to find what I wanted, as I went looking through various sections to find it. Compared to pretty much every Mac-native IDE/editor where it usually takes a few seconds as you open preferences and look for a colour wheel icon. Now you may say that I should probably have used the search field, but honestly that's something I missed. If a person is used to a certain way of working with something, they often blank out things they don't expect to see. The only search bar I've seen in a preferences window anywhere else on the Mac is in System Preferences, so it's not something one expects to come across in a Mac app's preferences


"- do we need to support all features exactly as in Xcode, because people are used to Xcode?"

That depends entirely on the feature and on the person. Something like refactoring can work differently just fine. I'd be a bit wary about the build system, as that will likely be a key issue. You'd want to have the same concepts of projects, containing targets, containing build phases. Xcode 4 also really nailed the UI for these. Schemes are sort of part of that, and I think they're incredibly useful, but you could get away without needing them if you can handle their job in a much better way.

Code completion though might be an issue. In AppCode you type, hit Tab or Enter and it completes. However, in Xcode you type and then Tab or Enter do different things. I might type "[NSString stringWi" and it might suggest stringWithFormat: followed by stringWithContentsOfFile:encoding:error: etc. If I hit Enter it works just like AppCode, completing the full selected method. However, if I hit Tab it completes as much as it can until it his ambiguity, so in this case it would complete to "[NSString stringWith". If i then type a C and hit tab it will complete to "[NSString stringWithContentsOf" because there are stringWithContentsOfFile and stringWithContentsOfURL methods. Now if existing Jetbrains app users are used to the tab, then this might be one of the cases you have to add a setting. Of course this may be possible already and I might have missed it.

Ultimately the answer to this question is: can you do it better? If you can't do it any better than Xcode, do it the same way as Xcode. If you can do it better, then go for it.

Thank you again for the detailed review, we'll try to address the issues you described to improve the usability of AppCode.

I would like to put in my two cents.

I have been developing on the Mac since the MPW days.  I have used pretty much every IDE on the Mac for different development needs (MPW, Code Warrior, XCode, JBuilder, Eclipse, and finally IDEA).  

I have to say I was completely shocked and very happy when I discovered AppCode.  I have been an extremely happy IDEA user for Java development since 2002.  While others might not agree, I think it is by far the best IDE.

The times I had to use XCode 3, I found myself wishing for the coding tools that IDEA gave you.  The degree of refactoring you can do with IDEA was amazing.

While XCode 4 is a huge step forward in my mind, I still think that IDEA has a better coding tool set.  Having used IDEA extensively, I feel completely comfortable with AppCodes UI.  Its a Java program and its UI is what it is for now.

Having said that, I can understand XCode programmers that have never used IDEA will find AppCode (I am making the assumption that AppCode relies heavily on the code base of IDEA) somewhat un Mac like.  I would urge patience to these people and give this product a chance.  I think AppCode has tremendous potential, and I would expect that future versions of Java for the Mac will just offer more in the way of native UI widgets.  

I know some engineers at Apple and they were surprised and happy to learn about AppCode.  The ability to extend it with plugins is something XCode 4 cannot match.

AppCode looks great to me and think it has a great future.

I only hope that the next version of IDEA Ultimate has an AppCode plugin.  Lots of iOS applications use technologies like Web Services, and if you are implementing both sides of such a beast, I could see that IDEA+AppCode Ultimate would be fantastic.

If you do any server side Java development, you should give IDEA Ultimate a look see.

-Tom Condon

Thanks to Martin for doing his UI overview. I agree mostly with him in his assessment.

I must disclose I haven't used Xcode 4 for reals, because the old versions were so buggy. But LLVM and Clang combined with Xcode is what I've been waiting for the last five years. Then comes AppCode with the apparent advantages of having the actual benefits of a real parser merged in the IDE and years worth of inspections, automagic corrections etc. built in.

I'd say AppCode beats Xcode hands down in the code completion, inspections, as-you-type-suggestions etc. departments. But I must say, Xcode is a native Mac app, and that helps a lot. Of course some of it can be helped with just using AppCode and getting used to it. But I'd like AppCode try to be more Mac-like, for example in the ways Martin explained. Also AppCode feels a little laggy and not super snappy. Is that Java being slow, on my Mac Pro? I don't know.

I'm generalizing here, but we Mac users like good design. That's why we use Macs and iPhones instead of Windows and Android. Underrating this desire towards good design can be a mistake. I do understand that good design and great UIs takes a lot of time and hard work. I know that because doing those great apps is what I do for a living :)

However, I must say the AppCode team has done a wonderful job and I wish them all the best! I will be evaluating AppCode and slowly learning to get fluent in it. I'm sure I can code faster in AppCode than in Xcode, once I can memorize all the commands and learn the AppCode way of doing things.

I'd like to mention that while the points above are all valid areas to look for improvements, IDEA/AppCode is one of the best Java apps on the Mac.

I've had the (mis)fortune of using more than a few Java apps on the Mac, and IDEA has always been one of the better behaved ones, and over the last 2 major version has really seen quite a bit of improvement in this area already.

It is a fairly well behaved app for a Java app, but it still feels like a Java app, rather than a Mac app. Cyberduck (http://cyberduck.ch/) is a great example of an app written in Java that looks and behaves like a Mac app, granted it is using a Java Cocoa bridge.

A lot of the biggest issues are just basic UI design issues, rather than Mac specific issues. For example, I don't find the AppCode preferences hard and awkward to use because they don't follow Mac conventions, but because there's an awful lot going on and it's hard to find what you want.

Perhaps I am just a renegade... but I like the fact it doesn't feel like a 'Mac App'. As a Linux/Java developer who somehow fell into being an iOS Developer as my day-job, AppCode feels like an absolute breath of fresh air!

I second this. Xcode is a lousy experience because it is so mac like, in the "user friendly" sense.

Apple make two kinds of apps : professional and consumer.

Their consumer products are great, and have really clean, easy UIs, like iLife, and garageband, and iMovie..

god knows why, but Xcode mimics the consumer UI.

Apple make professional apps too : Logic pro and final cut... these do not have the friendly UI xcode uses, if anything, I think they have more in common with appcode's UI.

I wish xcode developers would get their heads out of their backsides and stop defending this stupid kids toy of an interface.

I prefer appcode's professional interface any day of the week. Please don't pander to the philistines and keep it a pro app... maybe one day apple will get their heads ouf their bottoms too and do the same :)

Thank you, George!

This is interesting because I work with a bunch of guys that share the general theme of your critique of AppCode. I essentially agree with all of the non-standard UI problems that you point out, but it turns out that zillions of great productivity features in AppCode make it so overwhelmingly better than Xcode that I am quite forgiving. It would be nice if AppCode looked more native and improved some of the rough spots, but none of those things have anything to do with why I use AppCode in the first place. In fact, I am not terribly fond of Xcode (hate significant parts of it in fact) and don't find it to be any more "usable" (mystery meat anyone?) than AppCode in the ways that I find important.

But I'm already a satisfied customer. Although your points don't resinate with me, I believe they are important for JetBrains in trying to attract more devs. I work with quite a few guys that just can't get over the things you've pointed out and I think this is important for JetBrains to think about. Even after all of the conversations I've had with my fellow devs about the fantastic stuff in AppCode, despite all the feature envy they have, they seem to be stuck on the same UI things as you describe.