I love Twitter. The service itself has connected and reconnected me with more people than I could have imagined. I have made lasting friendship with a couple folks on another continent. I have been able to candidly chat and bounce ideas off fellow writers who inspire my own writing. I have been able to help with the development of some of my favorite apps on iOS and Mac OS. I have met many of my local friends through Twitter, and a few of those friendships have developed into bonds similar to family.
To say that Twitter has become a new communication medium that has changed and will continue to change lives is an understatement. But some of the fun of Twitter is fading. And that's because the folks in charge of Twitter1 don't seem to be fostering a community and ecosystem anymore.
Tweetie — The Harbinger of Doom
Those who have joined Twitter in the past six months or so likely don't realize that Twitter hasn't always had its own official app. In the old days, Twitter's official ways to access the service were via the website, the mobile website, or text message. Much of Twitter's popularity was garnered by third-party apps such as Twitterrific and Tweetie. Twitterrific was the first on the scene, and Tweetie was a late-comer, but quickly became the darling of many users.
In April 2010, Twitter acquired Tweetie and rebranded it as Twitter for iPhone, making it the official Twitter client. Over the next year official clients popped up for Blackberry and Android. The iPhone app became universal with the addition of an iPad interface, and the Mac version of Tweetie was updated and rebranded as Twitter for Mac.
This foray into official apps was the first blip on the radar.
A Shot Across the Bow
Back in March, Twitter's Platform/API Leader Ryan Sarver posted a note to third-party developers about the future of fully featured third-party clients.
Twitter will provide the
primary mainstream consumer client experience on phones, computers, and
other devices by which millions of people access Twitter content (tweets,
trends, profiles, etc.), and send tweets. If there are too many ways to use
Twitter that are inconsistent with one another, we risk diffusing the user
experience.
and
Developers have told us that they’d like more guidance from us about the
best opportunities to build on Twitter. More specifically, developers ask
us if they should build client apps that mimic or reproduce the mainstream
Twitter consumer client experience. The answer is no.
The day that was posted was not a good day to be a developer of a third-party Twitter client.
The x & O of Auth
A year ago Twitter made a change in how third-party apps access the Twitter service. Instead of Basic Auth, where a user supplies their username and password and an app stores both of those credentials, the service moved to OAuth, where a client receives and stores an access token linked to the user's account. This token can be revoked at any time from a user's settings page on the Twitter website. So OAuth is nice in that revoking access from a client is much easier if needed.
The problem a year ago was that OAuth requires a web view for the user to give permission for the client to access the Twitter service. It's janky and ugly and doesn't work very well on a smartphone, in my opinion.
Third-party developers voiced these same concerns, so Twitter adopted xAuth, which allows a developer to make a beautiful interface that asks for the user's username and password, and uses that momentarily to request the OAuth token. The token is then stored, and the user's credentials are not. This is fantastic for third-party clients. All the security benefits of OAuth with the ease of Basic Auth. It's a win-win-win for Twitter, developers, & users.
Well, one week ago Twitter announced (developer oriented version here)that they were removing direct message access from xAuth, and all full-featured clients would have to switch to the problematic OAuth web interface if they wanted to continue giving their customers direct messages.
John Gruber comments:
That’s good news on the surface — it means you can use services and apps that require your Twitter credentials without granting those services/apps access to your private direct messages. For services/apps that are entirely public, this makes sense.
But there’s a big shit sandwich attached: Twitter is implementing this change by requiring all third-party clients that want or need access to direct messages to use the cumbersome OAuth login flow for authentication.
[…]
Thanks to OAuth, you never need to give these sites your Twitter password, let alone allow them to store your password. Instead, they forward you to twitter.com, you grant them access to your account there, and then twitter.com forwards you back to the website where you started. It’s common sense: a web-based authentication flow works naturally from within a web browser.
But the same web-based authentication flow is jarring for native apps. When you open a native app — Mac, Windows, iOS, Android, WebOS — you don’t expect to be forwarded out of the app and into your web browser. Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth — but there’s a huge decrease in usability, simplicity, and clarity to the user.
[…]
And OAuth is even worse for setting up multiple accounts in a native client (and good multiple account support is surely one of the leading reasons to use a native Twitter client instead of the twitter.com web site). Because then, not only do you need to go through the cumbersome OAuth login process for each additional account, but you must first sign out of the Twitter account you’re already signed into in the web browser. The twitter.com web interface is inherently single-account. To use a different Twitter account in the same web browser, you have to first sign out, then sign back in using the other account. With xAuth, to add an additional account you merely enter another username and password. With OAuth, you have to start by signing out of whatever account you previously signed into. You only have to do this when first creating each new account in the client app — the app can save the OAuth credentials for multiple accounts — but it’s still far more complicated and annoying than simply entering a username and password.
The whole article is worth your time. There's a lot of gold in there.
To me, this move is solely to make life difficult for third-party developers. Even though I don't think Twitter would be nearly as successful today if the third-party clients hadn't made Twitter such an attractive medium, I also don't think Twitter owes developers in the long-run. It is their platform, after all. Same goes for Apple and Android, etc.
I do however, think Twitter has been rather duplicitous. Why have the annual Chirp developer conference when the company obviously does not want to foster an ecosystem? It doesn't make much sense.
Sadly, I don't think we will see fully featured third-party Twitter clients by this time next year. I think Twitter will cut them out. Which, in my opinion, will also cut out innovation on the Twitter service as a whole.
A Symbiotic Relationship
Throughout the past few years that I have been a Twitter user, I have always used a third-party client as my primary access to the service. I started out back in the day with Twitterrific, which was only available for the Mac (the iPhone didn't exist yet). My usage exponentially took off after I got an iPhone 3G on day one and Twitterrific for iPhone was available that day on the App Store, which also debuted that day. I had a brief affair with Tweetie on my iPhone for a couple months until Twitterrific updated with a lot of nice new features. And my Mac saw the occasional use of Tweetie for Mac, though I used my iPhone more because I love Twitterrific. And now Twitterrific is available using the same experience on iPhone, iPad, & Mac. So that is where I am happy.
Tweetie, however, was very great on both the iPhone and Mac. But the quality of both apps seems to have degraded since the developer sold out to Twitter. They may be the official apps, but they were both more stable and a better overall experience when Loren Brichter worked alone on them.
Now that I have established ad nauseum my preference for a third-party app, let me tell you why: that's where all the innovation has come from.
I'll start with a few that Craig Hockenberry, lead developer of Twitterrific, came up with regarding his app:
- First use of “tweet” to describe an update (see page 86 of Dom Sagolla’s book.)
- First use of a bird icon.
- First native client on Macintosh.
- First character counter as you type.
- First to support replies and conversations (in collaboration with Twitter engineering.)
- First native client on iPhone.
There are a number of the central themes of Twitter that came from one third-party app. Not to mention that @-replies and Retweets2 were innovated outside of Twitter itself as well.
My point is that third-party clients have been an important part of the Twitter experience. For many third-party clients were and are their main experience with Twitter.
Twitter gave developers a service to build upon, and developers in turn gave Twitter a user base and ideas on how to make the service even better. Many of these ideas I don't think Twitter would have implemented on their own. And now it just comes off that Twitter is stabbing developers in the back.
If you've seen the first Iron Man movie, Twitter sure seems a lot like Obadiah Stane, and developers seem like Tony Stark. And Obi is trying to kill off the golden goose that churns out invention after invention.
