steve's blog

thoughts on technology, business and strategy

Search

The Genius in Apple's Vertical Platform

Steve_jobs_think

It’s pretty evident that Apple isn’t wed to individual suppliers. Not only are they back to creating their own chips, but they are also one of the only 'compute' companies to have used each of the top 3 processor architectures over time—ARM, x86, and Power PC.

Apple's DNA in this area is untouchable, helping it to innovate at the confluence of software and hardware. There’s a reason why pinching and zooming on the iPad is snappier than anything people have ever seen, and it’s not entirely clear whether the software or hardware plays the larger part.

When a company decides to vertically integrate, as Apple has done with the iPad, it becomes subject to incredible pressure from outside. For example, how can Apple possibly stay ahead of the entire semiconductor universe, which will sell many more times volume than the iPhone and iPad.

Apple’s commitment to vertically integrate comes with a pressure to accommodate change—they simply can’t commit to one architecture for the long-haul. But changing puts strain on developers, since code must be recompiled and cross-compilers rarely maintain performance. 

This week Apple confined developers to a specific set of tools (XCode). 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. 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. 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. 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.

It’s clear from a strategic perspective that Apple has thought about vertical integration incredibly deeply. Their choice to enter the CPU business was not made lightly, and reflects a platform heritage and an ability to steer developers (afforded by huge network effects). 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 seamlessdevelopers will only need to flip a switch to give their apps blazing, native performance.

This incredible foresight will allow Apple to stay agile and maneuver in the face of what will be unrelenting competition from Intel, Qualcomm, and nVidia. Apple can essentially treat the CPU as a commodity—and this will enable them to continually adjust 'make vs buy' strategies, wield incredible power over suppliers, and build a long-term halo around their platform. 

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 Job’s vision and moves. Apple is setting the stage to become one of the biggest winners in the storied history of vertically integrated companies.

 

47 comments
Apr 14, 2010
Sachin Agarwal said...
Wow, this sounds like something I read recently :)

http://sachin.posterous.com/ie6-caused-the-web-to-mature-slower-than-it-w

Apr 14, 2010
steve cheney said...
great memories think alike :)
Apr 14, 2010
skoon said...
It sounds good in theory, but MonoTouch and Appcellerator both use XCode to compile down to native code. So why outlaw them as well?
Apr 14, 2010
skoon said...
Never mind, Monotouch uses it's own compiler to compile to native code.
Apr 14, 2010
 said...
As an iPhone/iPad developer, I disagree. You say there are problems compiling code for a new architecture, but at least 99% of code compiles equally well on any processor architecture. Developers only have problems when they use processor-specific features like SSE/Altivec/NEON, or when they share data between processors of different endianness - which doesn't apply to ARM/PowerPC, since they are both big-endian.

Also, if the iPad doesn't have an ARM chip, why are all iPad apps (including Apple's) compiled for ARM? It would be trivial to compile them for PowerPC instead. In fact, the iPhone Simulator (part of XCode) works by compiling iPhone apps for x86, then running them natively on the Mac. Emulating all iPad apps would slow down the whole system for no gain at all.

And finally, if Apple wants to move to a new architecture and force everyone to write native apps, why would they emulate for iPad apps at all? Why would they use the licensing agreement to try to enforce this? It would be much simpler for them to use an emulator for iPhone apps only, and add support for the new architecture to XCode. Any 3rd party tools would be incapable of producing apps for the new platform.

Apr 14, 2010
Ryan M said...
Great catch. It would be very impressive if this is the case. Looking forward to see what history brings.
Apr 14, 2010
Jeff Mc said...
Um, the machine debug shows ARM instructions. I would know the difference between PowerPC and ARM when I see it.
Apr 14, 2010
kvfinn said...
This post is incorrect. They are not telling people to use Xcode, they are telling people they can only publish application 'originally written' in Objective C. This is quite different.

If what you conjecture was true they would merely need to require all apps to ultimately be compiled with Xcode. But the language bans many tools that already compile only with Xcode.

For example, it is very common for games to use higher level scripting languages on top of the engine code -- this is a best practice in the industry now (try writing a content heavy RPG without one!). Everything that executes goes through Xcode, and it just looks like Objective C to Apple's tools. But it is prohibited none the less.

Monotouch has it's own compiler but if you want to use Xcode instead, there is a switch to do so.

Apr 14, 2010
kvfinn said...
Unity games also turn C# and whatever other scripting languages you choose to write in into an Xcode project, so likewise they would have no problem with an architecture shift.
Apr 15, 2010
cimota said...
It's not about developers per se, it's about tools vendors. If Apple changes anything - API, processor - it will take time for cross compiler to catch up. 18 months or so for Adobe.
Apr 15, 2010
 said...
