A Brief History of My Antagonism Towards Flash

I was anti-Flash before Steve Jobs made it cool. I have as much anti-Flash credibility as anyone.

For over a decade I've steered organization after organization away from building solutions in Flash, often against great resistance. I was evangelizing SVG — what I saw as the biggest opportunity for a more illuminated, open solution than Flash — back when its strongest corporate sponsor was none other than Adobe.

Aside: Humorously Adobe was leveraging SVG in their battle against Macromedia's Flash/Shockwave empire, before finally giving in and buying 'em out.

I have railed loudly against Flash on many occasions.

The Great Flash of Propriety

Yet Flash is fairly pervasive, despite my valiant attempts.

Up until around 2005 and the birth of YouTube, Flash had very little presence in the video space: That realm was dominated by Real Player, Windows Media Player, Quicktime, among others. Flash fit in the RIA niche where it displaced the short-lived empire of ActiveX and Java Applets. It was the tool for great web entertainment like You Don't Know Jack, the Net Show.

Then YouTube rose with Flash at its presentation core, and the rest is history. Soon Flash was the oddball foundation for video.

If you mention Flash today, however, the topic will immediately veer violently to the great Flash/Apple battle of 2010, where Apple has loudly rejected Flash (where it represents a proxy for "rich applications they don't control"), and Google, perhaps being a bit antagonistic, has embraced it with their Android and Chrome solutions.

Ok, embraced is probably a bit of an overstatement. In reality Google's initiatives have top notch HTML5 support, the best JavaScript performance, and are probably the best mobile/thin platforms for rich HTML5 applications, but they just happen to optionally support Flash as well, perhaps providing a bridge from the past.

A Very Personal Flash Experience

I've been running Flash on my Nexus One for several months now. I have it configured to On Demand so the scourge of animated, CPU-clogging Flash adverts don't destroy my web browsing experience. When there is Flash content that I want to view, I click the little arrow and voila, Flash is running on my mobile phone.

Overall it has been a very welcome addition to the device. From restaurant sites, to small videos like Zero Punctuation reviews, to games for my children, to product information pages, I like having the option of engaging Flash when the need arises.

So when I saw entry titled "Just How Bad Is Flash on Android" on Daring Fireball, of course I was drawn in. There Gruber indirectly linked to some demonstrations of Flash failing miserably on several Flash video sites.

To which, I say, no kidding.

Anyone under any illusion that having Flash on their mobile device opened up any and all content is willfully or technically incompetent. That or it's link bait trying to herd in the people who desperately need their biases confirmed, and a lot of people desperately need to believe that Flash isn't necessary on mobiles. I'd probably say it's that second option at play.

Of course not all content will play. This is, after all, a mobile device with a little power-sipping mobile processor. While 1Ghz sounds pretty pimp, the Snapdragon in the Nexus One is in many ways a weakling, particularly in video decoding and 3D graphics tasks where it fell behind even the iPhone 3GS.

On this 1Ghz processor I've had trouble playing local 720x480 h264 videos encoded at 1Mbps, encountering frequent stuttering and dropped frames. Compare that to the iPhone 4 which allows for up to 7Mbps+ videos at 1280x720, which it plays flawlessly, owing to the excellent hardware decoding.

When it comes to video the iPhone 4 simply kicks the Nexus One (and virtually every other HTC Android device, as HTC is addicted to Snapdragons) to the curb. Then again, the Samsung Galaxy S kicks the iPhone 4 around and calls it Sally, while the OMAP in the Droid 2/X offers a fair fight.

Snapdragon processor devices are not the top of the pile by a long measure.

So the Nexus One really isn't a great platform to highlight video prowess anyways.

Enough with the hardware excuses.

Add that Flash is often its own worst enemy: When you enable the plug-in, your enable in the Android browser is browser wide for that page, meaning it simultaneously enables the twelve punch-the-monkey animated ads surrounding it, often destroying the experience.

So there is no surprise at all that a high bitrate 1000x500 video surrounded by Flash adverts — a scenario that clogs a high performance 2.4Ghz core on a modern x86 PC (which would be equal to about a 8Ghz or higher snapdragon) — probably with a layer of DRM adding more demands, doesn't run so great on a mobile device.

"So Steve Jobs Was Right! Flash won't work on mobile!"

Given that I've enjoyed Flash on my smartphone on many occasions, I find such claims — which I keep seeing made by seemingly non-stupid individuals — ludicrous. It is fervent, desperate doublespeak.

Mobile Flash exists. It's far from perfect. The available content usually isn't even aware that it exists. Yet still, it is.

And really, it isn't a fair fight anyways. When sites provide HTML5 video, they do so often specifically for the iPhone/iPad because of the massive namespace territory they conquered. Most sites don't even feature sniff for the functionality — they don't care if you are running Chrome or Safari or IE 9 and can run HTML Video — but will instead refuse to serve up HTML 5 video for anything but those Apple devices. Given that, they encode specifically and only for that platform, with appropriate bitrates and complexity profiles ideal for those devices.

There's no big surprise that it often runs well.

That isn't a very encompassing, scalable solution though. One device family isn't meant to rule, and at some future point HTML5 will start to leave the iOS devices behind. The iPhone lived through a special moment in time where it was handled as a blessed child, getting its own special treatment, however that moment is passing.

Of course the Flash people have a solution for disparate devices, using dynamic streaming that is based upon the consuming device (resolution and bitrate scaling based upon the capabilities of the device, very similar to some technology in Microsoft Silverlight). Not surprisingly there is little use of it yet given that mobile Flash devices just started appearing very recently, and still comprise a tiny market.

"So...Steve Jobs Was Right?"

No.

When I originally thought about how to respond to this, my first idea was to make a video demonstrating a smartphone failing miserably at rendering and interacting with various HTML5 sites. But then I thought better because someone might confuse that as a serious criticism of HTML5 when I love the technology stack and pragmatically realize that it can't (and shouldn't) always be universally accessible.

Yet still, contemplate the failings of HTML5 on mobile devices:

• Layout can be ill suited for the screen dimensions and resolution of a smartphone.
• Functionality can be overwrought and too heavy for a smartphone.
• Input techniques might not work on smartphone.
• etc.

Anyone who has browsed on their smartphone or tablet has experienced all of those. If someone were looking to go out of their way to act shocked that such an experience exists, source material can be found everywhere.

Which is of course why many sites, like the atrocious script pig TechCrunch (seriously, load it up in Firefox with Firebug and check the net tab), created special mobile pages that they force you to, against your will, when you try to visit on a mobile device.

The next time you see a TOP 10 CANVAS DEMOS on your social news site of choice, pull them up on your tablet or smartphone and check out how well they work. Chances are overwhelmingly that they will fail miserably. Almost every HTML5 game demands that you use a keyboard to control it, if they aren't simply too resource demanding for a little mobile device.

So do we write off web browsers on mobile devices? Do we say, in a tut-tut-tut fashion, "No mobile browser exists. WAP is the world for portable devices!" I hope not.

Punching Monkeys Coming in HTML5 Soon To You

One trend that is accelerating is the movement of many ads to HTML5 and away from Flash. That short period where iOS devices came with an almost intrinsic AdBlock+ in the form of the lack of Flash capabilities is rapidly disappearing. Soon every page you visit is going to be a mishmash of computationally demanding canvas renders and DOM manipulations, and it's going to become much more difficult to avoid their cost.

Closing Notes

For those who are on the fence about the whole Flash thing — whether they care about it on their mobile or tablet — take a look a the quick video I put up above. The videos did not run perfectly, the auto configurator didn't provide a seamless, perfect experience...yet if the option is that or nothing, I think most reasonable people would agree that it's better than nothing.

No, not really.

What a thoroughly boring discussion that has distracted the entire tech industry. So many incredible innovations happening, yet everyone's talking this minor bit of errata. Move on!

It is further evidence that smartphones dominate the technology discussion now, with desktop technology fading into the noise. Intel is quickly preparing their very competent assault on the field with the Moorestown processor. It promises some exciting times ahead.

Backtracking on 802.11n with the N1

On the topics of product issues, in a prior entry I noted that I had been enjoying the fruits of 802.11n with the Froyo update on the Nexus One. Shortly after that entry, another update was pushed, FRF91, and my connectivity has become almost unusable unless I disable 802.11n on my wireless router (which was actually the case when I first got the phone, but FRF85 had provided salvation). So now I run two WAPs, with one to serve the 802.11n devices so I needn't cripple it for the N1, and a 802.11g one just to service the smartphone.

On High Density Smartphone Screens

With all of the talk about very high pixel density phones, and the downside of larger-screen phones, the focus of most discussions seems to be purely on the visual clarity of the screen. The actual usability of the on-screen content seems to be ignored.

On the Nexus One I'm dealing with a 252dpi (there is some fakery with the pentile pixel arrangement, but ignoring that), 3.7" screen. A site like the New York Times looks fantastic in landscape mode, with a fully readable presentation of the entire real-web contents. Yet the downside of that high-density, small screen becomes evident when I actually want to interact with the content on the screen. Something as simple as clicking on the category links down the left hand side is an exercise of extreme precision: Each link is approximately the size of a single fingerprint ridge, and they're so densely packed that a mm this way or that way yields the annoyance of a wrongly followed link. Zooming and unzooming just to interact with the screen isn't very enjoyable, and it erases many of the advantages of the pixel density.

Screensize is important, and smaller isn't better when you're talking about a device that doubles as a mini-web appliance. There is a balance to be achieved or the experience is compromised.

“Fragmentation? What Fragmentation?”

The Android Developer’s Blog ignited a firestorm recently by publishing an entry on the purported fragmentation of the Android ecosystem.

It’s worth a read. Too bad the same can’t be said to most of the responses to it.

When the topic concerns either Android or the iPhone, and the arguable failings of each platform, it’s seldom debated by people genuinely interested in seeing the target of their criticisms improve in any meaningful way. Instead it’s pundits (less generously called fanboys) hoisting their flag, pushing in for their chance to line drive some talking points.

Rabble rabble rabble, Steve Jobs will eat your firstborn

Rabble rabble rabble, Android is fragmented and anarchist.

It is noise that seldom inspires or enlightens.

On Android Fragmentation

We have a problem, Mountain View.

Some handset vendors are lagging on upgrading their devices, if they do at all. There is a wide disparity in performance and functionality among devices, leading to unpredictable user experiences.

It parallels the dark days of Windows Mobile, when unloved devices were shat onto the market and promptly forgotten, the vendors more interested in prepping you for the next iteration that, they assure you, will fix all of the problems of the last.

For those writing application targeting Android, such as myself, there is a need to carefully consider the current version breakdown, choosing the target that offers the minimum functionality you need without restricting your market too much. You need to perform the same analysis on the target hardware capabilities, as the simple reality is that a rich graphical 3D application won’t run acceptably on a wide range of deployed Android devices. A high-end game might run well on a Samsung Galaxy S, for instance, while being unusable on every other Android device.

Do you target 2.1 and take advantage of Quick Contacts, for instance, and limit yourself to 45% of the potential customer base, maybe preparing yourself for the future? Or do you target 1.6 and simply go without those refinements? Do you build a 3D rendering interface that will choke on all but the latest handset, or do you cater to the lower common denominator?

It’s a serious concern. There are brand new Android devices that are hitting shelves today with Android 1.5 on them. There are new devices with mediocre processors, limited memory, and barely functional GPUs.

Isn’t that weird? It isn’t optimal.

Add that there are all of the various skins that the vendors put on their devices to differentiate: HTC’s SenseUI, Motorola’s MotoBlur, Sony’s Rachael, among others.

Android devices come in all sizes and capabilities: There are big screens and little screens; devices with keyboards and those without; cutting-edge super phones and feature phones on steroids; tablets and netbooks; processors with NEON instruction sets and without; with SSE or without.

An Android device is not a homogenous experience for either users or developers.

Crazy isn’t it? Anarchy reigns! Contrast this to the land of iPhone where there is a very strong uniformity and development consistency among experiences and development and devices.

Shouldn’t Android be more like the iPhone? Shouldn’t Google lay the hammer down and demand that vendors refrain from customizing, they upgrade in lockstep, they build a consistent, uniform platform, and nothing deviates from the reference implementation? Everyone building a Nexus One with a vendor label on it?

No way.

Fragmentation is the Reason the Android Platform Has Succeeded

The progress of Android over the past year, or even just the past 6 months, has been nothing short of extraordinary.

From being a marginal wannabe, largely adopted by those ideological few willing to turn a blind eye to its many, many faults, Android is now a very serious competitor among mainstream consumers.

It’s an accomplishment that Google could never have pulled off alone. They needed a lot of help from a lot of very capable partners, and their strategy with the Android platform and the Open Handset Alliance is entirely the reason we got to where we are today.

HTC, Motorola, LG, Samsung, Sony, nVidia, Intel, ARM, among a slew of others…a lot of very smart, very capable companies working to make their own success story, pulling up the Android platform at the same time.

Motorola wants to sell you a Droid, yet by investing so much into making their devices a success they’ve build an ecosystem where you benefit from their success even if you choose another vendor’s phone.

Fragmentation is progress.

Instead of releasing a single iteration yearly, a single lockstep uniform device and experience, a Darwinist battle is taking place, the best choices and experiences triumphing. The Evo 4G is hitting shelves today, yet already we’re hearing about the next superstar, a purported HTC Scorpion device with a 1.5Ghz processor coming soon.

When people argue that Android should be more like the iPhone, they lose sight of this very beneficial side effect of the so-called fragmentation.

If Google ran the Android platform like Apple, it would have been a Buzzesque flop. It would have failed miserably.

But they didn’t, and it wasn’t. We are where we are.

So where are we?

Well firstly, most of what you’ve read about Android fragmentation is bunk. Horror stories about incompatible apps and terrifying development processes are largely exaggerated.

But there are some issues.

Google Earth, Google Goggles and the official Android Twitter application (an excellent application that was built with Google’s help) all require Android 2.1 or above. It’s fairly obvious that Google intentionally limits the best to a recent version in efforts to motivate vendors to hasten their upgrades, and to showcase the most recent platform additions, such as the animated backgrounds in the Twitter applications.

Those are the reason that customers demand that vendors update their phone, and it helps keep them motivated to push out upgrades. Motorola just released the Backflip on 1.5, and Sony released the X10 on 1.6. Both of them have gotten a lot of criticisms in reviews for this choice, and they both will pay for lagging behind. Their motivation to get upgrades to the market quickly is very strong.

As a developer, when you develop an application you need to target a given version knowing that you’re cutting out anyone running something older (thus cutting out some prospective customers). In a subset of cases you can target an old version and optionally target newer features using runtime reflection and feature sniffing.

And there are compatibility quirks. In developing an app that integrates the camera I’ve encountered a number of issues, including devices that invert the preview output, some that only return greatly scaled down pictures when a picture is taken, among a variety of other little variations and surprises, and that’s just among the devices I’ve tested with.

There are known issues when dealing with OpenGL where some devices demand a certain magic quadrant of environment conditions to operate at their peak.

All in all, though, it is an absolute walk in the park compared to most other development efforts I have pursued. The Android SDK abstracts most everything to a shockingly effective degree, and the very clever, HTML-like (and thus XAML-like) layout manager allows you to very effectively run your application on a huge variety of displays.

You can build high-performance code in the NDK, including hand-crafted ARM assembly, but you can do it in a way that will only optionally be used if the right conditions are available (e.g. an ARM processor with NEON instructions), otherwise falling backed to a managed version.

In many ways writing to Android is a bit like writing an HTML5 application. There are quirks that you have to deal with on some clients, but they’re mostly known and documented and fade away as the clients move closer to the specification, without restricting the innovation and uniqueness of the individual clients.

Everything about Android is built to abstract from the device, from the virtual machine runtime to the density-independent pixels to the layout manager’s multi-dot-pitch resource utilization (I would have preferred that they used vector graphics, such as SVG, but it’s better than nothing).

If Android is HTML5, then the iPhone is ActiveX

When you develop for the iPhone, you develop for the iPhone. With the iPad there’s one additional form factor, but the universe of clients is extremely limited and of little variance. With the new iPhone there are rumors that it will see a simple doubling of each axis’ pixel count, allowing the system to simply pixel double previous applications.

It’s a bit like developing for Internet Explorer back in the early 90s: Everything was grand and entirely consistent and uniform, and in many cases you could just target an ActiveX control because you could make so many assumptions about your target.

There is limited variability build into the iPhone SDK or development process, and those hurdles are crossed when they are encountered. When the iPad came out, they updated the SDK to deal with the second screen size. The new iPhone SDK added the ability to deal with the new pixel density.

It makes a developer’s life simple. But it also seriously hobbles the rate of innovation and the ability to adapt to change.

It’s a Long Term Strategy

In the short run the single-target approach – the ActiveX approach – wins. In the longer run those early gains disappear, especially when you’re moving uniformly (“non-fragmented”) against many speedy opponents.

Just take a gander at the comments on any Android market share story. Just a few months ago it was gloating damnation as the iPhone ecosystem dominated the Android platform. Now it has subtly shifted, and the argument has moved from "iPhone dominates!" to “You can’t compare the many Android makers against just Apple! Apple still beats HTC!” It’s quite a shocking adaptation, and of dubious merit: As a developer I completely care about the platform saturation, not whether a phone is a Motorola or an LG.

And of course Apple does as well. There are millions of iTouch and iPad devices that don’t get counted in smartphone surveys, and they give iPhone targeting developers a staggering lead still, but we’ll see for how long.

Some recent NPD data showing the Android platform overtaking the iPhone in the US has set the web on fire. Apple apologists like John Gruber are working overtime to try to spin it.

Remember back when Daring Fireball was actually an interesting site? Now it’s like I imagine Pravda was during the Cold War.

In any case, I was a little shocked to see the gains come this quickly. Android was obviously making a dent, but I expected another generation of products to flow through the market – like the Incredible and the EVO 4G, and eventually the long-anticipated onslaught of Dell vapourware – before Android really took hold with mainstream consumers.

And of course iPhones are still selling. They’re selling like hotcakes, for that matter: Apple reported a more than doubling of sales during the period in question (kind of undermining the notion that it’s some sort of calm before the 4G storm).

At this point smartphones have a limited market saturation, which is why it’s a critical juncture and why there’s a bit of a race to perform a land grab. It remains anyone’s game.

In a year we might be looking at the emergent dominance of Windows Mobile 7 phones. Or maybe the next iPhone model will storm the market. Or WebOS will be reborn into a real contender. Or maybe Blackberry – the strangely unmentioned leader of the pack – will really wow the market with their next cycle.

It is critically important that there is competition in the space. Competition is great for everyone, including for iPhone users (see the upcoming multitasking that is a virtual clone of the implementation in Android). The market can’t be dominated by one vendor, especially one with walled gardens.

Speaking of walled gardens, as much as HTML5 got talked up during the Great Jobs-Adobe War of 2010, in reality HTML5 performance on the iPhone and iPad is abysmal and is close to unusable for rich content.

The real alternative to Flash on the iDevices has been native, single-platform, completely-proprietary apps. Which is arguably a perfectly fine approach (take full advantage of the platform and all), but it was incredibly frustrating seeing HTML5 used like such a cheap sacrificial prop during the debacle when it really had perilously little to do with the debate. It was so grossly dishonest.

Of course I’m speaking outside of videos. For videos Flash is almost always a completely unnecessary wrapper around an h.264 stream (which is what many Flash videos come encoded in these days). Separating the video from the container is a no-brainer.

Obviously HTML5 needs to keep improving. With Android 2.2 around the corner there are wide expectations that they’ll introduce a JIT compiler for the Dalvik engine (“native” apps largely run in a VM runtime and are currently seriously hobbled by the lack of optimizations in the same), and it would be fantastic to see something like V8 for the browser as well. While the platform has far-and-away leading canvas and dynamic graphics support, it falls behind in scripting and that would be a nice gap to eliminate. It would be nice to see a decent dynamic HTML 5 capability built into iPhone OS 4, as currently it is seriously deficient.

Why the web should be destroyed, by Steve Jobs:

“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

I tried to ignore the whole section 3.3.1 debacle, as I’ve already commented on Apple’s moves and motives too many times, and really this change is just a new wrinkle of existing restrictions: developers for the iPhone are already subject to the capriciousness and fickle whim of Apple, with no recourse.

If Apple said that you have to wear a purple bow-tie while developing for the iPhone it would arguably be a change for the better. At least then you wouldn’t have uncertainty on the whole bow-tie color issue. From that perspective, Section 3.3.1 should be a welcomed clarifier.

While claims that it’s for the greater good of quality are discountable as a ludicrous smoke-screen, if you were gullible enough to believe that, and you accept the asinine notion that development technology dictates app quality, is Apple promising to filter app submissions by quality?

Given what is already in their app store they have a lot of pruning to do.

They could carpet-bomb out the crapulence, with acceptable collateral damage, by banning any apps made by small development shops. This would be great for everyone, right?

Kudos to them for removing consumer choice: If someone liked an app created via one of the targeted tools, clearly it’s because they don’t know what’s good for them. Personally I choose based upon reviews and user ratings, but it’s a win if these sorts of personal decisions are made for me.

Like I said, I’m not going to get drawn into this whole section 3.3.1 debate.

So let’s get back to Steve Jobs’ statement above.

“We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

Where do web standards fit into this equation, given that web standards are almost perfectly defined as intermediate layers between the platform and the developer.

Stop. Pause. Seriously think about this. Imagine that Steve Ballmer was saying this about SVG (just use GDI and DirectX or at worst VML) and JavaScript and the canvas element, while discussing banning non-ActiveX controls from the Windows ecosystem.

Where does Steve Jobs think the web fits? Is it just a convenient stop gap?

We know that Apple’s existence through the lean years, and then its resurgence, was made possible because of the cross-platform web, and paradoxically because of the cross-platform Flash technology. iMacs sold to the general population only because they knew they could still use the open web, consuming and interacting with apps that could certainly have been built richer and better if they targeted just the Windows platform.

They could use the popular sites, read the news, do their banking, pay bills, and send eCards, despite being on a platform used by only the very few.

Yet now Jobs has made it plenty clear that the web is for trivial, simple stuff. For richer apps you need to target the iPhone alone, using a process that in no way can allow you to target other platforms as well.

Flash is a no go because it enriches the web – there’s a lot of hate out there by people who know Flash only as a simple video player, where it punted Apple's QuickTime it’s worth noting, and as a platform for irritating ads, however as a parent of young kids I see Flash as the enabler of an incredible array of rich and entertaining educational tools for kids (PBS Kids, TVO Kids, CBC Kids, Disney Kids, among countless others) – and Apple has done nothing in the mobile web space to make up for the gap…because at that point you’re supposed to bridge over to the iPhone market and embrace it with fervor and loyalty. Sorry, but no thanks.

More Apple/Android Junk?

I have so many things I’d like to write about – topics having nothing whatsoever to do with Apple or Android, like IoC, ARM assembly, rational NoSQL, and of course pragmatic software architecture – but various mobile issues keep mentally demanding that I hop up on a soapbox about them for a bit. I have to get this out of the way.

Mobile computing is absolutely the most important realm for this industry over the coming decade, so pay attention to what is happening because it really, really matters.

CIBC – Leader and Innovator, or Me-Too Wannabe?

The CIBC Platinum Card

CIBC, a large Canadian bank, just launched a nationwide advertising campaign to promote their newly released iPhone banking application. You can see the video on YouTube.

It's notable that CIBC isn't targeting iPhone-only venues with these ads, which they could easily and cost-effectively do, but instead they are promoting this during primetime Olympics coverage. They're putting it front and center on their website.

If you caught the commercial you might have mistook it for an Apple ad, given that the strongest takeaway is a subtle "there's an app for that" message, followed by the implicit declaration that iPhone customers – a small minority of CIBC customers – are the elite, their walled garden needing its own special flowers.

Maybe Apple subsidized the ads and the product itself. It’s a little surprising for a large and profitable bank to look for ad subsidies, but it’s the only conclusion I can draw.

It’s either that or CIBC has an Apple fanboy wreaking havoc from the executive level.

In any case, big deal: CIBC makes an app for the iPhone (first bank in Canada to do so, they proudly boast). Just serving customers, right?

Consider that CIBC has never offered a rich-client Windows application for banking, which is a statement that is true for every Canadian bank as far as I know.

They will let you download data to Quicken or Money or what have you, on whatever platform you’d like, but if you want to bank electronically as an end-user the cross-platform web browser is and has always been your electronic banking tool, even when it limited them to a very simplistic interface.

They knew not to fall into the ActiveX quagmire like, say, South Korea. The banks have always supported just about any modern client equally.

Think about that for a bit: They have never directly supported the rich interface of the overwhelmingly dominant client platform for PCs.

And for very good reasons.

Yet now they have special, premiere support for one far-from-dominant Smartphone.

Given that history of device and platform treatment, it’s natural to presume that they have some fantastic and compelling reason for making this change: Maybe they’re using amazing 3D graphics of money flow or something on the device. Maybe a breathtaking augmented reality experience that allows you to visualize your debt load increasing when the camera is pointed at that new must-have device you really want at the electronics superstore, a virtual banker sternly shaking his head no.

There must be something that they just couldn't do without "going native", right?

Nope.

Their iPhone app features shockingly basic functionality. The single place where it could use something even remotely client-rich – to get the user's location to find the nearest branch – they screw it up and force you to type your location in.

This Is What Web Apps Are Made For

This Is An HTML5 App on the iPhone

This application was made for HTML 5, which humorously would easily allow them to use the Geolocation API to get the user's current location for richer and more intuitive mapping.

And let’s give credit where it is definitely due: The iPhone features excellent web app support, arguably best of class, likely because that was originally the only way to create applications for the device.

Jobs’ original vision was that the phone would offer a native Apple experience enhanced by a rich and robust web application ecosystem. That was the phone that they originally delivered.

That web richness allows you to make apps that look and act just like an iphone application with some simple targeted styles and scripting, offering rich and robust functionality and features.  It also allows you to avoid going hat-in-hand through Apple's app review process for every update, as is demanded when you publish via the App Store.

So imagine a world where CIBC decided that they didn’t need to kneel in worship before Apple, trying to suck some Apple-idolizing droppings from the dirty ground, and they’d release this as an HTML 5 app.

It would feature the same look and feel, could easily support all of the same functionality (without breaking a sweat). It would almost certainly be far more maintainable, and could function like a minimized version of the web app they already have for PCs, without necessarily demanding new public-facing web service APIs.

Win all around, right? Well that’s just the start.

If CIBC did it the correct way – as an HTML 5 app – it would also work on Android devices (including crazy features like local databases and geolocation and all of the snazzy dynamics), such as the hot new Milestone coming to Telus, and the anticipated Acer Liquid and Sony X10 coming to Rogers, and more importantly – this is the land of RIM – it would work on the newly revamped Blackberry webkit browser coming shortly, which is worthwhile given that Blackberry remains atop Apple in the “smartphone” category, especially here in Canada.

