Much has been made of Microsoft’s failure to shift its dominant presence in the PC market to the mobile market, but at least the company has a real product that actual partners have sold to consumers. Its longtime counterpart in PC hegemony, Intel (NSDQ: INTC), is in even worse shape, and the Intel reference designs making the rounds Wednesday are just the latest in a long line of failed promises from the storied chip-maker regarding its intention to get serious about mobile.
Intel has been showing off reference designs–which are essentially prototypes the company builds for potential partners like those McMansion model homes–related to mobile devices since the middle of the last decade, yet no one has shipped a mobile device in any kind of real volume bearing one of Intel’s mobile processors. In advance of CES, where Intel CEO Paul Otellini is scheduled to deliver a keynote address, the company once again showed off prototypes for a smartphone and tablet running Android to Technology Review and promised to have real phones out sometime next year.
There’s nothing wrong with the designs themselves except for the fact that they’ll never become actual products. They are marketing tools designed to persuade the industry that Intel understands how to meet the needs of the modern mobile market.
Yet Intel’s mobile problems have nothing to do with design or vision: a decade ago the company was regularly predicting the types of mobile computers we now take for granted. They have everything to do with software and execution.
There’s a fundamental problem for Intel in mobile. Virtually all software created for modern mobile devices has been designed to run on chips that use the ARM instruction set, making them incompatible with the x86 instruction set that Intel uses in its PC processors and mobile designs. An Android app written for a phone like the Galaxy Nexus won’t necessarily run with acceptable performance on an Android phone with Intel’s chips. Even Microsoft (NSDQ: MSFT) bowed to this inevitability last year, announcing plans to release a version of Windows 8 that runs on ARM processors.
And Intel’s execution problems have not given anyone–handset makers, software developers or design houses–a reason to overcome “platform fatigue” and develop phones and applications for yet another platform. Intel has had an extremely difficult time getting its chips to consume power at the same small levels that ARM chips can hit, which means phone makers would have had to ship bulkier devices with poorer battery life than designs like the iPhone. Apple (NSDQ: AAPL) decided to design and build its own mobile chips rather than work with Intel, which supplies it with chips for the Mac.
The company says that chips based on the current design, code-named Medfield, have finally met that threshold based on its decision to combine the duties of formerly separate chips into a single chip. But as Technology Review points out, Intel still lags companies like Qualcomm (NSDQ: QCOM) when it comes to further integration, which is favored by handset makers because such chips consume less power and are easier to include in tight spaces.
Intel has been “fighting back” and “getting ready to challenge” the threat posed by ARM chips since 2007 with absolutely nothing to show for that talk, which is probably why there has been a revolving door on the office of its mobile leaders.
Until Intel convinces a major smartphone or tablet maker to place a big bet on its Medfield chips with something that can truly compete against top-tier Android phones and the iPhone, it’s safe to ignore “reference designs” and concentrate on the 450 million devices that will have been sold this year without Intel inside. We’ll see what promises Otellini will make this year about mobile in January.
Actually the majority of applications written for Android on ARM will (and do) run just fine on Android w/ x86. The underlying chip architecture is abstracted by Java and Dalvik. There are a number of high-performance applications (e.g. graphics intensive games) that will need to be, at a minimum, recompiled to run on x86.
My understanding was that was only for apps targeted at Ice Cream Sandwich: http://liliputing.com/2011/11/google-android-4-0-optimized-for-intel-arm.html But it’s a fair point and I can clarify that, although I still think that few people will make those optimization without a volume-driven reason to do so.
The liliputing article on ICS is referring to the optimization of Android itself…not the applications created by 3rd party developers.
Volume is less relevant than money. Intel has a lot of the latter. I doubt they will be bashful about handing over some of it to high-profile application developers. Here is one example, written by you: http://paidcontent.org/article/419-intel-dangles-100-million-to-create-intel-friendly-mobile-startups/
Even Intel can’t support mobile development at scale with payola. And that underscores the point, right? If Android developers felt comfortable having their apps run unaltered on x86, there would be no need for Intel to bribe people to make apps optimized for its chips.
Intel doesn’t need to support the development at scale … just enough to get the ball rolling. That’s why I said “high-profile apps” (e.g. Facebook, Twitter, Angry Birds).
I don’t have any real stats to go on, but I would estimate that less than 1% of the apps on the Android market will need to be tweaked to run on x86. Google encourages developers to write apps using their JAVA sdk. When they do so, the apps will run on both platforms. This leaves a VERY small number of significant/high-profile applications that Intel would need to “help” port to x86.
Assuming Intel gets some traction in the next year or two with OEMs(big assumption), the 3rd party developers will have, as you said, “a volume-driven reason” to target both platforms. Time will tell.