There's more to it than this post makes it seem. Indeed, Apple will have less worries about switching architectures. But why prohibit apps from interpreting scripted languages? As long as the interpreter is made with XCode, it ports just like all other apps.
And as to the mystery you think surrounds the Apple A4: It is ARM, it's already been x-rayed and it reveals a quite common Cortex-singlecore and a GPU, the usual SoC. The reason that it's bigger is that they put the memory chips directly on the CPU, for lower latencies and higher speeds.
Apr 15, 2010
 said...
I agree with most of this. Also, I strongly feel that the Apple TV isn't forgotten, and will become ARM based in the next revision, using iPads/iPhones/iPod Touches as controllers for an Apple TV appstore with weather, content, gaming, social networking etc.
Apr 15, 2010
 said...
I'm inclined to doubt this, at least as strongly as is being implied.

Apple's LLVM efforts have really good x86 and ARM support. They also have PowerPC support, but it is showing signs of age. If Apple had a switch-a-roo like this planned, their LLVM efforts would have been more PowerPC centric than they have been to date.

Apr 15, 2010
 said...
William, it isn't the code that is the problem, it's the compiler. If you are using a custom compiler written by MonoTouch to compile code down to ARM executables and Apple suddenly switches to another chip, then your compiler will not compile for that chip even though your code is theoretically portable. If you are using XCode, Apple will push a new compiler the same day the new hardware is announced so you can simply recompile your code on the same day, and you are ready to go.
Apr 15, 2010
 said...
@lazycoder mono touch does both. it can compile and link your app OR it can dump out the obj-c.
Apr 15, 2010
hdon said...
@steve: This article would be compelling if the language of Apple's latest SDK license matched up, but it doesn't. Instead of Apple seeking to move developers to XCode, we have Apple seeking to prevent developers from compiling C/C++/Obj-C code which has been machine-generated from some other source code. If all they cared about was platform portability, compiling in XCode should do the trick. Instead they put a ban on "cross compiling" to C/C++/Obj-C.
Apr 15, 2010
j0sema said...
Interesting theory, but the A4 was indeed xrayd and there was ARM material inside. Also, Apple used to have a Motorola 68000 line ... the original Macintosh, Plus, Se and the MacII had the 68030, 68040 (fx), so they have used FOUR architectures. Cheers.
Josema
Apr 15, 2010
frankenspank said...
@kvfinn

They would never say this, as in order to develop an iphone app, you actually *need* a small amount of straight C.

Apr 15, 2010
throw_away_user said...
you don't seem to understand how a compiler works. the apps that use an intermediate platform (like flash) will work in any platform where flash is ported to without any effort by the developers (they don't even have to "flip a switch", just distribute the same content everywhere).
For the stuff that is compiled, there is no magic in xcode, it just runs a different compiler. Apple only needs to provide an API that is available across all architectures (like POSIX and cocoa).
Nintendo has done this with the GBA -> DS -> DSi path, and it worked fine for them without the need to force any tools on anyone.
Apr 15, 2010
Kreig303 said...
What I'd like to see is Apple move their desktop/laptop line to processors of this ilk.

The Intel transition--viewed from the strategic glance--could have been a way to ensure processor-independence for its OSes... forever.

As a muted non-fan of the Intel transition, it would be nice to see them move away from those overgrown microwave controllers.

--Kreig Zimmerman

Apr 15, 2010
Kreig303 said...
@j0sema:

That is true. Even allowing for the fact that the current MacOS is NeXTSTEP (as the original NeXT OS ran solely on 68xxx).

Apr 15, 2010
 said...
Interesting theory. I'm a Mac developer and have used ObjC since NeXTStep 3.2. I had one of the intel reference machines Apple handed out prior to releasing consumer intel machines. The app I was working on took about two hours to port - a few htons and htonl additions were all I needed to export Photoshop color palettes in my appkit based app.

On the other hand, the guys with legacy powerplant code had major problems with multiple inheritence and apple sent a guy in to help them. Result was a compiler fix.

I can believe you're right about the motivation to force Xcode as it makes any potential major os change minimal, or at least as easy as it can be.

Apr 15, 2010
jbtule said...
By telling developers to move to XCode tools, Apple is setting the stage to potentially switch architectures.

Not really, these other languages are typically doing AOT compilation to get around the interpreted language development clause or just ignoring the interpreted language clause. If it's interpreted (lua) it can switch architectures more easily than OBJ-C code. If it's AOT it's likely using LLVM to do it (flash is, macruby is, monotouch isn't) since LLVM is the same exact backend for xcode apple would use to switch architectures your point seems very unlikely. One of the major features of using one of these other platforms is that it is more portable.

