To Three20 or not to Three20...

My answer, and one I wish I came to a bit earlier, is not to Three20.

And the reason is this. It is a completely different architecture to the native UIKit framework. Which is fine, it’s supposed to be. But because of this, making what should be minor changes to the appearance of a table view cell, for example, can become troublesome.

Some of the problems I had were because of the lack of documentation. I’m not complaining about that, because the open source project grew out of an internal one which, if it’s like almost ever internal project I’ve worked on, everyone on the team knew pretty intimately. Documentation will improve. And that’s a good thing.

The one thing that I do like about Three20 is the whole request model thing. If you wire up a TTTableViewController, TTDataSource and TTModel, all the UI around loading and reloading data is pretty much taken care of for you.

But the other UI stuff is more trouble for me than it’s worth. I was initially attracted by the URL navigation feature, but really, I’m just adding another layer of complexity, especially when it comes to passing objects rather than scalar strings and numbers as parameters. And even then, there is unnecessary conversion to and from strings to create the URL and then extract the parameters that will get passed to the init method.

So I will be migrating away from Three20 in subsequent builds of Zoopcast. Yes, this is the first time I am blogging about Zoopcast, the startup I founded in July. We’re nearly ready… stay tuned (by following @zoopcast, who is eerily silent at the moment).

But that’s not to say that it’s not a good library. It is. And will be better after the bug crushing week that is happening now as well. But it’s just not appropriate for this case. It obviously has its uses – it is what one of the most popular iOS apps, Facebook, is based on.