Hi Matt,

I understand the change need to happen. In regards to xAuth though and 
finding an upgrade path, the assumption is that those that got access to 
that were developing desktop/mobile clients (not centralized services) so 
there is no centralized storage of tokens or user data (only in standalone 
applications in those applications). In a good number of the high profile 
applications of xAuth, it's an actual client (like TweetBot, Seesmic, 
Tweetdeck, etc). Those clients almost always interface with direct messages 
because they replicate most of the twitter features up and down. 

In that case, can you please reconsider the case of xAuth. Grandfather 
existing xAuth users to read, write, and direct message level. Then going 
forward with xAuth, evaluate the need of the app if it needs 
read/write/direct message on a case by case basis? You are going to break a 
good number of applications with that change. 

Although a month is just barely enough time to turn around an update for iOS 
if developers rush, it doesn't leave a lot of grace time for users that do 
not upgrade their applications very often. My own stats for my apps show 
without sending out notifications to nag the users to tell of an update (or 
force them to an update by sending them to the store when they launch the 
app), nearly half my users do not upgrade for at least 2 to 3 weeks after an 
update comes out. 

I hate to bring up comparisons to facebook, but they give us a good 
developer roadmap (http://developers.facebook.com/roadmap/ ) with a decent 
time line for deprecation, ramp downs, and migration paths.   

Zac 

-- 
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
https://groups.google.com/forum/#!forum/twitter-development-talk

Reply via email to