The built-in framework kind of gives you a “virtual” application identity as communicated to Twitter through iOS, without having to explicitly create an application record on dev.twitter.com/apps for your app. Apps created and accessed this way can have read-only or read-write access used, but not RW+DM (with direct message reads).
If you register an app on dev.twitter.com/apps, you can specify a permission level that includes direct message read capabilities, but in order to get a user to grant your application that permission, they need to a screen that makes this clear to them. So to secure that permission, you need to use OAuth 1.0A’s flow, resulting in a web browser view that obtains the user’s explicit permission.
Reverse auth bridges the gap between the virtual application on iOS and the real app you’ve registered on dev.twitter.com. It allows you to transit an access token from the virtual app instance to your “real” app – mostly so you can make use of the access token on a server or other use case.
Ultimately, if you’re going to work with direct messages, you need to use OAuth 1.0A and callback-based redirects to secure that permission.
