The iPad debuted, as expected, without support for Adobe Flash. Many industry observers spend very little time thinking about possible reasons for Apple's continued resistance to Flash and instead very quickly come to the conclusion that Apple either "has it in for Adobe" or "likes to screw with its users". Since Adobe has been, is and will be one of the prime developers of content on OS X, it is highly unlikely that Apple "has it in for Adobe". They might be getting a bit frustrated with Adobe's inability or unwillingness---or a mix of both---to update their very popular software to 64-bit in the case of Flash and Photoshop, or Cocoa in the case of Photoshop. Apple does a good job of optimizing the user experience with their operating systems and software---and can do so because they have access to source code for almost all of the UI that a user is likely to see. Except in the case of the Flash plugin, which is used in a huge amount of web content these days. The article, <a href="http://daringfireball.net/2010/01/apple_adobe_flash" source="Daring Fireball" author="Jon Gruber">Apple, Adobe, and Flash</a>, has a lot more detail, but the crux of the argument is as follows: <bq>[...] the most frequent cause of crashes across all of Mac OS X are (or at least were, pre-Snow Leopard) “plugins”. [...] several sources at Apple [...] confirmed that “plugins” was a euphemism for “Flash”. [...] Flash is still a 32-bit binary despite the fact that Apple wants to go 64-bit system-wide. Flash remains 32-bit and there’s 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. [...] Which situation do you think Apple is happier with? Mac OS X, where they had to create a new web content plugin architecture because Flash crashes frequently and isn’t 64-bit? Or iPhone OS, where they control the source code to every single component, and can do whatever they want, when they want?</bq> Near the end of this very informative article, we learn that, even though Flash has a monopoly on video playback for the web---a situation this author personally finds to be awful<fn>--- Adobe's OS X version has always lagged behind its Windows version. The Windows version takes advantage of hardware playback for high quality video whereas the OS X version cannot because, as Adobe puts it, <iq>Apple does not provide a public API to make this happen</iq>. What they mean is that Apple does not provide an API for <i>direct access</i> to the hardware. Instead, applications wishing to run video must use either the Quicktime API or the new Quicktime X API in Snow Leopard. Adobe should just use those APIs, as Apple's own QuickTime player does. Judging by the number of crash reports associated with the Flash plugin (mentioned above), Adobe is the <i>last</i> company to which Apple should grant hardware access. Apple, as a software developer, finds itself in the classic position of any highly skilled company forced to work within budget constraints (both time and money) and forced to work with existing technologies to facilitate and encourage integration and adoption of its own software. Take, for instance, this author's experience with development on the .NET platform from Microsoft. Though a software company (e.g. <a href="http://encodo.com">Encodo Systems AG</a>) may have employees skilled and experienced enough to write pretty much anything they need, there isn't nearly enough time in the world to do so. There are other issues to consider as well: <ul> Every piece of software a company writes increases its own support footprint: That component needs support forums, documentation, tutorials and bug fixing. Standardized components are likely to be already well-established among developers willing to try a company's software, increasing the likelihood that they can adopt new software that integrates with (instead of replaces) technology they already know and use. The time (not to mention the skill, which many companies don't have<fn>) required to write more complex software is often prohibitive and can severely affect cost estimates and schedules. </ul> Those concerns seem to indicate that, whenever possible, a company should focus on its core offering and simply integrate with existing technologies. The company minimizes its support footprint and spends its time working on software that they are uniquely good at. Partner companies are happy because they can integrate that company's products without throwing out any infrastructure or doing any massive retraining of their developers. Product budgets stay nice and small and schedules stay nice and tight because no-one is spending time re-writing components that already exist. Yes, indeed, it's all unicorns and rainbows. As long as the external software doesn't suck so much that it makes you wish you'd never used it. What happens when you've got a skilled set of in-house developers and they're forced to slog through development integrating with wildly popular technologies that look wonderful on paper, but that are shaky, unstable, unreliable and well-nigh unpredictable to use in practice? What happens is that developer frustration goes through the roof, budgets start to explode and product development stagnates with functionality in core areas plateauing instead of steadily rising simply because developers are spending all of their time working around irreparable bugs in the constellation of integrated software instead of building their own product. At Encodo, we've recently gone through some very rough patches working with WCF (Windows Communication Framework), EF (Entity Framework) and the data-binding used by the Windows Forms libraries and all components that extend it (like the DevExpress UI component libraries we use). In the case of DevExpress, we have the expertise to build our own UI components...but for all of the reasons outlined above, we chose to use a popular component suite instead. We have never wholly regretted that decision, but have often tangled with bizarre APIs and event models with which we would have never been satisfied <i>had we had control over the source</i>. And don't even get me started on EF: The first version is not ready for prime-time at all. It has holes everywhere and doesn't scale at all for development or practice (models over 25 entities are considered "large"). There are hidden limitations around which one must work; limitations that would not exist or that could easily be removed in code that was under one's own control. Similarly, the WCF libraries include a nearly impenetrable data serializer/deserializer which, as with most Microsoft technologies, emits error messages that are cryptic, at best. Not only that, but we recently managed to finally track down what we are quite sure is a bug in the implementation. It was on the hunt after this bug---and other inconsistencies---that we several times had to meet to determine whether we shouldn't just toss the whole thing overboard and roll our own solution. It's not that we wanted to have our own serialization; it's that we were spending so much time working around bugs in WCF that we weren't getting our work done anymore. Integrating existing frameworks and libraries makes sense <i>on paper</i>, but you have to make sure that those libraries are worth integrating i.e. that they don't end up costing you most than you gain. Companies should avoid shoddy technologies even if they are hugely popular and developed by big players (like Microsoft) because there is no way to avoid huge development costs with them. If the technology design and implementation are good, then you will save money; if they are not, it's going to cost you no matter what. That is, if you need object persistence in a database (EF) or need to send data over a wire (WCF), you're going to be spending a lot of money and time if you use those two technologies. If a company has a great development team, it might make more sense to avoid them---and their attendant frustration---entirely. That kind of situation sucks and it's completely understandable that Apple wants to avoid it. It's both a money sink and horrible for morale. <hr> <ft>The situation of video on the web being de facto controlled by Adobe is likely to change with the support of the HTML5