Interface Builder

I apologize if this is an annoying question, but hopefully you will be understanding that I am a huge fan of JetBrains IDEs, just very confused about some things with AppCode.

First of all, there is no way to separate the development process from Xcode, mainly with the need to still use Interface Builder, or the iOS simulator, as well as possibly other tools (I never got as far with the trial as seeing how the process for bundling/deploying and application worked).

From what I have read in the forums, it seems that the intentions of AppCode is to handle the code writing portion only, and the replacement of Interface Builder functionality isn't really on the roadmap.  If that is true, it's not all that surprising because it would be rather difficult to replace Interface Builder in my estimation, especially keeping up with it's evolution in a timely manner, etc.

I guess I am curious what people's experiences are developing for iOS and OS X with AppCode.  Are you gaining enough to warrant having to develop between two IDEs?  What issues or shortcomings of Xcode is AppCode solving for you?

I personally don't dislike Xcode.  I will say that coming from any other development environment to Xcode is quite a shock for probably anyone, and it is very easy to dismiss Xcode as being weird, non-standard, or just too different.  After some time in the environment I have started to be annoyed by it less.  This is actual a very common theme I have noticed with many Apple products.  At first they seem weird, but if you trust in why they are the way they are, often you begin to see a new and often innovative way of doing things.

I guess I should also say that I am of the belief that Interface Builder, and Storyboarding, is going to become harder and harder to decouple from as it evolves and becomes closer to the way Apple "prefers" you do things.

Again, I love JetBrains IDEs, and I guess I'm hoping that there is something about AppCode that I haven't understood yet that makes it a realistic replacement for Xcode.  If you have any opinions or experiences on the subject, I appreciate it!

3 comments
Comment actions Permalink

I've been employed as a developer doing iPhone development exclusively for the last year and have been using AppCode for at least 6 months.

I was happy enough with XCode, but had missed out on much of the functionality that I'd had in the past using ReSharper, so I was thrilled when AppCode was released.

I've never been concered with AppCode being a replacement for XCode.  I leave both open and don't find it particularily arduous to flip back and forth between XCode and AppCode.  (except that both use a lot of memory, so having them both open means I have to keep an eye on memory use in Activity Monitor).

Over time the percentage I spend in AppCode is increasing, and the time I spend in XCode is decreasing.  The biggest factor in this is that AppCode has so much power, but I have to train myself to use it.  Each time I ingrain using another feature, or stumble upon another cool thing it does that XCode doesn't, the percentage creeps some more.  I used to be about 50/50, but now i'm probably 80/20 in appcode's favor.  And even if it was only 20% AppCode, it would be worth it to me.

With Interface Builder in particular, I find that with either IDE, this tends to follow a pattern.
1. In the beginning of a new project, or a new screen/view/etc..., I spend most of my time in Interface Builder setting up the UI and pulling outlets.  
2. Then, there is a significant amount of time simply writing new code and implementing functionality.
3. Then there is a short period of adjusting the views for new design issues, and then things you've learned from getting it running.
4. Then there is a period of time fixing bugs in code and tweaking pixels in nibs.

So, in this pattern, I generally spend some time in XCode/IB with #1.  But writing code, especially new code, is so much better in AppCode, I try to get to step #2 as soon as possible, with #3 and #4 being XCode only as demand requires it.

This natural pattern of development means I'm not really switching back and forth as often as you would think.  I can spend weeks where I am primarily in AppCode with little need of IB. And if I was doing developer-driven testing-oriented development, there would be even less switching.

One of the real successes here, and frankly something that I was worried about, was that AppCode is written by people who "get" Cocoa development.  It isn't just a port of the common functionality of resharper.  I was expecting to get a lot of the great things from resharper, but that was it.  But AppCode cares about things that are uniquely Objc-C and Cocoa.  It offers to NSLocalize stuff for me.  It helps with with NSStrings, adds the @ symbol for me.  It understands release and retain.  They know how annoying it is to declare properties, how to deal with private categories, how protocols work, when a new API isn't available on my deployment target, when an imageName string might be misspelled because it isn't in my project resources, etc...  I can completely customize how I want my formatting, even for automatic code generation.  I can search textually through nibs!

In some ways it is fine that they aren't doing IB, because I would say that UX isn't a particular strength of AppCode/JetBrains.

I still find myself in XCode quite a bit, but generally when I start typing code, I get frustrated quickly that it won't delcare the property for me, or add a function in the private category, or quickly refactor the method, etc... and I switch right away.

Another great thing about AppCode that I don't see touched on much, even in favorable XCode vs. AppCode comparisons, is that the developement team is responsive.  They fix bugs. They implement suggestions.  

For example: XCode/GDB stopped giving me nice crash stacks on exceptions 2 or 3 releases ago, and I haven't seen anything from Apple on this topic.  It makes it a super pain to debug crashes. This is a big issue in my mind. Apple does a great job, and has a lot on their plate, and AppCode benefits tremendously from the tools they free provide, but I have little visibility into what they are doing or why they are doing it.  Yesterday, I complained in this forum about WHERE A LINE COMMENT WAS AUTOMATICALLY PLACED and got a reponse immediately about a bug to upvote and a workaround.  And I can get a complete list of every known issue and every(?) bug fixed for every release!

Every release I've gotten of AppCode, be it alpha/beta/EAP/pre 1.0/etc... has been close enought to release quality that I can't tell the difference.  And they release improvements often.  I think the biggest barrier to using AppCode is learning all the incredible functionality they have,  and the fact that the UI isn't particularily Mac-like.  I'm guessing most people who have used AppCode but aren't sure about the value it provides don't know about the bazillion things it does or can do for you.

0
Comment actions Permalink

Thanks for all the great feedback!  It's good to know that you have been able to benefit from it so much, and that you find working along with Xcode to be pretty seemless which probably becomes easier with experience.  I'll definitely give it a try on my next project :)

0
Comment actions Permalink

David's post is really well-put, and reflects my experience (after several months full-time with AppCode) almost exactly. I make quite a bit of use of Core Data, so have to jump into Xcode quite a bit to edit models. I have to say though I never stay there to do any actual coding, because writing Objective-C in AppCode has become such a frictionless and intuitive experience. Clearly part of that is my familiarity with AppCode's facilities. But  the way JetBrains have thought the editing process through really does afford a fluency that Xcode doesn't  approach.

0

Please sign in to leave a comment.