Y NO COCOA

The way I see it, appCode is only cross-platform in the sense, that is is written in Java. The cross-platform adventure ends here, as far as I can tell. appCode depends on Xcode for editing .xib and .plist files (also I haven't found a place in appCode to modify targets). So you really won't get anywhere with appCode on any other platform than OSX. So yeah, from that perspective it would make sense to make it using the native language and frameworks of the OS and not Java.

My best bet is, that the justification for doing this in Java is, that there has been an enormous amount of code reuse from IntelliJ - in other words, appCode would have taken a lot longer to develop and be a lot more expensive, if every line of code had to be rewritten in Objective-C/Cocoa. ...and this would also leave JetBrains with two very similar codebases (one in Java and one in Obj-C) to maintain -> again, more expensive...

As a long time IntelliJ addict, I don't have any problems with the look and feel of appCode - I felt more estranged to Xcode, when I started using that a few years ago - that was (and is) a tool that defies common sense and every standard way of doing things in every other OSX application.

Sune is right: appCode is based on an IntelliJ Platform (which is also the base for other our products like PyCharm, RubyMine, or PhpStorm, or even MPS), which has a lot of language features available out of the box if you have a proper infrastructure build for you language (like lexer/parser and some other internal things like PSI, etc). So you will have, for example, Rename Refactoring working with no extra coding (in ideal case) or Find Usages or Version Control integration, etc. InteliJ Platform is very smart and optimized for building IDEs with little extra effort so that's why we do appCode in Java: because platform it's based on is writted in Java.

Yes, native Cocoa applications are look great under Mac OS, but it is so cool to get a feature available everywhere with just a one single implementation, it is also easy to maintain it. Not always (we have a lot of different OS specific code too, especially for UI), but quiet often.

We also working on UI every day, and I hope our users notices these changes with every new IntelliJ IDEA release :)

So, that's it.

Gleb,

We pretty much control how everything looks and feels, despite of using Java. So if one points to actual behaviour that is unnatural to Mac app, we're happy to spend reasonable time polishing that out.

So please just tell what you don't like in the product and let us choose the tools and languages we use to deliver it.

Sure. For an IDE like this appearance is not a matter or critical importance. Also, if your other tools are any indication (and after trying appCode for an hour I see that they are), I'm totally willing to ignore the UI issues for the power and intelligence of the IDE. So, keep up the good work.

BTW, are you using native controls, or are you drawing them? If you are drawing them, Lion will require rework of that code…

Actually in this case the IDE appearance is quite important.

I expect that JetBrains wants to market this not just to IDEA customers who also happen to do some Mac/iOS coding, but also to pure Mac/iOS developers who have never used IDEA.
That means that if the reviews come out and they say that it's not a Mac-like application, a lot of potential customers will turn away immediately regardless of the other features. I know I myself would be quite hesitant to invest even serious evaluation time in a non-mac-like IDE if I hadn't been using IDEA since version 3.5.

That said, I have seen quite an improvement in the Mac UI for IDEA recently, which actually is probably due to the development of appCode.
So I see this as an opportunity to improve the Mac UI for both appCode and IDEA (since I expect most of the improvements will make it back to the shared platform).

I plan to submit tickets for any point where I feel appCode can improve the Mac-native feel, at least once youtrack allows me to submit appCode issues.

I agree, that the appearance of the IDE is indeed important - the debatable question is whether IntelliJ will be compared to "standard" OSX applications (iTunes, Mail, Pages or whatever sort of "defines" the OSX standard experience) or to other development tools on the platform (which at the moment - when we're talking iOS development is pretty much limited to Xcode).

I hope that it will indeed be compared to Xcode which - in my opinion - is not using the common OSX appearance, but seems to invent it's own way of doing things. Yes, Xcode 4 is a vast improvement over the 3.X series and does have some of the same visual components that iTunes use, but I have yet to meet an iOS developer who loves Xcode or even likes it. So far it has been a tool that was forced upon you, if you wanted to develop iOS apps - like it or not. It's a funny thing, because it's my general observation that Apple is quite good at making desktop applications, that not only looks nice, but are also nice to use, and somehow Xcode has always failed miserably in these categories. Again - yes - Xcode 4 is a vast improvement in both categories (except fo the fact that Apple decided to change a lot of the keyboard shortcuts), but Xcode4 is still nowhere *near* being a deveopler's best friend when it comes to writing code, assisting, warning, suggesting corrections and refactoring - appCode is on it's way to obtain this position and I hope deveoplers will recognize this and embrace it - even though it may not look as native as they're used to...

Gleb,

First:
"If it ain't broke, done fix it"?  Why on earth would you write an IDE from scratch when you already have a perfectly good one (in fact, an amazingly excellent one) already at your disposal?

Second:
I've been using Mac OS X since the very beginning, the idea of what is "Mac Native" has evolved substantially since then, and will take a drastic turn in Lion.  Apple isn't even capable of adhering to their human interface guidelines, particularly when those guidelines get in the way of innovation.

Personally, I don't care what appCode looks like, as long as it does the job that XCode isn't doing.. and even though XCode4 is a major turning point in that IDE's evolution, many of the UI choices they've made, choices that you might consider to be 'Mac Native' completely break the original look and feel previous Mac Applications.  For example, why can't I turn off the toolbar text to free up screen real estate?  Another example: Where the hell is everything?  It's nearly impossible to find things now because the UI evolved so dramatically between versions that it bears almost no resemblance to the previous one.

With the IDEA platform, you get consistency going back many, MANY years.  I know where everything is, I know how to configure it, and now I can do it with Objective C.  Does it matter then whether or not it has an Aqua (OLD SCHOOL MAC) or Brushed Metal look and feel?

I don't believe so.

Thom

I agree that the look of the application that I personally spend most of the day in, either if it is IntelliJ, RubyMine and now appCode, is important. If the Mac OS is a plattform Jetbrains want to invest in, they should definitely try to make theirs IDE's as Mac-like as possible, especially appCode.