Apple’s insistence on XCode for iPhone OS apps not about Adobe, but switching chip architectures?

“This week Apple confined developers to a specific set of tools (XCode),” Steve Cheney blogs for steve’s blog. “A lot of people think this is to kill Adobe Flash. Sure, that is a tactical reason, but there are much broader strategic reasons. By telling developers to move to XCode tools, Apple is setting the stage to potentially switch architectures.

“History often repeats itself: In 2003, Apple advised developers to switch to XCode tools,” Cheney writes. “This was not a coincidental move—2 years later Apple moved to Intel across its entire Mac line. Developers who complied could simply press a button and applications would run natively (full performance) on new Intel Macs.”

“Now consider this – Apple may have already switched without people knowing. Here’s an anecdote – the innards of Apple’s A4 (powers the iPad) have been speculated ad nauseum by experts, but the reality is no one knows what’s actually inside. This week, there was very surprising analysis that the A4’s die size far exceeds what it ‘should’ be (single core ARM Cortex A8 with a 64 bit memory bus and GPU).

“This analysis is not yet mainstream, but will add tremendous fuel to the fire that perhaps the A4 is NOT an ARM architecture,” Cheney writes. “In fact, it’s highly possible that the A4 is a dual core Power Architecture, which is what the PA Semi team worked with, prior to Apple buying them in 2007.”

If this is indeed the case, then iPhone OS 4.0 would bring incredible speed improvements to the iPad, since it would no longer run applications on an ARM processor emulator,” Cheney writes. “Can you imagine if OS 4.0 improved the iPad’s speed by 50% on day 1? Apple would be heralded as a software God. But in order for these speed improvements to be realized, apps would need to be written in objective C—which is exactly what Apple is now telling developers to do.”

Cheney writes, “We will likely find out what’s really inside the A4 soon. But one thing is already clear: Apple is sowing the groundwork to make architecture changes seamless—developers will only need to flip a switch to give their apps blazing, native performance… I find it fascinating that Apple has been so good at diverting attention to the Flash argument, that people don’t see the true genius behind Steve Jobs’ vision…”

Full article – recommended – here.

[Thanks to MacDailyNews Readers “Jack” and “jax44” for the heads up.]


  1. It’s amazing how Apple surprises the world, and blindsides the rest of the tech industry, seemingly on a daily basis. It’s a bit mind-boggling just how far ahead the company thinks, prepares and then actually releases all this stuff.

    It would interesting (to say the least!) to have a little peek at Apple’s road map for the next 3 to 5 years.

  2. The irony is
    that objective-c / cocoa is relatively easy to code, as programming languages go. The fact that Adobe is so slow in embracing it is a testament to their laziness.

  3. When I read the full article and the comments on that site, I am starting to wonder how accurate this theory really is. There are some pretty smart people commenting over there.

  4. My sense is that Apple has had a long-term strategic plan in place for quite some time now, whereas the

    Adobes and MSs of the world are staring at the puck as it sits on the ice awaiting a face-off…or something

    like that.

  5. I am by NO MEANS knowledgeable about processor construction, but when they say that the PA Semi’s chips were based on Power Architecture, does that mean Power PC? If so, I thought that those were bad for mobile. Isn’t that why Apple switched to Intel? Because the future was laptops, performance per watt was much more important, and the Power PC road map wasn’t heading in that direction. That was only 2005, right? So how the hell could Apple be squeezing 10 hours out of a dual core Power PC chip now?

  6. I don’t know what development tool has Adobe been using, but whatever it is, it obviously isn’t XCode. Migration from one tool to another would mean completely re-coding the entire CS package, from the ground up. There would probably be some copy/pasting, but most would have to be re-engineered, because there are surely a lot of differences between the tool sets, which somehow have to be overcome.

    Adobe simply does NOT have that many engineers in their Mac group that could do this. More importantly, the current tool of their choice is more than likely chosen for easier porting from Windows, and not for efficiency on Mac. Adobe wants to stay dual-platform, and for that reason alone, they will stick to whatever development tool they’re using, until Apple eventually makes it impossible for them to stay.

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.