TweetBoxes iOS Twitter client
Focus
iOS Native
Responsibilities
Concept, Design, Coding
Timeline
Late 2008
Thoughts
In 2008 I took on Twitter. At that time the Twitter API was very welcoming. The world of iOS was still a battle-ground, however. I set out to change a bit of both.
Design
As for the client design itself I wanted to follow the standard user patterns and expectations, but offer a more stylized experience. From far more graphical elements to animations, the client was pushing what the current-generation iPhone could do.
Technology
Much like the UX, the technology used in TweetBoxes was pressing the limits of the device. There was a constant balance between performance and feature. Using an SQLite database offered some more random-access features and updates. However, prior to Core Data SQLite had a bad habit of being entirely bound to active memory. With the clear expectation of tens-of-thousands of active updates and records at any one time, there was a great amount of engineering in this seemingly-simple client. Cached “read positions” per list, Auto-scroll positioning within these monstrous lists, unread mechanics for multi-attributed items. Some of my best days were hidden within the confines of that system.
The purpose of this client was to allow you to organize the people you followed into “groups” (known now as Circles in Google+ and Lists in Twitter). 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 death-blow for the application was in late 2009 when Twitter began changing its 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.
