In a way, the Twitter platform has come full circle. Twitter’s API grew out of its website as a means to enable outside developers to accomplish what the company, with its then-tiny and overburdened team, could not. Now that Twitter has ample resources, the matured platform is enabling the company to build the best applications in the ecosystem in-house. Going forward, it may be that the Twitter Platform primarily serves Twitter’s interests, in stark contrast to the era of API growth I was around for, in which platform development was driven almost exclusively by the needs of the developer community.
From Alex Payne’s The Very Last Thing I’ll Write About Twitter (via whitneymcn)

There are a lot of reasons I took the opportunity to sell Birdfeed when I did—the personal toll the bruising iPhone Twitter client market was taking on me, imminent financial concerns, the opportunity to be an early employee at Square—but without a doubt, my perception of an emerging, strong product direction at Twitter played a big part.

I was a very early user of Twitter (user #528 to be exact) and had already written my own API app for Delicious when I signed up, so the idea of creating a third party client to compensate for some of the service’s surprising oversights and frustratingly slow pace of feature development occurred to me early on. After I left Apple and went indie, I finally had an opportunity to actually put the considerable thinking I had done about my ideal Twitter client into practice.

By then Twitter was just beginning to solve some of the scaling problems that had limited the ambitions of early clients like Twitterrific for years, but it still lacked a strong product direction. Twitter’s improved reliability, massive growth curve, and still somewhat uncertain sense of itself, combined with the advent of the iPhone and App Store, meant that the time between the release of the iPhone SDK and Twitter’s acquisition of Tweetie was something of a golden age of Twitter client development—a time when an ambitious, lone developer working in a cafe could have major influence on a service used by millions (and make respectable money doing so).

It was only a matter of time before that changed, of course. I’ve often said that being in the Twitter client business is like participating in a Darwinian UI design competition, in which the most successful ideas are adopted and encoded into Twitter’s DNA by successive generations of clients while weaker ones wither away. In many ways, the recent release of “New Twitter” represents the endpoint of this process and the beginning of Twitter’s more active role in shaping its own destiny—the “twingularity” if you will (sorry, I went there).

Does this mean that there’s no longer room for third party Twitter clients? My suspicion is that people will continue to make them, but it seems to me that they’re already on the road to becoming increasingly uniform and commoditized as the Twitter experience is more sharply defined by Twitter itself (as my Birdfeed collaborator Neven Mrgan has suggested to me, Twitter clients are going the way of email clients). I also suspect that the inherent downward price pressure in the Twitter client market, which already made it very difficult for me to build a viable indie software business when Birdfeed was on the market, is only going to be more intense now that Twitter has its own formidable (and free) client offerings.

That said, I can’t deny that I still feel the (perhaps masochistic) urge to work on a Twitter client from time to time. Twitter’s product direction these days is so bold that it’s hard to resist the impulse to question it occasionally. And, despite the fact that client innovation has more or less plateaued, today’s Twitter API is more robust and full-featured than ever. Perhaps these factors will be enough to keep the great evolutionary UI experiment alive, if only among the armchair product designers of the world.