Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
JetBrains AppCode: an Objective-C IDE That Makes a Difference (jetbrains.com)
122 points by oemera on Oct 26, 2011 | hide | past | favorite | 51 comments


I really, really love Jetbrains. Even though I'm not an iOS developer, it's still nice to see that they are working to add their own flavor to the mix with other languages.

I wish so much that they would create a Visual Studio replacement. I'm primarily a Ruby/PHP developer and use their PhpStorm and RubyMine products constantly, but whenever I am stuck doing something in .net and have to open up Visual Studio, I just get a gross vibe from the entire experience... And this is with Resharper installed as well!

I see Visual Studio get a lot of support on HN, so maybe I am just weird, but I've never enjoyed using Visual Studio as a whole.


"I see Visual Studio get a lot of support on HN, so maybe I am just weird, but I've never enjoyed using Visual Studio as a whole."

Me neither. I switched from Visual Studio (C#) to Emacs (Common Lisp) -- and a short stint on the AllegroCL IDE -- and I do not miss Visual Studio one bit. It always struck me as odd to see Visual Studio getting praised here. I can only assume it fares better than Netbeans or Eclipse?


I can't speak for everybody, but I always rated Visual Studio because of its zero-effort code navigation and code completion. (No setup required, and it's surprisingly good at seeing through common preprocessor tricks.) The debugger is pretty good, too, the text editing experience is fine, the whole thing is 99% operable via keyboard, and the scripting language is bearable.

This probably doesn't sound like a rousing endorsement, but I've yet to find anything that's as good for reading and writing C, C++ or C# code.

(People using Visual Studio for anything else should definitely consider shopping around, though as general-purpose text editors go it is far from the worst possible.)


> zero-effort code navigation

Try the ReSharper VS addon from JetBrains -- it makes navigation much much better. VS code navigation really is primitive in comparison.


