AppCode: Objective-C IDE from JetBrains goes public
blog.jetbrains.com
blog.jetbrains.com
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.
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.
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.
If the final version of this looks and runs as well as iDEA, it will do just fine, and will hopefully bring OSX/iOS dev back down to earth.
Just give it a chance is all I'm saying.
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.
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.
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.
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.
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.
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
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.
PhpStorm is simply the best IDE I've used for our very large PHP application. And I've tried almost all of them.
Why in 2011, are people still building UI heavy applications with Java?
I'll wait and see how this turns out, but their other offerings are excellent.
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.
Our closest competitors locked themselves to one platform and have faced challenges trying to go cross platform.
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.
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.
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.
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.
This improves coding flow remarkably.
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.
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.
doesn't look ugly to me. Looks clean actually...
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.
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.
Strangely enough, it didn't recognize my .mm files as Objective-C++ files.