Twitter May Buy TweetDeck for $50M

Twitter is apparently working on plans to buy TweetDeck, the Adobe AIR-based Twitter client. Negotiations are allegedly in the advanced stages, and could cost Twitter about US$50 million dollars.

News of the deal comes via unnamed sources, according to the Wall Street Journal, but they didn’t have any information on what Twitter would do with TweetDeck should both sides agree on terms.

Twitter is a microblogging-like service where users share thoughts and comments in 140 characters or less. The company offers its own Web-based interface, as well as iPhone and iPad client apps. Buying TweetDeck could lead to new features in the company’s client tools.

Both companies are keeping quiet on the deal, so there isn’t any word yet on whether or not they’ll reach an agreement, or on what TweetDeck’s fate will be should the purchase come through.

A very, very interesting aside there. The commentariat is quick to poo-poo my contention that Flash is quickly becoming the de facto API for mobile precisely because it’s write-once-deploy-many and it makes programming more accessible to a broader range of contributors. It also does everything needed for a good 90+% of apps, including Internet sockets so RESTfil APIs like Twitter can be implemented in a straight-forward manner.

So, I will ask… What native iOS apps are getting $20M and $50M bids from potential suitors? How long do you think it is until the only developers building iOS apps with XCode are “fanboys” and those who need absolute best performance (and willing to pay the extra development cost for it), while most apps are built with Flash/AIR?

Google’s developers are most definitely doing native apps of the Java or C++ variety. And that makes a lot of sense for Google as platform vendor and for the kind of performance it needs to squeeze out of Maps, Navigation, etc.

The reason to choose Flash/AIR for an app like TweetDeck is that you can deploy it on multiple phone platforms, multiple tablet platforms, the 3 major desktop platforms as “not bad” desktop applications, and inside the browser. From one source base and with potentially more involvement in the coding from designers and artsy types.

The downside of AIR on iOS is that Apple insists that each developer package the AIR library separately rather than use a shared library. So you have larger apps and more complicated updates than platforms where AIR is welcomed with open arms. As Apple is going to lose the “control” it wants over APIs anyway, you’d think they’d just try to keep it easier and safer for its customers.