Helpful Tips for Adobe

underdogcover.jpgIn a blog post on Tuesday, Mike Chambers of Adobe announced that the company was abandoning its plan to support creation of iPhone OS apps using Flash CS5. The post is less emotional than Lee Brimelow’s “Go screw yourself, Apple” but every bit as whiny.

All the angles on the issue have been covered extensively on tech blogs, in particular Daring Fireball, so you won’t see any particularly novel insight here. But I haven’t yet seen them all gathered in one place. Apple has gotten a lot of criticism across the internet — much of it entirely deserved — for its App Store approval policies and the closed system approach it’s taking with the iPhone OS. And it bugs me to see Adobe employees — whether representing the company as with Chambers’s post, or not as with Brimelow’s — getting so much traction by taking advantage of that ill will, when Adobe doesn’t have a leg to stand on.

After citing various stories about Apple’s rejection policies and an even-handed piece on Slate called Apple Wants to Own You, Chambers goes on to say that Adobe will be shifting its focus with Flash CS5 onto the Android platform. Here are a few helpful tips for Adobe that might make this next choice of platform go more smoothly:

1. Don’t promise something to your customers unless you’re sure you can deliver.

Adobe’s claiming that Apple suddenly introduced a new clause to the developer program license that blew all their hard work out of the water. How could they possibly have predicted that Apple would so cruelly impose a last-minute ban of Flash on the iPhone suddenly out of nowhere? I mean, sure, the iPhone has been out for three years now and it’s never allowed a Flash player, but with Apple’s draconian secrecy, who knows why that is? Okay, fine, the CEO of the company has repeatedly said that it’s for performance reasons and battery life, but that’s just spin. Adobe had no way of predicting that the company that’s refused to allow Flash on their devices would suddenly decide not to allow a program that runs Flash. It’s all Apple’s fault!

2. Have a chat with Google and Motorola first.

There’s no way that a small start-up like Adobe could’ve communicated with industry giant Apple, either. Who even knows those guys’ email addresses? Plus, they’re scary: Gizmodo made a whole post about the guy whose book-reading app was rejected for containing adult material. Who’s to say that the exact same thing wouldn’t happen to a multinational corporation proposing to create a new development environment for the platform? Unlike Apple, Motorola and Google are pledged to complete openness, and they won’t have any qualms about performance or security on their branded Android OS devices. You probably don’t even need to ask first.

3. Try running your software on the device in question.

Apple’s reasons for refusing Flash are so arcane and mysterious that nobody can figure them out. Even though it’s been said repeatedly from multiple sources both inside and outside Apple that Flash is a hit on performance on battery life, that’s just idle speculation. Better to try to sneak something in instead of actually trying to find the problems with interpreted code and non-standard video playback and getting it to run acceptably.

4. Don’t use a Mac for development.

Because if you want to get anything done, you’ll have to use Adobe software, since Adobe has near-total market dominance in every area of production. And Adobe software runs like shit on a Mac. Mr. Brimelow, I suggest that your talk about the long relationship Apple and Adobe have had with each other would be more convincing if you had a dramatic backdrop, or a YouTube video playing in the background. For the backdrop, you’ll want to use Photoshop CS4, the first version that supports a 64-bit OS, which came out a year and a half after OS X converted to 64-bit. And for the YouTube video, be sure you speak up loud, because playing anything with the Flash video player on a Mac will cause your computer’s fan to kick into overdrive from the increased processor load.

5. Consider what “cross-platform” means for a platform built entirely around its unique identity.

If the blog posts from employees weren’t enough to convince you that Adobe’s committed to cross-platform development, then running any piece of Adobe software — especially any AIR app — should do the trick. Using PhotoShop or Flash on a Mac means that you get to give up everything that made you choose the Mac OS in the first place. The closest they’ll come to “Mac look and feel” is begrudgingly including a “Use OS Dialog” button on their file dialog boxes. But the iPhone, even more than the Mac, is specifically branded as a device that wins not on features, but on the OS.

Chambers makes a point of saying “While it appears that Apple may selectively enforce the terms, it is our belief that Apple will enforce those terms as they apply to content created with Flash CS5.” Or in other words, Apple will allow Unity, .NET, et. al., but is singling out Flash/Adobe to screw them over specifically. Adobe’s complaining about Apple not giving them fair treatment is a lot like a polygamist accusing one of his wives of cheating.

6. Have someone define “closed system” to you.

Apple already covered this one beautifully with its terse and awesome response to Chambers’s post:

“Someone has it backwards–it is HTML5, CSS, JavaScript, and H.264 (all supported by the iPhone and iPad) that are open and standard, while Adobe’s Flash is closed and proprietary,” said spokeswoman Trudy Muller in a statement.

This is the most galling part of the whole thing, to me: Adobe’s desperately grabbing on to Cory Doctorow’s coat tails and waving the flag of intellectual freedom, while simultaneously suggesting that the iPhone OS is gimped because Flash has something like 98% market saturation with internet video.

The best explanation I’ve seen is from Louis Gerbarg on his blog: allowing Flash, or even iPhone-targeted Flash, onto the iPhone would mean Apple effectively turning its OS development cycles over to Adobe’s engineers. It’s the same reason they’re so uptight about developers using private frameworks: if they change something with an OS update, the app breaks, and customers complain to Apple. Not the developers.

Adobe’s essentially going into a store, handing the owner a big black box, refusing to let the owner see what’s inside, and then complaining about freedom and openness when the owner refuses to sell it.

7. Learn to appreciate the monopoly you’ve already got.

It’s not particularly insightful to point out that the environment Apple’s created with the iPhone OS is very similar to the environment that game developers have had to deal with for years. Game console manufacturers have very tight restrictions on what they will and won’t allow to run on their devices — if you think that Apple’s approval process is complicated and draconian, you should go through Nintendo’s technical certification process sometime. (Note that this isn’t a complaint: the certification process means it’s much, much harder to find a buggy game that crashes your system or runs poorly on your particular console configuration).

And the lesson in game development is that content is more of an investment than code. (At least, code written in a particular language. And that’s partly my programmer bias showing through, where it’s a point of pride that once you’ve learned how to do something in one development environment, it’s much easier to do the same thing in a different one). Art assets will port from platform to platform, even if the code base doesn’t. [More on this in point number 10.] I have yet to see a game company that didn’t use Photoshop to generate art assets, and most also use a combination of Illustrator or AfterEffects or any number of other Adobe products.

8. Come out and acknowledge who multi-platform development benefits, exactly.

There is an ease-of-use and familiarity benefit to using Flash. But Adobe reps hardly ever mention that. (As someone who’s developed games using Flash and using Cocoa, I can kind of understand why Adobe wouldn’t push the “ease-of-use” or “predictability” claims where Flash is concerned). Instead they talk about cross-platform capability. An independent developer might be drawn to Flash for, say, making a game because it’s an environment he already knows. A publisher would be drawn to Flash for being able to make the same game for the iPhone, Android, Web, and anything else.

And this makes it a little bit like trying to explain to poor people why they shouldn’t vote Republican: they don’t care about you. Adobe isn’t going to make such a big stink, or for that matter build a campaign around a new feature in one of their flagship products, for the indie developer who’s going to blow a thousand bucks on the new Creative Suite. Adobe wants to get publishers to buy site licenses. And publishers want to make something once and then get it onto as many platforms as possible, because for a publisher, development time is more expensive than hardware purchases, testing, and customer support. Smaller developers will quickly reach the point where having their product on multiple platforms is costing more than the revenue it’s generating.

So when Chambers says:

The cool web game that you build can easily be targeted and deployed to multiple platforms and devices. However, this is the exact opposite of what Apple wants. They want to tie developers down to their platform, and restrict their options to make it difficult for developers to target other platforms.

what he means is: Apple includes a free development environment on their machines, to encourage people to buy their hardware. It comes complete with documentation, visual design tools, and built-in animation and layering libraries that make it relatively easy to achieve Flash-like results using native code. However, this is the exact opposite of what Adobe wants. They want to tie developers to Flash, to ensure that they have a proprietary development environment that’s most appealing to larger publishers, and restrict their options to optimize the runtime to target any particular platform, guaranteeing that it runs equally bad everywhere.

The “cool web game” bit is there to make it sound like the guy sitting in his bedroom who’s just finished his cool Bejeweled clone-with-RPG-elements can just hit a button in Flash CS5 and suddenly be rolling in heaps of money from App Store sales. And to the smaller, independent developers who would like to try releasing their games for multiple platforms: learn Objective C. It’s not that difficult, and you’ll have developed another skill. That to me seems more valuable than getting upset that a game designed for a mouse and keyboard on the internet won’t port to a touch-based cell phone without your intervention and a little bit of effort.

