If you’re a Mac developer looking forward to the release of the iPhone Software Development Kit with a glee usually reserved for Christmas mornings, then you might want to temper that enthusiasm just a wee bit. Developing for the iPhone, as it turns out, won’t be quite like developing for the Mac, though they do share some underlying similarities.
Take it from one who knows: namely, Iconfactory programmer Craig Hockenberry, the fellow responsible for Twitterrific. Craig’s penned some thoughts on what it’s like developing for the iphone, given his experience trying to hack out a native version of Twitterrific.
Don’t expect to reuse much of your existing code. If you’re using a standard MVC design (which is pretty much inescapable if you’re using Cocoa) then about 2/3rds of the application will require major rework.Heed his words, children! He knows wherefore of he speaks. It’s a worthwhile read for anybody who’s interested in developing for the iPhone. Which, come on, is all of you.From my experience, your models and the infrastructure that support them can be reused without much effort. On the other hand, the multi-touch interface obviates the need for your existing views and controllers.
Unless Hockenberry is breaking a NDA and knows the final SDK is going to be exactly like programming on a jailbroken iPhone, isn't it a little early to be saying what it's going to entail? I would expect Apple to make something like Xcode's Interface Builder for the iPhone so programmers don't have to reinvent the wheel each time through code.
Apple's toolchain is definitely going to be more elegant than what's available now.
While I'm sure he's talking about developing for Jailbroken phones, I can't imagine that it would somehow be different.
What he's saying makes sense and is generally correct. The idea behind porting apps designed via MVC is that the model is where the work is done and is portable. The view presents your interface and should not be portable (because you should be designing for the interface) and the parts of the controller that deal with the interface will not be transportable either.
Again, though, the important point to consider is that an iPhone is not Mac OS X. Figuring you're going to take your Mac OS X app and recompile it for the iPhone is not something your customers will appreciate. Much as I don't want some Windows app ported to Mac OS X, I don't want some Mac OS X app ported to iPhone. Instead, I'd rather buy an application where someone has actually put some thought into the differences between the two platforms and designed an interface which takes advantage of that.