TwitterKit doesn't seem to support read-only apps very well



While I’ve always applauded the fact that Twitter’s authorization model provides the ability to define apps that only require read access to a user’s account, that scenario doesn’t seem to be very well supported in TwitterKit.

While you can access the details of user sessions, it’s not possible to tell what level of access is associated with that session without making a separate network call and observing its response headers. It would be really nice if this information could be captured from the login flow and stored with the session.

The Like buttons that appears in several places seem to be smart enough to begin a login flow if the user attempts to use them while not authenticated. But if the token obtained grants only read access, things kind of fall apart: the button state animates to on, and a network request is sent that will log to the console but silently fail when it gets back a 401 from the API. At some point the button will revert to its off state. Ideally, the button should be disabled/not visible if it can’t perform as advertised, or at least the failure should be surfaced to the user.

The TWTRComposerViewController reports the auth failure to its delegate, but it would be better to prevent the user from even trying to compose the tweet if sending it can never succeed. (The burden of reporting the problem to the user is also left entirely to the host app: if not handled correctly, it just looks to the user like pushing the Tweet button didn’t do anything.)


Great feedback and ideas - we will be sure to pass this along to the Twitter Kit developers!


I just realized that the situation with composing tweets is worse than I’d thought: TWTRComposerViewController is only intended for the app card use case.

When using TWTRComposer to give the user a composition UI, there’s no reported failure at all. Not in any of the TwitterKit-provided UIs, and not in the TWTRComposerCompletion block. The user’s attempt to post just silently fails, with no apparent way for our app to detect or recover from the situation. (And I’m pretty sure we’re the ones they’ll be mad at.)