Tweetie 2 ā€“ A Case Study in Making iPhone Apps Leaner


It’s really hard to make iPhone apps lean. With Apple’s walled garden (i.e., the App Store), it’s tough to both test applications and control the time between iterations. In the first case, there’s a way to do that – ad hoc distributions – but as any iPhone developer knows, it’s not very fun. In the second case, even when iterating quickly, there’s no way to know how long an update is going to sit in Apple’s approval queue. There’s more to discuss on making iPhone apps lean but for now, let’s move from the conceptual to the tactical and take a closer look at Loren Brichter’s Tweetie 2 announcement and how it will make his iPhone app more lean.

Tweetie was first released on the iPhone back in November 2008. The core philosophy of it then, as it is now, was speed, simplicity, and the Apple way. Unlike many iPhone apps and particularly iPhone Twitter clients, Loren embraced what he described as the “iPhone interface philosophy” and thus did not re-invent the wheel for the UI elements. He believes his design choices were part of his success.

In April 2009, Bigbird, a new core architecture for the then impending Tweetie for Mac was announced. At that time, Loren wrote that Bigbird would become the foundation for Tweetie 2 for iPhone.

Of course, that leads us to the present. All the big blogs are a buzz about the upcoming release of Tweetie 2 for iPhone, including tantalizing screenshots. Those screenshots are what have blinded the pundits to the most important news of the release — the architectural changes and what they’ll mean for Tweetie going forward.

Going back to making iPhone apps leans, two of the big issues are testing features both from a true feature standpoint (i.e., validating usefulness and effectiveness) and stability (i.e., does it work properly and not have bugs). Unlike in a web environment, there’s no real ability to A/B test and as mentioned before, performing quality assurance is a pain in the ad-hoc distribution. There’s a handful of ways to think about dealing with these issues — but let’s focus on how Tweetie did it.

1) Tweetie for Mac

Like TweetDeck (and soon EchoFon), Tweetie has an advantage over other Twitter iPhone clients — it has a desktop companion.

Now, not all iPhone apps can or should have a desktop counterpart. But those that do will reap the reward of tremendous learnings. While clearly an iPhone app versus desktop or Web-based app requires some different thinking, having a non-iPhone environment for A/B and QA testing features can allow a more proven app to go into the App Store. Especially when…

2) Synced Codebases

Loren will soon sync the Tweetie for Mac and Tweetie for iPhone codebases. He writes the following,

“Once I sync the codebase for Tweetie for Mac and Tweetie for iPhone, expect an explosion in functionality. I will be able to explore new features in Tweetie for Mac, pushing out updates there instantly, and once Iā€™m confident that changes are stable, push updates to the iPhone.”

Tweetie’s unique advantage is that its desktop app is native to Mac. Unlike TweetDeck, which in all probability has to port many elements of its AIR-based app to the iPhone, Tweetie will have one core architecture powering both of its applications.

The key point, as he indicates, will be that Tweetie for Mac will become a test bed for Tweetie for iPhone. Once that occurs, Loren can quickly test different features across a much larger number of users, both for validation and QA, before incorporating them into Tweetie for iPhone.

Part of this testing will be facilitated by the fact that his architecture can “push out updates there [Tweetie for Mac] instantly.” Building his application this way seems to indicate that he is very interested and committed to trying out new features and learning what works best.

Concluding Thoughts
Ironically, it took the Tweetie applications nearly a year of what probably would fairly be described as non-agile development to make it more agile and lean. The last major update from Tweetie developer Loren Britcher was in April 2009, which means he has had his head down in development for about 4-5 months.

Although his initial reasoning for building Tweetie for Mac was likely not motivated for being able to test features, clearly that’s now a major benefit because of his new architecture and being based on the Mac platform.

The “Tweetie approach” can definitely serve as a model for making iPhone apps more lean. But it is a model. There are many cases where it wouldn’t make sense to have a counterpart or companion application on the desktop or Web. For those that do, having a native Mac application, even a stripped down MVP-style one, could go a long way towards making iPhone app development much leaner.