Twitter’s API changes went live today, disabling key features for third-party apps like Tweetbot and Twitterific.
The new API removes timeline streaming, preventing third-party apps from refreshing timelines automatically, and it limits push notifications and other features. Twitter is also charging exorbitant fees for access to its new activity APIs, with access starting at $2,899 per month for up to 250 accounts.
All third-party Twitter apps are affected by these changes. Tapbots yesterday updated the Tweetbot for iOS app to cripple multiple features popular with Tweetbot users. Timeline streaming over Wi-Fi is no longer available, for example, which means Twitter timelines will now refresh more slowly.
Push notifications for Mentions and Direct Messages are delayed by several minutes, and push notifications for likes, retweets, follows, and quotes have been disabled entirely. The Activity and Stats tabs, which were reliant on now-deprecated activity APIs, have been removed from the app, and because the Apple Watch app was heavily dependent on Activity data, it too has been eliminated.
Similar changes were introduced in Twitterrific in July, and as of today, the Twitterrific app is no longer able to receive and display native notifications. Twitterrific’s Today center widget and Apple Watch app relied on these features, and have been removed.
Twitterrific recommends Twitter users download the official Twitter app to receive their notifications, while using the Twitterrific app for everything else.
As the changes went live, Twitter today sent out a company-wide email to employees that starts out by acknowledging the huge impact that third-party Twitter clients have had on growing the Twitter service before pointing towards “technical and business constraints” that prevent it from continuing to offer the APIs necessary to keep these apps working as before.
Today, we will be publishing a blog post about our priorities for investing in Twitter client experiences. I wanted to share some insight into how we reached these decisions and how we’re thinking about 3rd party clients moving forward.
First, some history: 3rd party clients have had a notable impact on the Twitter service and the products we built. Independent developers built the first Twitter client for Mac and the first native app for iPhone. These clients pioneered product features we all know and love about Twitter such as mute, the pull-to-refresh gesture, and many more.
We love that developers build experiences on our APIs to push our service, technology, and the public conversation forward. We deeply respect the time, energy, and passion they’ve put into building amazing things using Twitter.
However, we haven’t always done a good job of being straightforward with developers about the decisions we make regarding 3rd party clients. In 2011, we told developers (in an email) not to build apps that mimic the core Twitter experience. In 2012, we announced changes to our developer policies intended to make these limitations clearer by capping the number of users allowed for a 3rd party client. And, in the years following those announcements, we’ve told developers repeatedly that our roadmap for our APIs does not prioritize client use cases — even as we’ve continued to maintain a couple specific APIs used heavily by these clients and quietly granted user cap exceptions to the clients that needed them.
It’s time to make the hard decision to end support for these legacy APIs — acknowledging that some aspects of these apps would be degraded as a result. 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. In addition, it hasn’t been realistic for us to invest in building a totally new service to replace all of the functionality of these APIs, which are used by less than 1% of Twitter developers.
We’ve heard feedback from our customers about the pain this causes. We review #BreakingMyTwitter quite often and have spoken with many of the developers of major 3rd party clients to understand their needs and concerns. We’re committed to understanding why people hire 3rd party clients over our own apps, and we’re going to try to do better with communicating these changes honestly and clearly to developers.
We know we have a lot of work to do. This change is a hard, but important step forward. Thank you for working with us to get there.
Twitter has continually said that just 1 percent of Twitter developers use its now-deprecated APIs, but as these changes seem to impact most of the major Twitter clients, it’s not clear how the 1 percent figure is being calculated.
As TechCrunch points out, Twitter’s email insists that the APIs were “legacy technology” that needed to be eliminated for “operational necessity,” but it’s Twitter, not an outside force, that has refused to maintain or redevelop the APIs third-party apps are using or transition existing apps over to the new API platform.
The sad thing is they did build a service to replace most of this, they just priced access to it so high that it might as well not exist. pic.twitter.com/ylfG6lHbQp
— Paul Haddad (@tapbot_paul) August 16, 2018
Twitter has further explained its decision to remove the APIs in a blog post that says the “best Twitter experience” it can provide is through its own “owned and operated Twitter for iOS and Android apps, as well as desktop and mobile twitter.com.”
Tags: Twitter, Tweetbot, Twitterrific
Discuss this article in our forums
