That is not to say I didn’t have some qualms with Twitterrific 3 & 4. As I alluded to earlier, I am a fan of simplicity. However, Twitterrific remained very bare bones compared to other apps, something I enjoyed. It had the same feature set as the iPad app did, and cautiously returned features as needed. Then Twitterrific 3 (and 4, since 4 was really an evolution of 3) came to the iPhone, actually being an update to the iPad app. Where version 2 had feature overflow, Twitterrific for iPad went back to the bare minimum. They took the opportunity afforded to them by the short time to develop the app to strip Twitterrific back to basics. When the iPad came out, The Iconfactory was again first to have an app out for the new device. However, it suffered from feature creep and interface bloat. It packed in just about every feature that could be thought of but the kitchen sink. That is why Twitterrific 2 was a little surprising. I have always admired The Iconfactory for their attention to simplicity. The initial iOS app was a basic way to read, tweet, and reply, just like its big brother on the Mac. Twitterrific for iOS was my first app downloaded from the App Store as soon as I had purchased my iPhone 3G on launch day in July 2008. While Twitterrific’s roots are on the Mac, it is the iPhone, and later the iPad, where its story really takes flight. ![]() ![]() It started as simple as Twitter itself, and contributed some features back to Twitter that we all take for granted now. For the years that I have been on Twitter there is one app that I have used primarily to interact with the service - Twitterrific. Most of my friends over the past few years, both local and afar, started as acquaintances on Twitter. Thank you for working with us to get there.I love Twitter. This change is a hard, but important step, towards doing it. And we’re going to try to do better with communicating these changes honestly and clearly to developers. We’re committed to understanding why people hire 3rd party clients over our own apps. 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’ve heard the feedback from our customers about the pain this causes. 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’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. 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. Today, we are facing technical and business constraints we can’t ignore. 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. 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. 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. In 2011, we told developers (in an email) not to build apps that mimic the core Twitter experience. ![]() We deeply respect the time, energy, and passion they’ve put into building amazing things using Twitter.īut we haven’t always done a good job of being straightforward with developers about the decisions we make regarding 3rd party clients. We love that developers build experiences on our APIs to push our service, technology, and the public conversation forward. These clients pioneered product features we all know and love about Twitter, like mute, the pull-to-refresh gesture, and more. ![]() Independent developers built the first Twitter client for Mac and the first native app for iPhone. I wanted to share some more with you about how we reached these decisions, and how we’re thinking about 3rd party clients specifically.ģrd party clients have had a notable impact on the Twitter service and the products we build. Today, we’re publishing a blog post about our priorities for where we’re investing today in Twitter client experiences.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |