I also took on a Twitter client when it was a service just starting to gain public attention. The API was very open, the ecosystem was very active and there was lots to learn from writing such an integrated application.

TweetBox started its life as “Twitter Box”. But after a few direct communications from the team at Twitter it was decided that I would relinquish the “Twitter” title and become “TweetBox”.

The major difference with this Twitter client was that you could organize people you followed into “groups” (known now as Circles, thanks to Google Plus). This allowed you to pay attention to only certain “channels” of the stream. At the same time, and the more complicated part, was that the client would keep track of what tweets you had read in each box. This meant more of an “inbox” style of view. I was interested in keeping the “stream” concept of Twitter and allowing a customer to not feel as if they had “missed” a bunch of things.

The client was filled with technical solutions to overcome the challenges this concept introduced. With a local database of recent tweets that pruned itself and performed lazy loading and interactive messaging, TweetBoxes was a very advanced client and truly jump-started my iOS skills.

TweetBoxes also introduced a concept of interactively marking items as read as they scrolled by. This was coupled with the concept of scrolling to the top to mark all as read. These are now somewhat regular patterns in small form factors.

The death-blow for the application was in late 2009 when Twitter began changing it’s security model to use OAUTH as the log-in technology and began forcing somewhat aggressive timelines on client developers to “adopt or die”. I saw this as writing on the wall that Twitter was not convinced in their third-party development community as beneficial. This action, coupled with the “change your name or else”, created a less-than-attractive environment to maintain an application.