In April of this year, Twitter announced that it was making changes to its available APIs, which meant that third-party apps would be impacted the most in a handful of ways.

Now, months later, we are finally seeing the results of those changes on Twitter’s end. That includes the loss of many features for third-party apps like Twitterrific and Tweetbot. Twitterrific disabled those features, including relevant push notifications, streaming timeline, and more, back in June. Taptbots, the developers behind the popular Twitter app Tweetbot, disabled these features or severely downgraded them just this week — at the same time as Twitter’s API changes went into effect.

Now, Twitter has posted a public blog post to talk about those changes, and try to go into some detail as to the reasoning. In the post, Twitter notes that its API changes are tied to legacy developer tools, and those apparently only effect “1% of third-party developers”:

“In order to prioritize making these experiences great, we’ve chosen to stop investing in other products — including two legacy developer tools used by about 1% of third-party developers. This means that some Twitter-like apps will not be able to function the exact same way as before. For example, instead of Tweets automatically streaming in like they once did in some third-party apps, you might need to pull to refresh like you do in Twitter-owned apps and sites. Several of the most popular apps have already made updates so that you can continue using them with minimal disruption.”

Twitter’s official blog post is pretty straightforward in its approach, talking about how it basically wants the best possible experience on the social network to be available on its owned products, whether that’s the iOS app, Android app, or Twitter’s website.

However, TechCrunch has posted an internal email that was sent out to the Twitter team recently, and it’s a bit more open in its reasoning. Twitter does admit that it hasn’t been exactly great at talking to third-party app developers, and it also points out that the company has basically been working towards this end since 2011. You can read the full email below.

“Hi team,

Today, we’re publishing a blog post about our priorities for where we’re investing today in Twitter client experiences. I wanted to share some more with you about how we reached these decisions, and how we’re thinking about 3rd party clients specifically.

First, some history:

3rd party clients have had a notable impact on the Twitter service and the products we build. 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, like mute, the pull-to-refresh gesture, and 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.

But 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 is now 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. 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.

We’ve heard the feedback from our customers about the pain this causes. 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. 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 have a lot of work to do. This change is a hard, but important step, towards doing it. Thank you for working with us to get there.

Thanks,

Rob”

Our Take

That internal email probably wouldn’t make a great public blog post on the matter, but it is at least good to see that the company is being a bit more open behind-the-scenes, and, hopefully, that means more transparency between it and third-party developers will actually happen.

Are you still planning on a third-party Twitter app as your daily driver? If so, which one?