Not sure if this would break some TOS or something but can't a native app just continue asking you for your username and password and just do this oath stuff in an offscreen webview, making it seem just like with xauth? It's almost disingenuous to show an in app browser with oath and confuse the user into thinking he has the same sort of "same origin" security as oath in the browser -- he doesn't, that webview is completely controlled by the app and thus offers no additional security over xauth whatsoever.
About 3 years ago I was working for an internal team at eBay to create an app for their end users. Their api uses OAuth for all public resources. Instead of going through the pain of getting access to private apis, we just built the app on top of the public apis. Being perceived as a normal eBay product though we didn't want end users going through the Oauth process so we just processed the flow in a hidden webview. It was the path of least resistance that still allowed us to look official.
From a technical perspective, what you're talking about is something that would be very brittle and liable to break because of changes Twitter make to their login pages.
It's also relying on functionality that may be treated in the future as an attack vector and locked down by either Apple or Twitter. e.g. like the changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-unders, etc.
Everything you are describing being "locked down" happened within the context of the browser world, not to webviews you control. Again, once you are in control of the webview you can do anything. Think of this way: you could just implement your own HTML renderer, at which point, once again, nothing anyone builds in will matter. In fact, why bother embedding a webview at all? Depending on how they implemented the login, simply download the HTML source code as plaintext, then issue the post of the form yourself -- no browser required. Each of these is slightly more abstracted, but you get the idea.
I agree with your point that this may be brittle, but that's kind of the point I'm making -- you're getting zero new security benefits out of it and introducing the possibility that many apps use a worse technique to get what they want done. Also, if you are just manually filling out a form I wouldn't worry about brittleness too much, you're just looking for two text fields and then submitting whatever form contains them yourself. Unless Twitter actively starts trying to create fake form elements or something I doubt anything would break, and even then, is this really what Twitter wants to get in the business of building, tricky forms to swat third party apps?
