About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search
Home » Learning Curve » Red Hat Diaries

Steve Jobs is Right

It's not just Adobe's Flash that sucks.

Get It

Try It

After Steve Jobs introduced the iPad, he traveled to New York City to trash Flash. That created a bit of a brouhaha. Then Apple came out with a new 'SDK clause' for their coming platform iPhone OS 4 and a war between Adobe and Apple ensued.

Steve Jobs is right.

Flash helped contribute to a cultural revolution, particularly through YouTube, but it isn't Flash per se - it's the 'moving pictures' thing. Early YouTube clips were scrappy and of low quality and YouTube grew. Google came in and bought up YouTube and immediately began working on improving the quality. And the likes of Edgar 'Napster Killer' Bronfman came in and started yanking their IP. To this day there are web surfers who can't handle the bandwidth needed to run the new YouTube (and only marginally run the old one).

Flash on any platform but Windows is crap. It sucks CPU mercilessly. More and more sites overwhelm their visitors with Flash clips and accept hordes of advertisements that use Flash. The effect is rather gaudy - and will set a fan going in any Apple laptop. It's not the idea and it's not the technology - QuickTime is able to stream video on comparable hardware with no ill effects. It's the lack of effort Adobe put into it. Flash on the Mac sucks - and it's Adobe's code that sucks, not the OS.

It's ironic that the companies of John Warnock and Steve Jobs should be at war, but in retrospect history shows it to be mostly inevitable. Warnock and Jobs literally invented the desktop publishing industry in the 1980s, without which the original Macintosh would have remained a stillborn product. But Microsoft's Windows boomed in the 1990s and that's where Adobe concentrated their efforts. And hardly surprising: Microsoft took over the entire market and Apple were marginalised more than ever.

Adobe offered token support for Apple's new OS but little more. The original OS architecture - MacOS - was outdated before the new millennium, but nothing much changed at Adobe. Adobe worked from a single code base for their computational models, in procedural and not object oriented code, only branching at the front end. Apple's adoption of Objective-C and NeXTSTEP meant a total paradigm shift but Adobe didn't bother.

Adobe didn't try adopting Apple's new technologies. There was no Cocoa inside Adobe's applications. Instead they seemed to be sticking with Carbon which was only meant as a transitional solution anyway.

But appearances deceive even here: Adobe's Carbon bundles were in fact wrappers around PEF binaries, far behind the times, and this meant that Adobe customers often had to purchase upgrades when their software should have worked on their new Apple hardware. Adobe customers started getting shafted.

Even to this day Adobe are doing the same thing with their Flash for Snow Leopard. One can find Adobe's Flash at the path '/Library/Application Support/Macromedia/Shockwave 10'. They use their own non-standard preferences system (at '/Library/Application Support/Macromedia/Shockwave 10/Shockwave 10 Preferences') and their additional binaries at '/Library/Application Support/Macromedia/Shockwave 10/Xtras' show what's really going on - they're still using programming technologies that were too old already ten years ago.

$ pwd
/Library/Application Support/Macromedia/Shockwave 10/Xtras
$ file *
Animated GIF Asset:         header for PowerPC PEF executable
CBrowser PPC Xtra:          header for PowerPC PEF executable
DVD Asset:                  header for PowerPC PEF executable
Flash Asset PPC:            header for PowerPC PEF executable
Font Asset PPC:             header for PowerPC PEF executable
Font Xtra PPC:              header for PowerPC PEF executable
Havok:                      header for PowerPC PEF executable
InetUrl PPC Xtra:           header for PowerPC PEF executable
LRG Import Export:          header for PowerPC PEF executable
MPEG 3 Import Export:       header for PowerPC PEF executable
Mix Services:               header for PowerPC PEF executable
Multiusr:                   header for PowerPC PEF executable
NetFile PPC Xtra:           header for PowerPC PEF executable
NetLingo PPC Xtra:          header for PowerPC PEF executable
PNG Import Export:          header for PowerPC PEF executable
QuickTime6 Asset:           header for PowerPC PEF executable
RealMedia Asset:            header for PowerPC PEF executable
SWA Decompression PPC Xtra: header for PowerPC PEF executable
SWA Import Export:          header for PowerPC PEF executable
SWA Streaming PPC Xtra:     header for PowerPC PEF executable
Shockwave 3D Asset Xtra:    header for PowerPC PEF executable
Sound Control:              header for PowerPC PEF executable
Sound Import Export:        header for PowerPC PEF executable
Speech:                     header for PowerPC PEF executable
Sun AU Import Export:       header for PowerPC PEF executable
Targa Import Export:        header for PowerPC PEF executable
TextAsset PPC:              header for PowerPC PEF executable
TextXtra PPC:               header for PowerPC PEF executable
Tiff Import Export:         header for PowerPC PEF executable
XmlParser PPC Xtra:         header for PowerPC PEF executable

