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