I can't has cheezburger

When Twitter announced a few months ago something along the lines of “hey, I know that almost all innovation for new features for Twitter’s user experience have come from third party developers, and we wouldn’t even have our own native Twitter clients if it weren’t for an acquisition of third party clients, but now that we are making native Twitter apps, we’ve got this now, so, um, please stop doing it” I was a bit pissed because Twitter is ignoring obvious facts.  Despite the fact that 90% of its users using a native Twitter app were using Twitter’s own offerings, what Twitter failed ot mention is that that other 10% was responsible for something to the tune of half of Twitter activity (a.k.a. the most engaged Twitter users don’t use Twitter’s own apps).  I am okay with a company wanting great levels of control over its user experience (see my gigantic collection of Apple gear), but I’m certainly not okay with it if said company pretty much drops the ball every time it comes to making a good, integrated user experience.

But I’m not here to bitch about Twitter. Developers who develop on Twitter’s platform are doing that readily, and that’s who I’m here to bitch about.  I’m talking about the developers who were bitching about the fact that Twitter made changes to OAuth authentication in a way that required Twitter apps to get re-authenticated to keep functioning.  In this case, a third permission was added (access to DMs) because Twitter heard that users wanted more granular control over whether an app had access to such information.

This was a simple enough change, but developers were all up in arms about the fact that Twitter made them make this change and the change was told to them with only 13 days’ notice, which didn’t give them enough time to prepare their users for the transition.  I asked one developer who was bitching about a user bitching that his third party Twitter app was still broken as though it was the Twitter app’s fault, and I asked the guy, “what did your app actually do to inform users about the transition?” Mind you, not random things the dev posted on his personal Twitter account or even the Twitter Client’s official Twitter account, but how did information about the change get relayed to the user WITHIN the app?

His response? “Nothing.”

When I asked why not, he explained that there wasn’t a system in place to do that; it had been on the back burner for some time.

(warning: begin rant)

So, apparently developing a freaking system to check something as simple as an RSS feed of announcements on a developer’s web site occasionally to fucking TELL the user that changes might happen to Twitter’s API soon requiring changes to be made was not important enough to implement for months, but when it’s actually needed, suddenly it’s all Twitter’s fault that they didn’t give devs a few months’ notice to implement this system.

First off, if you rely on a third party API that can change at any time, you need to be as resilient as possible. You wrote your damn app, you have total control over it. If you’re a reputable OS X/iOS developer you should be bright enough to know that your users aren’t going to be happy with your app breaking without warning the user first, and there should absolutely be a system in place for letting the user know what’s going to happen from day one.  If you lacked the foresight to do this, that’s your problem, not Twitter’s.

Secondly, this is Twitter’s API, not yours. They put the work into making this API, and they put the work into making the plumbing that makes Twitter work (with or without the fail whale).  They can make changes whenever they want; it’s their API, motherfuckers. It’s entirely likely that at some point, there may be a critical security flaw discovered in Twitter’s OAuth that can only be fixed by revoking all access keys tomorrow and requiring Twitter clients to re-authenticate. You can’t reasonably expect Twitter to wait a month for you to develop a workflow to make this easy for your user, then get it approved in the App Store; they need to make that change ASAP.

Finally, this isn’t the first time you’ve dealt with a condition on Twitter that affected your client. Twitter was once known for having legandary amounts of downtime; sometimes daily.  Once Twitter implemented an API call limit to mitigate high demand. These are all conditions you want your app to tell you about before seeing a cryptic NSURLDomain error on your screen. If your user sees the latter, they’re inclined to believe something about your Twitter client is broken. If they saw a message beforehand mentioning that Twitter was experiencing downtime, then they know it’s all good.

Twitter may not have the best track record with developer relations, but developers, you need to STFU on this one.  Not a single Twitter app that I’m aware of properly made any in-app warnings to users about the changes coming to Twitter. Not one. But developers sure complained that Twitter’s official app didn’t have this disadvantage.  Yeah, no shit! There’s no reason to expect Twitter to add extra authentication to its own Twitter clients just because.

Developers: find something else to bitch about Twitter about! there are plenty of things.

Peace out. Namaste.