Their 'bundle' at /Library/Application Support/Macromedia/Shockwave 10/Shockwave.bundle is hardly better. Drilling down to /Library/Application Support/Macromedia/Shockwave 10/Shockwave.bundle/Contents/MacOS shows the same thing as before. This is no Cocoa bundle - this is not native code.

$ pwd
/Library/Application Support/Macromedia/Shockwave 10/Shockwave.bundle/Contents/MacOS
$ file *
DPLib:                header for PowerPC PEF executable
IMLLib:               header for PowerPC PEF executable
MacromediaRuntimeLib: header for PowerPC PEF executable
PluginLib:            header for PowerPC PEF executable
ProjLib:              header for PowerPC PEF executable
SwMenuLib:            header for PowerPC PEF executable
SwSupportLib:         header for PowerPC PEF executable

Applications can enhance the user experience with the modern interpretation of resource forks, but to be completely reliant on them as Adobe remain is to be stuck back in the 1990s writing software for a platform that no longer exists. Adobe wouldn't have anything to bring to the Apple computer OS market without Apple's assistance in keeping those ancient technologies alive. And it must hurt Apple to have had to do this year after year with no sign of movement from Adobe.

Adobe's clinging to the past isn't limited to their Flash - they do that with all their products. Whilst many will argue that Carbon has been fully equivalent to Cocoa (which it is not) it is a fact that Carbon has been officially deprecated today (hooray) and Apple absolutely refused to commit to a migration to 64-bit. And good for them - waiting 10-15 years for an industry colleague to get with the programme shows more than enough patience.

It wouldn't have taken much effort for Adobe to migrate to Cocoa ten years ago. The 'learning curve' for Objective-C is one of the smoothest and friendliest in the industry. Not making this minimal effort - with so many practical benefits - says a lot about a company.

A great deal of code in Adobe's application 'models' would remain procedural anyway and need little or no changes. All the Adobe people had to do was learn the Cocoa icing on the cake, starting with Objective-C, a programming language Apple correctly claim takes but a few hours to learn for seasoned C programmers. (And one must assume Adobe's crew are seasoned C programmers.) But no one at Adobe ever gave the go-ahead.

So whilst Adobe products looked 'almost OK' in many instances, they missed out on all the good stuff the native Cocoa could bring. And small quirks would always remain and ultimately annoy.

Adobe prefer cross-platform solutions, their AIR framework being a case in point. But anyone running TweetDeck on Mac OS X knows the score - it uses the AIR framework and it's a CPU hog just like its Flash sibling. AIR is not a good solution for any platform.

Flash melts CPUs and sucks the life out of a battery. The iPhone and the iPad are mobile devices where this battery power is crucial. It makes perfect sense to disallow products that work like Adobe's - they make the platforms look bad, the devices themselves perform poorly.

And now Apple want to stipulate what programming platform people use for their mobile devices. Oh the audacity, shout some, whilst others just sit back and smile in amusement.

Apple have a corporate responsibility and ambition to make their devices look good. And whilst it's been contended there have never been any good cross-platform titles for the Mac and whilst some would disagree, all would struggle to cite substantial user land examples.

