I suppose some will think this means more competition for Apple. But if this tool works well, it more likely means that developers will develop for iPhone first, since that is the biggest single market, and then port their apps to other platforms.

(Yes, I know there are more Droid phones out there than iPhones. But there are more iPhones out there than any single Droid manufacturer/brand/model name.)

And I believe there are more iOS devices out there (which all run most of the same apps) than Android devices. Certainly the share of Internet usage is skewed toward iOS and not Android.

Data showing the Android market > iOS market requires artificially combining many incompatible devices into one total that is a platform in name only. While artificially subtracting huge segments of the iOS market: the iPad and iPod Touch. (And it often means looking only at the US market, where iPhone is on just one carrierfor nowwhile Android devices are on sale or given away by multiple carriers... who all have different rules about what your open Android device can do.)

(As for full Internetthats neat but its not really what I want from a TV. Games and media, yes, browsing and communication, no. I have a computer and a phone that do those tasks better than any remote control.)

Well I do believe it is fair game for Apple to expand it's CPU options for it's entire Mac line with AMD.

"Apple's custom A4 processor, which employs a CPU and GPU from ARM, is found in the iPad, iPhone 4, fourth-generation iPod touch, and Apple TV. The new Apple TV in particular was a setback for Intel, as previous versions of the set top box had been based on an Intel processor.

In September, Intel CEO Paul Otellini called the Apple TV redesign a "step backward" while highlighting Intel's partnership with Google on the Google TV platform. Otellini touted Google TV as having the "full internet," unlike Apple TV or the iPhone."

Very interesting indeed.

Let's see...

1. Design and generate the source for the UI with Interface Builder.
2. Translate the IB source to some other language / Framework.
3. Extract the application specific code and translate that as well.

... and Voila

Although other frameworks are missing many of Apple's features...
And Apple could cause problems for Intel if they want to...
Apple frameworks are so well defined and the Apple tools so nice that it might actually be worth it.

Time will tell.

Creating a tool for converting from iPhone to Intel doesn't make much sense. Apps are written for Cocoa Touch, but that framework only exist on Apple devices. Apps aren't written for ARM specifically. Only when Xcode builds the app, is the ARM compiled code produced. (Ironically, the iPhone simulator is in fact running apps with Intel compiled code).

So what should this tool do anyway?

It's a true testament to apple's vision and hard work that we've reached this point that the giant intel in courting iphone developers. Three and a half years ago when that fat f.ck from ms was laughing about the iphone, even some of us who could see the tremendous potential of the platform, we couldn't have thought that things would go this far.

They'll probably charge some ridiculous amount for it. They have always ended any hope of adoption of their tools and consequently the targeted platforms by doing that. They used to have some insanely good optimizing compilers for PPC that small developers had no chance of being able to afford. Assuming the goal of those was to encourage the adoption of PPC, they failed utterly. I predict the same fate for these tools and maybe even the underlying platform if they treat the tools as a profit center.

Surely this "tool" which makes it sound like it's a simple job of using it and your done etc, it nothing more than a compiler or compiler extention (sorry, I'm no real developer) to recompile into x86? Simple I would imagine. I would imagine that the hard part is all the iOS API calls which they will have to reverse engineer, or get people to drop and write code without them, or use a generic set of new Intel API calls which would then work anywhere - sort of the oppsite of what Apple want their developers to do...

My guess is that it's not going to be that sophisticated - it's largely going to be something that will identify 'unportable' C and C++ constructs - something that good OS X developers should already be avoiding to keep code portable between PPC and Intel and re-usable on iOS.

It might also include an Obj-C runtime ported to run on Intel (there are at least two out there that run on Linux. GnuStep also includes at least some level of Cocoa compatibility, but not full iOS compatibility, and with the commercial backing that it has lacked so far, it might actually catch up).

Consider that a lot of iOS games, for instance, are 90% C++ and OpenGL, with a thin amount of ObjC and Cocoa around the edge. That's one reason games companies have been able to port console titles over.
Even with more Cocoa Touch oriented apps, for many apps there is likely to be a common core of portable code.

The exceptions - the applications almost wholly based around exploiting distinctive, non-portable APIs like CoreAnimation, are a pretty small number.

However, the big question is who is going to need it - the only thing I can really see that Intel can bring to the tablet space is Windows compatibility. That's going to be important to some businesses that have heavily locked themselves into MS technology, but they're not going to buy MeeGo devices. As soon as you remove Windows from the picture, then why would you choose MeeGo over iOS, Android, ChromeOS, Nokia's Linux or Blackberry's vapourware tablet?

It strikes me as a product that missed it's opportunity - which was pre-Android, pre-iPad, when there was a noticeable performance gap between ARM devices and Intel ones, but when there was also a definite need for something more efficient than Windows - you know, back before your phone could record & encode HD video, and Windows 7 did a lot to improve its power efficiency.