There may indeed be a technical rather than a capricious or tactical reason for the decision. The one thing that every alternative language/platform for for iPhone has that Obj-c/CocoaTouch doesn't is Garbage Collection, while modern garbage collection is pretty good speed wise it uses a lot more memory, it's probably why most alternative smart phones have 2 times the amount of ram as an iPad add multitasking to the mix and those alternative language apps may barely be runnable because of lack of available ram.

Apr 15, 2010
chrisjwowen said...
Erm...this whole thing rests on your assumption the chip is some sort of dual core chip. Pure fantasy. What isn't fantasy is that you've probably got a lot of traffic from this.
Apr 15, 2010
 said...
So I am not a techie in terms of processor architecture but i would like to offer my two cents anyway. If I'm correct the gist of the article is that apple has cleverly disguised a power pc chip as an arm processor? If so can I ask how that makes any sense? Apple dropped support for PPC on OS X but has decided once it dropped support from snow leopard (and apparently the iphone os is a variant of OS X) only to add it back in again a few years later, but curiously decided to drop support to older machines running the same architecture? HUH? This is of course aside from all the compiler stuff I am hearing which I dont pretend to understand, but even to someone not up on all that stuff that this is pretty preposterous...or am i missing something?
Apr 15, 2010
Garry Tan liked this post.
Apr 15, 2010
fluxforge said...
i love apple and all the haters that don't: go and play with lol-linux!
Apr 15, 2010
 said...
Mmmm, no, I think this is just more "apologist" speculation, similar to the tripe about Flash not running on the iPhone because there's no cursor. Personally, I think Steve J is just a pretty awful human being. Might be a visionary, but I wouldn't want to know the guy personally.
Apr 15, 2010
iPadForums said...
Wow great article. Hope you don't mind but I linked to your article here: http://www.ipadforums.net/apple-ipad-news/1843-speculation-a4-powerpc-os4-0-w...
Apr 15, 2010
x x said...
We used each of the top 5 processor architectures over time—6502, M68xxx, ARM, x86, and Power PC! The thing we use now has 128k 6502s with quad M68767s managing them. Runs faster than a pack of lemmings.

Steve

Apr 15, 2010
 said...
Two problems with that theory.

The first is battery life. Compared to x86, sure, the chips that PA Semi were building were nice, low power PPCs. But they're big fat monsters compared to the presumed ARM Cortex A8 everyone (well, those who've paid attention) believes is lurking on the iPad.

Then there's the benchmarks. If you take the iPhone 3GS benchmarks on any CPU-driven task (including JavaScript benchmarks), they scale to pretty much exactly where they ought to be for a 1GHz Cortex A8. I mean, right on, no chance there's even an A9 in there.

The huge die size is probably most easily explained by the claim that there's 256MB of DRAM on-chip. Embedded DRAM is nothing all that new.. it's been in some of the laptop GPUs for awhile now. But it's also not tiny.

Apr 15, 2010
webconomist said...
Perhaps it's just that Apple understands one key thing: People will do more with products that work. That code, to the masses, must be invisible.

Microsoft, Linux etc., all require too much time messing with other things to make one thing work.

Apr 15, 2010
always-learning said...
@j0sema: Lest we forget, the Apple I and II lines also used the 6502, 65C02 and 65C816 processors - that makes FIVE architectures now.

Even the Newton used ARM, so Apple likes to recycle processor architectures every now and again as one gets advantages over the other.

Apr 15, 2010
Don Burnett said...
I have had a newton and many power macs and now an intel mac and I have an iphone..

The poster sounds like a big apple fanboy here.. Why do I say this? Well Apple tightly control over markets (in both the itunes /mp3 market) not to mention controlling how and who makes apps for your device. You are stuck with using Apple's development system for an Apple device, which you can only sell on their store. So you are stuck with their content alliances and capabilities. If you do want content from some other source you are stuck with the speed and offerings of HTML 5.

Is Apple that scared that adobe would take over app development on their platform and it would become the standard for iPhone apps because currently it's installed on 98% of the web browsers out there ?? To many of us who just look at computers as tools (non religiously) that seems like more true motivation.

One thinks so? Genius? Magical? Not for someone who used "Interface Builder" back in oh 1993 to develop apps for NeXTStep and now is using the same tool in Xcode in 2010 and not finding it that much improved..

Not allowing tools like Flash and Monotouch only impedes better content development and a better user experience , but Apple doesn't seem to want it (even if they'd had to approve those apps and their performance)..

This is a very protectionist attitude and it will only serve to Apple's disadvantage with other platforms such as Flash on Android and other competitors not so "in-view" right now.. Also, giving your competitors not as good a user experience on your platform (and yes I am talking HTML 5) as your own alliances and partnership doesn't seem very democratic. I suspect when there are five times as many "Apps" that are more innovative on the Google App Store all done in flash and Apple is losing customers that will change.

I suspect the only reason opera mini is approved was that they knew they'd be facing opposition if they didn't and it renders 5x faster, because of similar litigation with Microsoft.

