At first I was excited that Xcode had some competition, so I downloaded this as soon as it was available.
Unfortunately, it has a crappy Java-generic GUI. For an IDE for a platform that makes a big deal out of user experience, it really looks awful. (And it manages to be slower than Xcode 4!)
I understand that tools don't have to be pretty to be functional, but I draw the line here.
Same deal with MonoDevelop. These alien GUIs look absolutely miserable in OS X alongside the system and all the tastefully done third party native apps you have running.
Unfortunately, outside of xcode, their is no other competition. No other IDE comes close. Considering this release is a pre-beta (and not some faux-beta popular with web two point oh startups these days). Having used other Jetbrains products, I'm fairly certain that when all is said and done, the final product will be solid IDE.
> Having used other Jetbrains products, I'm fairly certain that when all is said and done, the final product will be solid IDE.
It probably will be solid, but having used their other products on the Mac (RubyMine, IntelliJ), it's probably never going to get any less java-ugly or feel any more native.
And I think that's likely to be more of a problem for potential users of AppCode vs RubyMine or IntelliJ users on the Mac. Because its target market is either established Mac developers who care about the conventions and tastes prevalent in Mac software, and thus find AppCode ugly and alien in function, or users of other JetBrains products getting started with Mac development, for whom AppCode might feel familiar but will be a barrier to learning about the conventions and tastes prevalent in Mac software, leading them to produce sub-par experiences with the product.
Meh - it's not for those us who like everything in its place, fully native "oh my god it's so elegant" software.
It's for those of us who want something that does everything we want (plus some more) without being too hard on the system resources and has the ability to stay out of our way when we need it to.
It's true, Jetbrains products are not the most beautiful, and yes they're mostly written in java. However, they do make incredibly functional products with a slim learning curve with some amazing features. Jetbrains products (from Python to Ruby to PHP, and I'm sure their new AppCode) have consistently shown the best understanding of the code being developed which contributes to the best code sense and refactoring support I've ever seen in any IDE.
I have a few disagreements with what you have said here.
AppCode is in Beta - it's going to be slow and its going to crash. Even though you have stated that "tools don't have to be pretty to be functional" I think you have contradicted your point here by writing off AppCode on that basis entirely.
As a software developer, fair criticism of a tool should never rely on its aesthetics but rather on its ability to solve problems and solve them productivity. Eclipse, Emacs, Hudson, et al are tools I wouldn't say are aesthetically pleasing but they are very successful at solving the problems they were designed to solve. Thus I believe aesthetics should logically be placed secondary to utility.
I really did want to expand on the point you disagreed with, but I had to leave. Here's a bit more.
What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use. So far, reading and testing, I have not seen any reason to prefer appCode to Xcode. If appCode had some sort of killer feature, then I would put less emphasis on the way it looks.
In addition, this sort of interface displays a fundamental misunderstanding of OS X and iOS by Jetbrains. Integrating with an OS is about more than getting your code to run and do stuff. I am a user as much as any iPhone owner is a user.
What I meant was that given the choice between two tools, one of which is pleasant to use (for whatever reason) and one of which is not, I will always choose the one that is more pleasant to use.
This is the crux, for me. After years of becoming accustomed to the million and one tiny points of attention to detail about the development experience (as opposed to the user experience) that JetBrains are known for, this announcement is fantastic news. XCode is painful by comparison.
In the worst case scenario you should keep it around for refactoring. The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around.
> The support in Xcode is far behind the state-of-the-art, those features alone should pay to have this around.
Assuming AppCode's refactoring support ends up being even as good as Xcode 3's hit-or-miss heuristics, which remains to be seen.
"AppCode is from JetBrains and ReSharper/IntelliJ IDEA have great refactoring, so AppCode will too" isn't a valid line of reasoning, because the limiting factor here isn't the author of the tool, it's how much a priori reasoning you can actually do about the target language in question. C# and Java are both, by design, highly amenable to the kinds of static analysis that make refactoring support simple. Objective-C, by design, is not.
Xcode 3 and below did a lot of pattern matching to try to make a decent go of autocompletion and refactoring, and it fell down a lot of the time. With Xcode 4, Apple has turned the new compiler, LLVM, into a shared library and hooked into it for refactoring and autocompletion, so they're working with the same parse trees the compiler is, and they have as much information to reason with at compile time as can be hoped for in an extremely late binding, weakly typed language like Objective-C.
How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't.
In short, I'm extremely skeptical of the claim that AppCode is going to be leaps and bounds better at statically analyzing Objective-C than Xcode 4, given the constraints of the target language.
How is AppCode going to get any better than that? Either they're going to go the heuristics route, like Xcode 3 and below, and have all kinds of cases where they fail miserably, or they're going to hook into LLVM, and have no real insights into the code that Xcode 4 wouldn't.
You can have symbols available to you from the compile that you're not interested in using. How do you filter them out smartly? There is plenty of room for improvement, even with a LLVM-based parser for determining possible autocompletions.
Also, Xcode 4 has a tendency to forget it has to show me any completions at all. At that point, Xcode 3's autocompletion is preferable to, well, nothing.
I know what you're saying about AppCode's ability to understand the language, but after seeing first-hand the refactoring support of Jetbrains products for dynamic languages like Python, Ruby and especially my enormous PHP project - I don't think there's anything to worry about.
I know the GUI might not look nice due to being Java, but if AppCode will get as much polish and as many features as IDEA or the smaller language specific IDEs got, then AppCode is something to really look forward to.
Even after a year of constantly using PhpStorm (yeah - still no time to rewrite that huge app I'm maintaining) I'm still finding little things that show that the IDE was really made by developers.
It's just like with the iPhone: It's full of little nice touches.
Recently, I was pissed of enough about the typo in the name of an interface:
IModuleAmmendment
and I had PhpStorm rename refactor it.
Of course it worked (and instantly over 800 files), but it also fixed the typo in a class implementing the interface (CatalogModuleAmmendment was for example renamed to CatalogModuleAmendment).
And that's just a sample: The IDEs are full of these little things. This makes me so productive that I can easily live with the less-than-perfect looking UI.
This sounds like a commercial, but I'm really just a (incredibly) happy customer of theirs.
What I would pay for is not another IDE but one that handles all the code signing bullshit for me. It's crazy the amount of errors a team can have regarding code signing and push notification certificates.
I'm excited to see more additional development solutions for Objective C; but why are we taking a step backward with these awful Java like GUIs that have plagued Eclipse and NetBeans?
Why in 2011, are people still building UI heavy applications with Java?
Why are JetBrains doing it? So they can reuse code.
At least I hope that's why. If that team isn't sad about not being able to provide a proper Mac GUI then they're out of touch with what's good about the platform.
First, JetBrain IDEs that I've used are lightyears ahead of Eclipse and Netbeans in terms of performance. Secondly, they have a lot of established code written in Java. Thirdly, their other IDEs are cross platform.
I'll wait and see how this turns out, but their other offerings are excellent.
I think you've made a bit of a misconception here in confusing the underlying programming language (Java) with the UI library. Assuming you want a program to act and function naturally, like an OS X application - in which your problem is really down not to the programming language used. It is down to the libraries that are being used to develop the UI. Were people to be using Java as the language, but building from a Cocoa binding then you'd be able to have the same UX as a native app. Netbeans uses its own library, which is based on top of Swing. This doesn't feel native at all.
It is also worth noting that there's a big difference between the Gui Libraries that Eclipse and Netbeans depend upon. SWT, the library that eclipse depends upon is actually using native widgets /most/ of the time underneath. Unfortunately it does a lot of its own UI stuff on top of those widgets, and doesn't really follow Mac OS guidelines. I still feel its an incredibly well designed UI though in many regards.
Our startup's main product uses Java for a UI heavy app because makes it cross platform out of the box and is relatively easy to develop a nice, native looking UI with if you know what you're after.
Our closest competitors locked themselves to one platform and have faced challenges trying to go cross platform.
Being 'easy' is irrelative when it results in a terrible user experience. There's no way to explain to the user: "oh this would look a lot better but we wanted to use a different language so it's not our fault".
Most of the great IDEs are java. Jetbrains makes their money in the java market, so seems reasonable to leverage their existing code base. Also, java gives you cross platform. Not an issue for AppCode, but it's a biggie for all their other languages (ruby, python, php, java)
JetBrains does a lot of good things. The fact that they bring their ideas to a number of different languages is a great thing. Resharper, IntelliJ, RubyMine, PyCharm, Phpstorm and now AppCode - you could stick purely to Jetbrains products and have a familiar IDE layout and functionality for the various different application development tasks you undertake.
I've wished many times for ReSharper-like refactoring in Xcode. Now JetBrains (the ReSharper people) have announced CIDR, an Objective-C IDE.
Apparently CIDR is still at an early stage (pre-beta even) and doesn't yet support debugging on a physical device, but I still take this as great news. I think allowing developers to download and try CIDR now will give JetBrains the feedback they need to deliver a great finished product.
I don't think most Xcode users know what they're missing. And unfortunately they still won't, just by looking at screenshots and perhaps firing this up and having a quick bash around.
Some really good screencasts are needed to show what's possible with appCode - fortunately JetBrains does excellent screencasts for their other products and I'm sure they'll do these as it gets closer to release.
As for me, I'm a long-time IntelliJ user. Xcode 3 has been incredibly painful to use - even after taking a lot of time and effort to learn the keyboard shortcuts.
Xcode 4 is a major step in the right direction and started to actually make iOS coding reasonably fun. But it still can't hold a candle to the features available in this early release of appCode - it's awesome.
Here is one small example of something that won't be apparent to someone without a demonstration.
Say I have a class called Foo and I realise, as I'm using it, that I want to add a method called doSomethingElse, I can just type the new method call and have appCode create the method for me. Ie:
Foo *foo = [[Foo alloc] init];
[foo doSomething];
[foo doSomethingElse]
doSomethingElse would be marked in red. I just have to hit command-enter, select 'Create method' and appCode creates the method signature in Foo.h, creates the method in Foo.m and puts the cursor in the body of the method ready to implement it.
That strikes me as a good example of where the kinds of features JetBrains is known for don't really mesh with Objective-C.
If doSomethingElse is a method defined in a category I expect to be loaded at runtime, or something I expect to be caught by foo's forwardInvocation method, having it turn red and bug me to provide an implementation in Foo is exactly the wrong thing to do.
It's the kind of little feature that really only makes sense in the context of a static language like C#, where a method call without a corresponding method implementation can be known definitively to be an error.
That's interesting but I'm confident in JetBrains getting this kind of detail right. I don't have appCode in front of me but I'm sure they'll implement something to handle it. They go to great lengths to understand your entire codebase including any libraries/sdks you might link with.
They've had to do similar things already with Javascript, Ruby, etc. Even Java has similar issues - for example you can use reflection to call methods. So it may mark a method as not being used in your project. But for 99% of cases it gets it right.
GCC would give a warning if you tried to compile this, and Xcode 4 would highlight the offending line with a yellow bubble. appCode's behavior doesn't seem too inappropriate in this case.
I am sure it will get polished before the final release. All IntelliJ IDEs can install a very functional VIM plugin - that itself is a big deal for me!
As a java developer that needs to also support native iphone and android apps, this is a huge win for me. Its very nice to jump around projects using the same familiar keystrokes and functions.
The disclosure triangles and combo box look native. The icons, scrollbars, tabs, toolbars, status bar, tip-of-the-day dialog (wtf?), and confirmation dialogs all are obviously non-native, some of them in ways that are trivially fixable (such as getting the button order right in the confirmation dialogs).
I understand that it's pre-beta, but if they consider the current GUI to be even a prototype instead of the placeholder that it is, they'll likely never get any traction outside of Java developers trying to cash in on Apple's App Stores.
> but if they consider the current GUI to be even a prototype instead of the placeholder that it is
I doubt it is. It's not the first Jetbrains IDE on OSX. They may decide to go a very different graphical route for this one as it's pretty obviously OSX-only, but that's not really a given.
I noticed it has the new "vanishing" scrollbars. Looks a little ugly, but it's not that bad. I expect it will get better with time. I like the color-coded tabs and easy tab switching. The editor itself lags a bit.
Strangely enough, it didn't recognize my .mm files as Objective-C++ files.
Unfortunately, it has a crappy Java-generic GUI. For an IDE for a platform that makes a big deal out of user experience, it really looks awful. (And it manages to be slower than Xcode 4!)
I understand that tools don't have to be pretty to be functional, but I draw the line here.