Agreed. I used to think that I didn't like VS because I also didn't like .NET. I still don't like .NET, but after using other IDE's for other languages (primarily Jetbrains' products) I have grown to dislike it even more.

It feels like the Internet Explorer of IDE's to me. I am not sure whether or not my distaste is justified since I am well aware that it is a powerful IDE, I just hate how bloated it all feels. That and its incredibly annoying that once I wish to uninstall it, I end up having to uninstall about 20 other programs too. Very obnoxious.


VS does 90% of things pretty well, and you hack and slash your way around the stuff it doesn't do well.

VS is one of those interfaces that is easy to grow into, out of the box it's pretty functional and eventually you learn all of it's features as you go. Resharper really makes VS a much better product. Intellisense practically codes for you and has just enough of the documentation that you don't need to dig into MSDN that often.

XCode especially anything before XCode 4 is pretty abysmal, I really enjoy JetBrains other products (except for their RoR IDE). I was really surprised at how horrible XCode is given Apple's penchant for UX (too bad Jobs didnt code). Looking forward to using AppCode, I'll be really happy if there is usable code completion.


VS just tries to do too much. Integrating TFS is a bad idea, that should be a separate application entirely (or possible 2 separate applications). VS nails the core functionality it has provided since VS2003; code completion, refactoring, debugging. Too bad the featuritis means we have to deal with weird bugs like random freezes that require to close all the way out and restart. You can always just use the text editor of your choice and msbuild though.


How I wish they would hire some experienced Lisp people and make a dream IDE.


I love JetBrains products. These guys are awesome. I don't write Apple Code (iOS or Mac OS), but I'm sure it is really cool.

They built my favorite Java IDE, IntelliJ.


This will probably be a great project for people who are used to JetBrains products. If you are developing iOS applications on the side you won't have to learn a whole new environment.

For 100% iOS development I doubt many people will switch. The integration between Xcode, Interface Builder and the various Apple frameworks is something that will be hard if not impossible to implement in another IDE.


Plus you can't beat free.


True...Even thought I have never used the Apple Frameworks... you can't beat the integration. That is why Visual Studio is so popular too.

Maybe JetBrains should build their own OS! (just kidding)


I tried really hard to get used to it when AppCode was still in beta. But the lack of integration made it too hard. I miss my Vi plugin though.


I might be missing something, but was are the advantages of this over using Xcode?

I'm all for options, and $50 to $150 usd is not prohibitive for an IDE, but since Xcode is free and directly from Apple, there must be some really good features for me to switch IDEs.


Disclaimer: I do Java using Eclipse for my day job, and have used one of their Java IDEs in the past (IntelliJ IDEA). The code-editing side of XCode compared to these IDE is like a relic from the 90's.

Once you use a refactoring tool to rename a class and have it renamed everywhere in your project, you get a taste for what XCode is missing. There are several refactorings like this that shave a lot of time out of some of the more annoying tasks. Code generation allows you to define a method or property once and have it added to both .h and .m files, as well as have properties synthesized. If you want to add an argument to the method signature, that is done in one step, too. The SVN integration in IntelliJ IDEA was superb. I have had issues using SVN in XCode where the interface refuses to load history, and the interface for managing conflicts just isn't there (try having 2 devs change the project file). These are just a few things off the top of my head.


What you have to realize is that refactoring is a dangerous concept in Objective-C, regardless of which IDE you use, because of Objective-C dynamic nature. Classes can be loaded or switched at runtime, non-existant methods can be called, and class and methods can be variables. Cleanly refactoring is much easier to achieve in a statically-typed language such as Java, which is why Java IDEs are so much better at automatically refactoring.


This doesn't really ring true to my ears. I have some experience with Smalltalk, which is where refactorings were pioneered, and which Objective-C has some roots in. Smalltalk is even more "dynamic" than Objective-C. If you get the chance, I recommend playing around with Squeak or Pharo.


It's not (just) the dynamism of Objective-C that make some refactorings unable to be guaranteed to produce correct results; the "C" part plays a big role as well.


Have you tried Xcode 4? I'm not its biggest fan, but, it is a step up from Xcode 3 when it comes to refactoring. It can rename a class everywhere in your project, for example.


Xcode 4's refactoring is still quite poor. Renaming something is akin to a "find and replace all" in my experience. If two unrelated classes have the same method name, Xcode will rename all instances of both classes if you rename one of the methods.


Off-topic: How would you compare Eclipse to IntelliJ IDEA and why did you choose Eclipse?


I've used both. I have a personally bought copy of IntelliJ, though I'm using Eclipse now.

For the most part, they're both comparable. Both have powerful refactoring and code-generation abilities.

For core Java development, there's no need to leave Eclipse. IntelliJ might provide some nice features, but overall it doesn't warrant purchasing a license.

When combined with web development, other languages, or non-core development, is where it easily pays off to switch to IntelliJ.

We were doing some Grails work, and Eclipe's support (via STS) was shady at best. We put off trying IntelliJ since it meant learning a new environment, new shortcuts, etc, but after about a day of playing with it, we were sold, and never looked back.


For the record, there's a free version of IntelliJ now. (Community Edition)


IntelliJ is also a lot nicer for Scala than the Eclipse plugins. The Python plugin is pretty excellent too; it brings in most (all?) of what you'd buy PyCharm for.


My current employer (and myself, too) had a history of Eclipse already when I started. Another dev got hired that was an IntelliJ nut. He was able to set up a working environment without "contaminating" our projects. Occasionally we would pair with him driving, and I was always impressed by the speed and quality of the IDE. Once he left I never bothered to look further.


I tried it out for a bit a couple of weeks ago. I didn't stay with it because it didn't seem to be playing nice with the beta Xcode, but I'm still interested in switching. My two major reasons are refactoring support and the vi plugin. Having used Resharper for a long time in C#, I feel slow in environments without it; App Code begins to bring the Resharper convenience to Objective C.


XCode is based on the same framework as the other IDEs, so you can expect excellent refactoring, static analysis, and "code rewriting" features. Also, the version control integration of the platform is top-notch, especially for git. I use IDEA to manage all of my local git repositories, and I only use the command line now for pushing remotes and git-log (I use IDEA for the rest because it is faster for me).

Disclaimer: I'm on the JetBrains "Academy" which means they sponsor some of my speaking and stuff.


I think you mean AppCode instead of XCode.


The main reason I use IntelliJ products (IDEA for Java and AppCode for iOS) is the keyboard support. These guys are serious about making sure every feature is easily done with the keyboard. Xcode drives me crazy because I feel like I'm always reaching for the mouse or tabbing through fields or buttons to drive the UI.

The most common refactorings, like rename method/variable/field or change signature are all easily done through the UI. Example: rename (anything) is Shift-F6, <type new name>, enter. I do this all the time.


If it's better then I am all for it; why use macvim if text edit is free and directly from apple?


The one feature I'd love from any tool with iOS development would be something that automates and facilitates certificate and profile creation and handling. Right now it seems I make a single mistake along the way and everything is messed up.


I renewed my developer account last week and due to an email snafu didn't get the renewal code before my developer account expired. When I finally got the renewal processed and launched Xcode 4.2 for the first time, I was treated as a new developer. In Xcode, everyone was done for me -- creating a certificate, making the team provisioning profile, etc. All I had to do was connect devices so Xcode could grab their UDIDs and add them to the profile.

If you're getting started today, it's pretty damn seamless. Most people find this stuff harder/more painful than the actual coding, so it's a big win for iOS developers.


I've done this. Feel free to hack up my scripts: http://procbits.com/2011/10/10/automating-generation-ios-pus... http://procbits.com/2011/10/07/automating-the-mac-os-x-keych...

All code is open source on Github as referenced in the articles.


I'm a longtime Jetbrains fan (ReSharper and TeamCity).

I looked into AppCode a bit earlier when it was still rough. Getting tight integration is the key for me. Refactorings would be nice (XCode has Rename already), but really what I want are snippets, or something to take some of the drudge code away.

For instance, to add a property I have to add 4 lines of code in 4 different places. This should be one action (which can be overrided later).

Also, code navigation. This was terrible in XCode 3, better in 4, but nowhere near ReSharper or IntelliJ.


Also, automatically add the #import statement when I allocated one of my classes, please.

The ideal, for me, would be the same as ReSharper: a plugin that adds functionality, but that won't happen with Xcode any time soon.


What happens if you delete the last class that #imported something? Do you remove the #import? What if the #import wasn't automatically added? Still automatically remove it?

How about if you don't need the #import for a class, but, instead for something else (say, it #imports a bunch of other classes for you instead, like UIKit.h)?


Definitely worth checking out. Having refactoring support and non-broken SVN integration might be worth switching alone.


A Mac-exclusive app not being Cocoa is perverse.


And it makes you wonder why AppCode isn't written in AppCode. At least the Xcode engineers use Xcode to write it…


Why? What would Cocoa add to this project that would compensate for the additional work?


For one thing, the standard UI elements everyone expects from a top tier Mac app and which this sadly does not deliver.


That would be nice, but I'm not sure it's worth pushing 1.0 back a year or so, all other things being equal. I certainly wouldn't call trading a bit of prettiness for a lot of functionality "perverse."


If you mistake the call for Cocoafication for nothing more than a call for "prettiness", you're naturally going to end up missing why people care so much about it.

Java applications don't support a lot of deeper OS X features that make the platform so consistent. I have custom keybindings set up via the DefaultKeyBinding.dict mechanism that work pervasively throughout the OS, except in applications like AppCode that seem to think that their ease of coding trumps my consistency of platform and configuration. I think that kind of assumption is utterly broken and user-hostile, and it has nothing at all to do with "prettiness".


It was rgbrgb who brought up native GUI elements as the big reason for going Cocoa — I was just replying to his/her comment.

Anyway, like I told frou_dh, I do understand the benefits Cocoa offers. I've been a Mac user since 1985, Cocoa programmer since 2001, got the gold badge on Stack Overflow — believe me, I get it. But I also understand the benefits offered by JetBrains' existing IDE codebase. Engineering always involves tradeoffs. JetBrains' tradeoff may not align with your preference here, but the simple fact is, they now have a highly capable IDE shipping for OS X. Cocoa doesn't have anything particularly helpful to IDEs that would offset the cost of rewriting, so if they had gone with a total rewrite in Objective-C, it seems most likely that they would either not have anything shipping or they would have a pretty but half-baked product (or both).

It's true that not using Cocoa does hurt the product. But there are a lot of ways Cocoa apps can be broken and user-hostile too. The initial release of Xcode 4 was so broken that a lot of people downgraded after trying it for a week. It's still worse than Xcode 3 in terms of stability and responsiveness on average hardware. TextMate has always been Cocoa, but early releases were missing a lot of standard features because so much of the UI was custom code (as the standard Cocoa controls did not offer the functionality TextMate wanted).

So yeah, if AppCode were Cocoa, it wouldn't have all the UI problems it does now. It would have different problems. My point is just that which set of problems you'd rather have is a matter of personal preference. If you disagree with JetBrains' choice, then this is not the app for you, and that's OK.


To not see a problem with this not being Cocoa is to miss what's good about Mac OS X in comparison to Linux and other unixes.

---

My dictionary says this for perverse:

- Showing a deliberate and obstinate desire to behave in a way that is unreasonable or unacceptable, often in spite of the consequences.

- Contrary to the accepted or expected standard or practice.


I do see the problem with it not being Cocoa. The thing is, I also see a problem with throwing out huge swaths of your existing, mature codebase to make a minor project superficially nicer. They're both real problems, and which matters more to you depends on how strongly you adhere to the philosophy that "real artists ship."

When the iPhone came out, it didn't have cut and paste or any third-party apps. When OS X came out, it didn't even have DVD playback or CD burning and it was agonizingly slow. All of those decisions were far more "perverse" than leveraging an existing codebase to bring a new product to market. OS X as it exists today is the product of countless iterations on the promising-but-lousy OS X 10.0. To miss that fact is quite literally to miss what made OS X so great.


I agree that this makes business sense for JetBrains.

AppCode is clearly never going to be iterated in to a good Mac app without a rewrite.


I find it interesting that so many folks whine about how an application looks instead of how much it helps you do your job. AppCode doesn't tout itself as a beautiful Mac application. It's written by developers for developers. We have a saying at my office: 'If you can't code, it's likely that you care about pixel perfection.' I care about getting stuff done. I don't care about how pretty my application is when I'm getting the job done. I like things that increase my velocity (in my case over 50%). I feel like Xcode just gets in the way many times. Simple things like not being able to have the cursor in the middle of a line and be able to simply add a line under the current line (vi lovers: think 'o' from the middle of a line). In Xcode you have to go to the end of the line and hit enter. That is one trivial example of a time saver that AppCode offers. (There are MANY).

Instead of whining about pixel perfection, try taking a look at the things it does and the audience it targets. You probably don't code enough to actually have an opinion that matters much anyway.


Does it have vi plugin?


It appears that it supports most of the plugins that IntelliJ Idea have. I bought AppCode just yesterday and absolutely love it.


let's see if this can beat Apple at its own backyard




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: