Opening Defense

First off, Jobs is completely correct when he writes that this has nothing to do with Flash competing with the App Store. Apple has never really liked Flash, and this dislike dates back for quite some time. I remember back when I worked Apple that we made every effort to avoid using Flash when possible; and this was back in 2007 (pre-iPhone). Apple was adopting open web standards and avoiding Flash then, and it continues to do so now. The message has been pretty consistent. Although the competition Apple might get from opening Flash to developers (specifically game devs) might be significant, it’s really not the big issue. Apple has a very deeply rooted stance on Flash’s place in the web.

That said, there are a few points that Jobs makes that don’t really add up, especially given Apple’s own practices regarding “open”-ness.

Rewriting

Jobs writes:

Most Flash websites will need to be rewritten to support touch-based devices.

There are two issues with this. Firstly, the term “most” is subjective (and probably wrong). I don’t actually know any Flash sites that are heavily dependent on the “rollover” UI that is not possible with touch-based devices. This is probably because, with the exception of portfolio-style (artist, musician, photography) sites, there are very few websites that are hosted entirely inside of a Flash embed. I would imagine that “most” sites use regular HTML for navigation (where rollovers would be involved) and only sprinkle Flash around for content. Content, generally, shouldn’t require any “rollover” behaviour.

But even if the use of “most” was accurate, it’s not really a reason to hold Flash off a device. Yes, those sites would need to be rewritten, but plenty of websites had rollover-style navigation UIs before the iPhone too. In fact, rollover based UIs were used in HTML for just as long as they were used in Flash. Those websites (of which Apple’s own site was included) were all modified to handle the new touch-based paradigm. I don’t see this as any greater cause for concern when it comes to Flash.

Jobs then says that this rewrite is a good opportunity to use “modern” technologies like HTML/CSS/JS. I’m not a huge fan of Flash, but Flash is a modern technology. It’s not open, but it’s modern. There are plenty of places where Flash is a better idea than sticking to standards (ie. try grabbing webcam/mic input with standards). Like any good tool, it should be used in those places. Saying that your site is legacy and therefore undeserving of the internet unless it is using open standards is an opinionated response that makes the web sound more closed rather than “open”. Part of the reason that HTML has an <embed> tag is to allow for these arbitrary plugins, whether they be open software or not. Saying that there is no need for such a plugin based web is indeed saying that you don’t need “the full web”.

Third Parties Are a Crowd

This sounded ironic to me:

If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

It’s funny because that sounds a lot like the relationship iPhone developers have with Apple and the App Store. Just replace “third party” with “first party” and re-read.

What is the real difference between first and third parties here? Does it mean Apple is more likely to enhance the tools/platform than a third party? Flash still gets updated, and fairly often. Does it mean developers are not at the mercy of Apple when developing for the iPhone? Oh how I wish that were true.

Apple Hates Edge Cases

Overall, the points Jobs made were mostly valid. I can see why, for technical reasons, Apple does not want to support Flash. I can also see why it’s important to uphold your platform’s UI standards above “cross-platform functionality”. And yes, supporting open standards on the web is generally a good idea. But this stance still just leaves you kind of unsatisfied. Jobs’ view is very clear cut, minimalist and simplistic. There’s no denying that these traits are a core part of Apple’s DNA. It’s clear that Apple hates edge cases.

The problem is that the real world is not so clear cut. The real world is filled with edge cases, and these edge cases are all sets of real world use cases for Flash that are not addressed by HTML5. I touched on mic/webcam input above (chatroulette anyone?), but there are also things like Flash animation (we all know Homestar Runner) and the real issue (not even an edge case) of Flash-based games. You have to ask yourself, would these sites be around if it wasn’t for Flash? You can argue the legitimacy of sites like chatroulette, but in Apple’s world, the internet would have never seen it, period. Is that how we want the web to work? That doesn’t sound all that open to me.

Now before you think it, yes, some of the above examples could be rewritten with JS and the emerging canvas APIs, but until there are tools to make this as easy as Adobe makes it, it’s not a realistic solution for most people. Also, most game developers aren’t so comfortable with putting up their work in a JS file that people could easily take and modify (and republish). Yes, Flash can be decompiled (I’m no Flash expert, there may be extra protection), but it’s not as easy as downloading a linked Javascript file, opening a text editor and changing numbers. To some, this difference is an important edge case; a show-stopper, in fact. Not all code can be commoditized.

I really have no problem with Apple trying to reduce the amount of Flash used on the web, it’s certainly being abused (especially for serving video) to Comic Sans proportions. But to completely remove it, well, that seems extreme. Flash is a tool, it has its valid edge cases. And yes Apple, I said it, valid edge cases.

Turns out that copying over the Dock.app after using Migration Assistant caused the four finger gesture to not be caught by the system. I moved Dock.app over because I modified some of the resources. Rather than copying the binary over the second time, I only moved the resources and now everything works fine. Hopefully, if you had this problem, replacing your original Dock.app will fix it.

So Mail.app doesn’t know jack about subscriptions unless you know how to rub it the right way. After recently switching to IMAP I also discovered that it doesn’t like to use standardized IMAP folder names. You know, “Sent”, “Trash”, et al. If you’ve been annoyed by the inconsistency of having Mail.app trash your mail into directories you’ll never see again, or not recognize your Sent folder, you should know there’s a really simple solution.

Enter Property List Editor

Close Mail.app before editing the preferences file so it doesn’t overwrite the settings. You need to restart the app anyway, so shut it down now. I also suggest backing up the file if you’re not used to editing .plist files

1. Open up ~/Library/Preferences/com.apple.mail.plist with the Property List Editor
2. Navigate to the key named MailAccounts and open it up
3. In it are all your accounts indexed as 0, 1, 2, …
4. Find your IMAP accounts (check that the key AccountType is IMAPAccount)
5. Navigate to the keys SentMessagesMailboxName and TrashMailboxName and change them to Sent and Trash respectively

Voila, you’re all set. Save the plist file and start up Mail.app, it should now use the proper special folders (the real Trash folder, etc.) and the IMAP folders should disappear from the sidebar. Now when you delete something, it will actually go to your IMAP trash!

Well, there’s a new MacHeist, and there’s only 1 day and a couple of hours left to snag it up!