One of the developer-hostile aspects to Twitter’s announcement of upcoming changes in the 1.1 release of their API, is the imposition of new “user token limits.” Developers of traditional client applications will be limited to 100K tokens, or twice the number currently issued, for apps that already have more than 100K. What’s a user token? It gives a person like you or who downloads the app the ability to actually connect to and work with your Twitter account data. No token? No service.

Suddenly the total number of users any Twitter client developer can expect to support has a hard limit. Limited resources tend to rise in value, and we’re already seeing that play out in the client market. On a recent episode of Core Intuition, we welcomed Twitterrific developer Craig Hockenberry, who spoke candidly about the changes. During the episode, he pointed out that the ad-supported, “freemium” model adopted by Iconfactory and many other developers, may not survive this transition.

Tapbots, the developers of the popular Tweetbot client, announced today that they have pulled their Tweetbot alpha release for Mac, citing the new user token limitations. While exposure to a large number of users is undoubtedly good for testing and promotional purposes, they don’t anticipate it being worth the potential cost in “lost tokens.”

Matthew Panzarino of The Next Web reported on the Tweetbot news, taking care to emphasize that because user tokens don’t expire on any regular schedule, they can be used up even by users who download a client once, connect, and never launch the app again. The total number of oustanding user tokens doesn’t go down unless users log in to Twitter and explicitly revoke access to the client application.

During our conversation on Core Intuition, I pointed out that Twitter’s new policy runs the risk of invoking Apple’s ire, as well. Apple’s App Stores for Mac and iOS are host to dozens if not hundreds of Twitter API clients, many of which meet Twitter’s criteria for “traditional clients.” When a particular app reaches its 100K token limit, what happens to the user who purchases the app from Apple’s App Store a second later? I suppose it will be up to developers to anticipate their proximity to 100K, and start winding down the operation (and their business) by removing the app from the store, etc. But if they don’t? Apple’s just sold an app that, through no fault of theirs or the developers, is useless for connecting to the service it’s meant to support.

A Token Degree Of Control

It’s bad enough that clients will have to contend with a hard limit of 100K active users per application, but what must be particularly infuriating to developers is the knowledge that some of those 100K tokens may not have been used for years, and may never be used again.

The Tapbots announcement included an overt request that users of any Twitter clients should “help 3rd party developers out” and revoke any tokens that you’re not using. This underscores the doubly subservient position developers have been put in by this move: Twitter imposes a hard limit on the number of user tokens, only end-users can free up previously used tokens, and developers, helpless to address any of this on a meaningful level, are left to suffer the worst of the consequences.

At a minimum, Twitter should support developer-driven token expiration. Google, for example, supports an API endpoint for revoking OAuth 1.0 or 2.0 tokens. This gives developers the ability to improve the user’s experience when revoking a token makes most sense: e.g. if a user has opted to “Uninstall” an application. But it also provides some discretion and flexibility for the developer to revoke in other scenarios where it makes sense. A scenario such as the one Twitter is imposing, for example.

With the ability to programmatically revoke tokens, the particulars of doing so would be up to developers. For example, if I were the developer of a 3rd party client such as Twitterrific or Tweetbot, I might arrange for the client application to communicate token usage data to a centralized server. This would theoretically give me the ability to say “expire any user tokens that haven’t been used within the past year” and rest assured that I’ve freed up a bunch of tokens without inadvertenly inconveniencing an active user.

There are security issues at play here, and the unfortunate potential to seriously inconvenience an active user if a user token is revoked prematurely. But given the hard limits being imposed by Twitter, some hard coping mechanisms are due to developers. Tokens are precious, limited resource, and neither users nor developers can take them for granted any longer.