Mozilla's Firefox may be the most popular of the 'good browsers' today but integration with Mac OS X has been slow and is still far from satisfactory. Integration with the NSText system is starting only today. The FOSS community's lack of experience with Apple's OS - and in particular with the object orientation paradigm - produced several embarrassing gaffes over the years, such as in the misuse of dialogs and sheets. Mac OS X offers functionality not found on other platforms and the Moz people simply didn't get it. AppKit services are somewhat integrated today with Firefox 3.6 but an acceptable level of integration is still far off.

Unix itself is the ultimate example of cross-platform but it's mostly not seen by end users and Linus himself says end users should never be aware it's there. For end users, it's all down to the interface they're greeted with. And neither REAL nor AppleScript - which many felt should have been scuppered with Carbon - nor Carbon nor AIR are ever going to look good. And worse: they're never going to work good. And when they don't work good, the blame doesn't go to the independent software vendor: it goes to the hardware vendor. Apple.

Objective-C and the Cocoa and Cocoa Touch classes, as the NeXTSTEP classes before them, are a revelation. This is the way all graphical code should have been written. This is the way it should have been done on all platforms - on Windows, GNOME, and KDE. And for software houses like Adobe as well.

C, Objective-C, and even C++ admit of inline assembler best used in conditional compiles for kernel and device driver code. The good programmer will keep application code documented in its native language but will continually test algorithms to find what works best for a given occasion - and may do so by studying assembler output. Nothing wrong in that - as long as the C code documents why a certain algorithm was used or unless the whole application is written and documented in assembler, something that's not particularly advisable and hasn't been for a long time. Early C compilers over thirty years ago were good enough to be compared with assembler for efficiency and speed, and things are of course much better today.

Keeping things at a relatively high level (although it's actually rather low level) also ensures the platform independence Steve Johnson once envisioned for C itself - and thereby Unix and everything that followed. The whole idea with Johnson's 'portable C compiler machine' was to sidestep the learning curve needed every time an OEM came out with a new platform - only a few of the crew needed to study the new instruction set, instead of everyone having to learn it (and write code every day in it).

Two man-months was the estimate back then: the time it took to port C to a new hardware platform.

Once you have platform independent code - and Cocoa and Cocoa Touch code is platform independent so much more than Steve Johnson's estimated 94% for Unix - you can switch out your hardware underbody at any time. There wasn't much of an upheaval back in 2006 when Apple moved from the PowerPC to Intel. For the most part that migration was painless for all involved. And the ADC tools made it even easier.

Keeping one's base of third party products is essential. Windows might be more secure today if it weren't dependent on millions of software titles that won't work with less than the crappy platform they're written for. The hundreds of thousands of iPhone/iPad apps are something Apple cannot do without and risk breaking. So keeping people on the right development track is part of that. Spite the platform and everybody loses - yes, even Adobe.

And from a purely aesthetical point of view, it's nice to see the sluggish Adobe being pushed out of the Dark Ages and into the New Millennium. They're only about ten years behind today; with a bit of talent and overtime, they might still catch up.

See Also
The Technological: Adobe Systems
Red Hat Diaries: Apple Buy Adobe?
The Technological: Adobe on Drugs?
Radsoft: Adobe Flash Makes Browsers Bite It
Bloatbusters: Adobe eBook Reader for Windows
Industry Watch: Adobe Flash Makes Browsers Bite It
Adobe: Workaround available for security vulnerability caused by installing Adobe Version Cue CS3 Server

jlongster: Scheme is also dead on the iPhone
Daring Fireball: Why Apple Changed Section 3.3.1
Tao Effect Blog: Steve Jobs' response on Section 3.3.1
Maniacal Rage: Crash Reports for 'Adobe Photoshop CS4'
Macworld: Adobe evangelist tells Apple: 'Go screw yourself'
The Flash Blog (Lee Brimelow): Apple Slaps Developers In The Face
Macworld: Change in iPhone developer terms puts Flash in crosshairs

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search
Copyright © Rixstep. All rights reserved.