I think there's a disproportionate amount of beginner's material that involves the use of storyboarding and Interface Builder, which gives the impression that iOS development is a lot like it is in Visual Basic.
Perhaps other iOS developers can weigh in on this, but I feel like it's fair to say that the most qualified developers do everything programmatically.
I've been doing everything exclusively programmatically since I've started, and I've never had any problems with XCode - to the point where I was surprised when I heard people complain about it for the first time.
From that point, the only downside I see to using Objective-C over Ruby is verbosity, but that seems pretty inconsequential given some of the benefits sandofsky mentioned above.
It's nice that there's something out there for experienced Ruby developers though.
I really agree about the storyboarding stuff - I've had a hard time getting into it. That said, I'm a very experienced iOS dev, and I use XIBs as extensively as possible. I started writing apps before Interface Builder supported iOS in the summer of 2008, and those projects are completely, utterly crippled by the fact that there are thousands of lines of code that create and position views. None of it can be easily redesigned for iPad or enhanced for the 4" display. It'd take forever.
Using XIBs is also great for universal apps. I can instantiate the same controller with one XIB on iPad and another XIB on iPhone, and the layouts can be tailored to the platforms. It's wonderful when a client comes to you asking for an iPad version of their app, and you can duplicate the XIBs, scale them up, resize controls and swap out assets and go home early.
One thing that does suck about XIBs is that they ALWAYS cause merge conflicts. That part sucks and really needs to be addressed (at this point, Apple would probably have to write a diff tool for XIBs!)
> Perhaps other iOS developers can weigh in on this, but I feel like it's fair to say that the most qualified developers do everything programmatically.
It's really variable. XIBs have issues with source control, but they can be very useful for bringing in assets without needing a load of boiler-plate image loading code. iPhoto, for example, is laid out programatically but most of the controls are coming in from XIBs.
I agree about experienced iOS devs doing everything programmatically. IB is really, truly awful, and just about impossible to use in a team with CM. From most tutorials though, you'd think it was required. Not only is it not required, but it's easier and more powerful to not use it at all.
Interface Builder doesn't let you do anything very dynamic (moving panels, things that animate, etc) anyway. In my experience, a person experienced at programmatic view creation is a bit slower on initial creation, but a lot faster at refactoring or changes. A few well placed variables, for example, gives you a lot of instantaneous visual control.
>Perhaps other iOS developers can weigh in on this, but I feel like it's fair to say that the most qualified developers do everything programmatically.
Perhaps other iOS developers can weigh in on this, but I feel like it's fair to say that the most qualified developers do everything programmatically.
I've been doing everything exclusively programmatically since I've started, and I've never had any problems with XCode - to the point where I was surprised when I heard people complain about it for the first time.
From that point, the only downside I see to using Objective-C over Ruby is verbosity, but that seems pretty inconsequential given some of the benefits sandofsky mentioned above.
It's nice that there's something out there for experienced Ruby developers though.