Heres the deal. On stage at the WWDC 2009 keynote address last June, Apple senior vice president of software engineering Bertrand Serlet was explaining the new web content plugin mechanism for Safari in Snow Leopard. Rather than run within Safaris application process, web content plugins now run in their own process, so if they crash, they (usually) dont crash Safari itself. You get a broken little rectangle in the page where the plugin was executing, but the browser itself stays running.
Apple did this for two reasons. Serlets stated reason on stage was crash resistance, as mentioned above. As for why such crash resistance was worth implementing, Serlet explained that, based on data from the Crash Reporter application built into Mac OS X the thing that asks if youd like to send crash data to Apple after a crash the most frequent cause of crashes across all of Mac OS X are (or at least were, pre-Snow Leopard) plugins.
Serlet didnt name any specific guilty plugins. Just plugins. But during the week at WWDC, I confirmed with several sources at Apple who are familiar with the aggregate Crash Reporter data, and they confirmed that plugins was a euphemism for Flash.
In other words, in Apples giant pile of aggregate crash reports from all app crashes on all Macs from all users who click the button to send these reports to Apple Flash accounts for more of them than anything else. That doesnt mean Flash somehow causes crashes in any various app. Presumably, most of the time its Safari or some other browser playing Flash content. And its worth noting that this doesnt necessarily mean Flash is particularly crash-prone or poorly engineered. Think of it as a formula like this:
total crashes = (crashing bugs) × (actual use)
Flashs number and severity of crashing bugs could well be somewhat low and it would still account for a large number of total crashes because its actually used all the time by any Mac user with Flash content playing in a web page. And, if Flash Player for Mac OS X actually is poorly-engineered overly-buggy code, well, thats even worse.
But theres another reason why Apple created this new external process architecture for web content plugins in Snow Leopard: it was the only way they could ship Safari and the WebKit framework as 64-bit binaries. Flash Player is only available as a 32-bit binary. (This is true for other third-party web content plugins, like Silverlight, but Flash is the only one that ships as part of the system.) 64-bit apps cannot run 32-bit plugins. Apple doesnt have the source code to Flash, so only Adobe can make Flash Player 64-bit compatible. They havent yet. So if Apple wanted Safari to be 64-bit in Snow Leopard (and they did), they needed to run 32-bit plugins like Flash in a separate process.
Maybe you dont believe Apple that web content plugins are the most frequent source of crashes on Mac OS X. Maybe you dont believe me and my unnamed sources at Apple that its Flash in particular that accounts for this. Thats cool, skepticism is good. So then in that case, maybe Bertrand Serlet blamed plugin crash resistance for political reasons, just to stick a knife in Adobes back, and the only reason Apple went with this external-process architecture was for the 64-bit/32-bit incompatibility.
But that just shines a light on the fact that Flash is still a 32-bit binary despite the fact that Apple wants to go 64-bit system-wide. Flash remains 32-bit and theres nothing Apple can do about it. Instead of being able to make Flash 64-bit themselves, Apple had to engineer an entirely new plugin architecture.