The difference between how Twitter and Apple treat their developers

Something has been lingering on my mind lately regarding some pertinent issues involving Twitter and how they treat their developer community. They’ve been on a trend lately of buying out popular third party clients that access their API, for better or worse. Naturally, this has created some feelings of hostility in the development community.

Even though I’m not in the business of making third party Twitter clients1, I can understand how those who are currently have some trepidations about what may happen to their product. With Twitter’s official iOS and Mac clients, as far as I know they are the only apps that both support the streaming API and have zero API rate limitations. This may seem like an unfair advantage for some people, although I can compare what they are doing here with Apple’s own use of private APIs that third party developers don’t have access to. This just seems like the nature of the game, however, from what I gather it doesn’t make people all too happy.

If you’re learning the Twitter APi right now, it seems like the best course of action is to integrate some functionality into a more interesting and unique product — utilizing the features of the API to supplement your own stuff. A great example of this is Buffer, which uses the Twitter API to help people schedule Tweets at the times they choose. The functionality of it seems to differentiate enough from what the intended core Twitter experience is supposed to be. Twitter seems to focus their time into making the service easier to understand, which means not including more advanced features like scheduling tweets. Power users are a small niche, so it’s completely understandable that they wouldn’t want to spend their time catering to that group of people.

When people get into iOS development, they know full well not to develop apps that are too similar to Apple’s own. In addition, they are also warned by Apple that they should try and create something unique, instead of yet another fart app or flash light app. The key here is that you know full well in advance what to expect out of the iOS development network and the App Store review process. With Twitter, they also encourage people to create their own unique apps that leverage their API. They’ve already made it clear that what they don’t want is for you to create yet another vanilla Twitter client. They’ve already got that handled, and it seems evident that they want to set the gold standard for what they believe is the ideal user experience. Honestly, I can’t fault them for this and I’ll certainly give them the benefit of the doubt that they want nothing but the absolute best experience for their users2.

There are a plethora of Twitter clients on the iOS and Mac App Store, and I wouldn’t be at all surprised if Twitter ends of acquiring more of these as well in the future3. I think the Twitter iOS client space is so full already, that I would be hard-pressed to believe any sane person would want to even attempt to build another client. Of course you have great companies like the Tapbot guys that came out with Tweetbot, which is a pretty exceptional Twitter client with a unique look. What concerns me though is how long will it be until Twitter aggressively chases them to buy the product? Twitter already has their own official iOS client, which was built off of Tweetie. This would potentially mean their app would just be dumped, which would leave all of those people who paid for the app really unhappy.

The more I cogitate on this, one glaring difference I see between Apple and Twitter, is that if you develop on Twitter’s platform, you end up getting bought out fairly quickly.

* * *

1. I don’t build my businesses on top of someone else’s API. [↩](#fnr1-2011-13-05 “Jump back to footnote 1 in the text.”)

2. Sans the [dickbar fiasco](http://www.marco.org/2011/03/20/why-the-quick-bar-dickbar-is-still-so-offensive) of course. [↩](#fnr2-2011-13-05 “Jump back to footnote 2 in the text.”)

3. So far Loren Brichter’s Tweetie and Tweetdeck have been acquired. [↩](#fnr3-2011-13-05 “Jump back to footnote 3 in the text.”)