9. Make a genuine attempt at an open system.

If Adobe really is all about content creation, and if they’re going to insist on jumping on the anti-Apple “closed system” bandwagon, why do it for an inherently closed system? They’ve got one development kit that requires a plug-in and forces all its content into a window on a webpage, and they’ve got another development kit that works with HTML and PHP but nobody uses it. Why not put their content creation software expertise to work creating stuff that’s genuinely based on open standards?

There are tons of great HTML 5 demos getting passed around the internet, and they’re all done with a text editor. (And, most likely, Photoshop). Why not take the Flash front-end, since people like it for whatever reason, and let it spit out HTML 5, CSS, and JavaScript? ActionScript is already a bastardized sub/superset of JavaScript. HTML 5 has a canvas element and layering. There’s a browser war going on, where everyone’s trying to come up with the fastest JavaScript interpreter; only Adobe can make Flash Player plugins run faster, and they don’t have a great track record at that. Flash that doesn’t require Flash Player would be huge. No doubt Flash has some power-user features I’m not familiar with, and of course Flash Video is a whole different topic, but I’ve never done anything with Flash that couldn’t be done according to the HTML 5 spec and some clever JavaScript.

10. Stop the damn whining already.

Brimelow closed comments to his post to avoid “the Cupertino Spam bots,” and Chambers warned that non-constructive comments such as “Flash SUXXORS!” would be deleted. Because, as everyone on the internet knows, anyone who defends Apple for any reason, ever, is automatically a drooling Apple fanboy who believes Steve Jobs can do no wrong.

Which means, I guess, that everyone in the tech industry is 12 years old.

What these guys need to understand is that complaining about Adobe’s closed, proprietary system doesn’t automatically make Apple’s good, and vice versa. (Although it’s a big point in Apple’s favor that they don’t try to claim that their system isn’t closed). There are definitely problems with iPhone development.

The restriction on interpreted code does indeed suck, and is the biggest problem that Apple needs to find a solution for. When I mentioned that game developers have spent years learning how to port games to different consoles, I didn’t mention that the key to that is often a scripting language, like Lua. That allows a big chunk of code to be included in the portable game “content:” tailor the engine specifically to each console, but let the game logic stay fixed. (In theory, anyway). If Apple would just have a set of approved scripting languages — instead of just JavaScript via WebKit — and include them with the OS, it would open up a huge number of possibilities. The appeal of Lua on a mobile phone is even more evident than on a PC: it’s tiny, relatively efficient, and too simple and general-purpose to cause many problems when the underlying OS gets updated.

(I’d be remiss if I didn’t mention again that an iPad-native equivalent of HyperCard would be sweet. It could even use the Keynote front-end and run everything with WebKit. If you need a consultant on the project, Apple, let me know).

The other problem is the lack of transparency in the approval process. I mentioned that the certification requirements for consoles are a lot more complicated than those for the App Store; the advantage, though, is that they’re very explicit. You can and will still get surprised by a rejection, but a lot of the more obscure problems are solved when there is a huge list of requirements and developers are forced to test everything.

As for the other objections that are so often brought up, they seem reasonable enough to me. Yes, the state of file management on the iPad is really terrible right now, but I’m confident it’ll improve. Sure, Apple can reject an app for “duplicating functionality” of one of its built-in apps, but that situation is fluctuating (witness their support for VOIP apps like Skype, and browsers like Opera Mini) and the core apps are functional enough anyway. (Rejecting an app for the “pinch to preview a stack of pictures” functionality is pure bullshit, though).

And Apple can and does reject apps based on content alone. But as John Gruber pointed out, Apple’s still selling a brand as much as a platform. That’s the fundamental philosophical difference between the Android model (and Adobe’s whining) and the iPhone model: Android is selling you on the idea that you can run anything, Apple is selling you on the idea that you can run anything good. That’s why it’s a good thing that both platforms are available to both developers and customers. If you want a general-purpose phone that can run anything you throw at it, including ports of web games, then get an Android. If you want only the stuff that’s been specifically tailored to run well under the iPhone OS, then get the iPhone.

Leave a Reply