Remember that Apple far from dominates the Smartphone category, and competition is only getting fiercer. Canada has never been as iPhone-crazed as the US, and a number of compelling non-iPhone smartphones are just hitting our shores.

So if they went the HTML 5 route, they could offer a rich experience on all capable devices, easily stylable and feature-scaling to optimize the platform experience. Anything would be better than the WAPishly rudimentary "everyone else" dumpbin interface they currently support for every other mobile device.

Didn’t They Listen To Steve Jobs?

Juxtapose Steve Jobs telling us that the iPad doesn't need Flash because HTML 5 makes it irrelevant – a premature statement, but the time will come when his words will seem prophetic – with organizations like CIBC porting absolutely rudimentary web functionality into native apps, wasting time and resources and cash, primarily benefiting Apple, while undermining marketplace choice.

Very backwards move, CIBC. It doesn't make you look hip and on-the-ball, but instead makes you look like Apple-salesmen hoping for your little bit of me-tooism hipster credibility.

Given how boastful CIBC is about being the first bank to feature an iPhone interface, it would be delightful to see another Canadian bank, such as my old workplace RBC, take the high road and come out with rich and robust mobile web apps that don’t favour one walled garden without cause.

They could show it running just as richly on a Blackberry, gaining benefit from the glow of Canadian patriotism.

A Place for Web Apps and a Place for Native Apps

While Jobs is quick to declare the end of Flash in pitching the iPad, the reality is that there are serious gaps in what HTML 5 web apps are capable of.

Graphical games, for instance, aren’t a web app reality without either adding Flash to the equation or going native (e.g. OpenGL on Android or the iPhone). Some day down the road it will be possible, but that isn’t reasonably the case right now, aside from some tech demos that make a high-end desktop grind to a halt.

Apps that exploit special features and functions of the hardware generally can’t be web apps either, at least until the feature is so common and prolific that it gets baked into the shared standards, as geolocation has. I’m sure at some future point we’ll have “camera” and “webcam” and “DSP” APIs to access from JavaScript, but for now those are native app domains.

Mr. Jobs’ statement could more honestly be worded as “Flash isn’t necessary when you have HTML....and apps from the Apple App Store”.

Platform specific apps are needed for a lot of solutions. That goes without saying.

Still, porting absolutely rudimentary functionality to native apps is a backwards repeat of mistakes made in the past, walling the garden off for no logical reason.

CIBC is hardly alone in making this foolish, foolish move, but given that they seem to be so proud of this mistake they deserve particular criticism.

So You Own An iPhone and You Don’t See The Problem

My Youngest Doesn't Have an iPhone...yet

Even if you own an iPhone, and you happily imagine a world where your children’s children will have iPhones, you should still view moves like CIBCs with intense cynicism.

Not only are they limiting your choice unnecessarily if you ever decide to consider alternatives (as everyone should always be doing), even if you’ve declared fealty to Apple forever and ever the movements of organizations like CIBC are diminishing Apple’s need to be competitive.

Recall what happened to Internet Explorer after so much of the web (outside of Canadian banks, notably) decided that they would treat IE users as first class citizens, everyone else ignorable chumps. Once that lock-in was established Microsoft had little incentive to work on their browser and they took their users for granted. We’re still trying to pull ourselves out of that mistake.

Apple isn’t Microsoft, but by the end of 2010 they will likely exceed Microsoft’s market capitalization, which is absolutely shocking. Corporate sludge is inevitable at some point. If something happens to Steve Jobs, for instance, and they recruit Ballmer to run the place, you might decide to consider alternatives only to find that you're tied to the platform in a thousand seemingly minor but cumulative ways.

Competition is good. Building up the walled-garden of the iPhone undermines competition, and encourages a foolish Windowsification of the mobile world.