I really feel they are inappropriately stifling innovation and it's a very monopolistic approach to controlling the market and how people use the device. Some political groups lately have attempted to label less direct tactics "socialistic".

Apr 15, 2010
BrianSHall said...
Really sharp analysis. I re-posted this on my site with the link because several commenters have valid rebuttals, particularly Geerk.
Apr 16, 2010
Kevin Goldsmith said...
I think it is a good point, but I don't think it is the only reason by forcing developers onto an Apple-controlled vertical tool chain. I posted some related thoughts on my blog yesterday (http://blog.kevingoldsmith.com/2010/04/15/section-3-3-1-is-not-new-behaviour-.... Apple has been nudging developers onto their tools for years, but it isn't just the compiler, it is the language. Maybe ObjC was originally picked for some good reason (although I can't think of one), but I think now it is all about locking in developers to the platform. Forcing everybody onto X-Code wouldn't be so bad if it was a good tool. It isn't. It is getting there, but it is years behind other professional-grade IDEs. Forcing developers on to an IDE rampant with bugs and missing features that developers take for granted on other platforms really reduces the attractiveness of developing for that platform.
Apr 16, 2010
 said...
If Apple were only out to "get" Adobe and Flash, they'd take just a fraction of the cash on hand in the war chest, buy the majority stake in Adobe in a hostile take over, and then end the entire Flash problem root and branch by arresting Flash development forever. It'd take about $60 billion dollars of Apple's cash to make Adobe permanently irrelevant.

Marginalizing cross compilers via the license restrictions, no matter who has made the cross compiler, has more to do with Apple wanting to maintain their legendarily strict control over the quality of the end user's experience. Cross compilers with a "develop once, run anywhere" mentality which spit out sterilized machine code, are by their very nature, lowest common denominator code spitters, and they look and act the part by not being optimized for the features of any platform. Apple cherishes its differentiation and polish and Flash doesn't do either, especially for Macs, and also especially not for a multi-touch device, where a Flash SDK toolbox doesn't even yet exist.

As for the cross compiler ban being "monopolistic" evil, good luck with that. Apple only controls about 25% of a narrow, albeit upscale segment of the vast global cellular phone market. There are plenty of smart phone and dumb phone development opportunities outside of Apple's walled garden for those who cannot stand the license change.

The proper analogy is rather like a company such as Mercedes Benz telling actual and potential subcontractors that the company will only henceforth accept proprietary looking and feeling plastics for use in their passenger compartments so that there is not even a question of commoditized looking parts being in their cars and then have the makers of non-complying plastics complaining that M-B will not accept bids for their now unacceptable product.

It's M-B's car to develop and they have a reputation they both wish to protect and enhance which is really of no concern to many vendors outside of the immediate product provider ecosphere. The concern for a corporate image and satisfying direct customer experience is always at odds with the desire of certain third parties to provide goods made as cheaply as possible.

Apple doesn't tolerate cheapness, so lazy runtime environments that cater to that slice of developers are not welcome either. Flash developers decry that Apple is trying to "lock in" developers. That's false. Cupertino merely wants their developers to actually develop something that was actually, you know, DEVELOPED for the iPhone platform rather than recompiled on the fly. If you do not want to do that, no one is twisting your arm to play along.

Apr 17, 2010
nik liked this post.
Apr 18, 2010
eamdude said...
Users dont want to spend a lot of time surfing the net looking for software. So the app-store makes sense. Users like being protected from viruses, scams, phishing and just idiots and scams in general. So the gate-keeping of the app-store makes sense.

Apple wants apps that highlights it brand and the device. Especially with a new type of user interface. So it wants to make sure this type of developer isnt forced out of the market by Wal-Mart (like Adobe's plaform).

Apple also want to quickly make hardware changes. I too remember Adobe during the Intel conversion. The delay was ridiuluos. And Adobe blamed everything on their owm cross-platform framework.

Luckily for devopers Apple is not the only game in town.

Mar 10, 2011
Jessica K. said...
Nice, I have a good friend working at Apple who said that they will also do some big improvements this year, lets see what they are working on
Apr 21, 2011
Roger liked this post.
Apr 21, 2011
Roger said...
thanks for sharing!
Apr 22, 2011
caro aprisio liked this post.
Apr 30, 2011
blond-xxx liked this post.
Jun 20, 2011
resultat bac liked this post.
Sep 14, 2011
Barry Maurice said...
i dont see a like button, how are these guys liking the post?
Dec 19, 2011
Anna Longreen liked this post.

Leave a comment...

steve cheney

steve cheney

Engineer with an MBA.

Current entrepreneur.

Former programmer, marketer, investment banker, and vc.

My Other Sites
 
Subscriptions

Contact me
Follow me on Twitter