On August 16, Twitter shuttered two legacy APIs that it had announced would be removed earlier this year. Developers of a number of popular third-party Twitter clients warned that the shutdown of the User Streams and Site Streams APIs would negatively affect users of their apps and, as a #BreakingMyTwitter backlash evidences, it turns out they were right.
One app, Tweetbot for iOS, for instance, no longer supports automatic timeline refreshing, and push notifications for events such as likes and follows, have been removed. Tweetbot’s maker, Tapbots, removed its Twitter client app for Apple Watch entirely.
While the company hopes to be able to restore some of the lost functionality, it says that its hands are tied because “Twitter has chosen not to provide alternatives to these interfaces.”
That has developers and users of their apps asking: what gives Twitter? Why has Twitter – whose CEO publicly apologized and committed to rebuilding its already-tortured relationship with developers several years ago – moved forward with cutting off APIs that popular apps depend on?
A leaked internal email from Rob Johnson, Twitter’s Senior Director of Data Enterprise Solutions, explained:
Today, we are facing technical and business constraints we can’t ignore. The User Streams and Site Streams APIs that serve core functions of many of these clients have been in a “beta” state for more than 9 years, and are built on a technology stack we no longer support. We’re not changing our rules, or setting out to “kill” 3rd party clients; but we are killing, out of operational necessity, some of the legacy APIs that power some features of those clients. And it has not been a realistic option for us today to invest in building a totally new service to replace these APIs, which are used by less than 1% of Twitter developers.
Johnson stated that “we check out #BreakingMyTwitter quite often and have spoken with many of the developers of major 3rd party clients to understand their needs and concerns” but made it clear that while “change is hard”, Twitter has no intentions of reversing course.
In an official public statement, Johnson wrote:
We feel the best Twitter experience we can provide today is through our owned and operated Twitter for iOS and Android apps, as well as desktop and mobile twitter.com. We’ve long believed this — we’ve focused on delivering the best experience for our apps and sites for years.
He listed a number of features that are present in Twitter’s official clients, and noted that “many of [them] are only possible in a Twitter-owned app.”
But if Twitter’s first-party clients are so great, why are third-party apps still so popular, and why is #BreakingMyTwitter a thing?
One of the most interesting statements in Johnson’s email was this:
We’re committed to understanding why people hire 3rd party clients over our own apps.
Some critics believe that Twitter’s decision to remove the User Streams and Site Streams APIs was less about the technical burdens of maintaining legacy APIs and more about forcing users to use its own clients, which, unlike third-party clients, it can fully monetize.
The single sentence above seems to lend credence to the critics’ belief. After all, Twitter appears to know that many of its users, particularly power users, prefer to interact with its platform via third-party clients, and it clearly hasn’t yet figured out why. But even so, it still decided to implement changes that will leave those users without apps that meet their preferences and needs.
In both his internal email and public post, Twitter’s Johnson noted that only 1% of third-party developers were using the User Streams and Site Streams APIs. However, given that the developers using these APIs were among the most prominent members of the company’s ecosystem, it would appear that Twitter was intent on breaking up with them, backlash be damned.
The big question now is how those developers, as well as the ones who weren’t affected this time around, will respond. Will developers continue trying to create meaningful apps using Twitter’s APIs, or is Twitter’s developer ecosystem dying a slow, intentional death?