“The biggest mistake we made as a company was betting too much on HTML5 instead of native… We burnt two years.”

http://www.theverge.com/2012/9/11/3317230/mark-zuckerberg-betting-on-html5-for-mobile-was-a-mistake-hints-at

I’ve seen some holes in a few of the blogs & commentary that I believe need plugging.

1. Companies have no choice, they have to have an HTML5 Strategy

If customers access your website on a device, it needs to work. If that is simply 1 page that provides a link to your iOS app store or Android Play store app, fine. SOMEONE has to build that web page and ensure it works on that particular set of devices.

Alternatively, it could just be your existing website that you’ve ensured renders reasonably well on iPhone, iPad, and Android. That, or whatever your analytics are telling you. Remember, interpreting quantitative data is key; just because 1% access your website on iPad could mean because it doesn’t work, hence they stopped trying.

Metrics have shown that consumers do not like “Download our App” as whole screen, first pagers. Metrics have also shown that if you show that screen without an easy way to use the site, they leave.

Conversely, for larger web applications, it’s not as simple as using “responsive design” (yes, I said it, take a shot) and calling it a day. In large companies with larger web properties, you’re talking multi-month initiatives to get a 3rd party agencies to respond to an RFP/RFQ, pick one to pitch an analysis of the companies mobile needs, design it, and Directors to figure out if you convert your existing code base or start anew, not taking into account the different API needs that may arise on the server-side. Sometimes stop-gap plans are put in place to give the user SOMETHING so they can at least be productive and/or it ensures the brand isn’t significantly hurt whilst larger initiatives get underway.

Also, some apps can only be downloaded on wireless.

For these reasons: web only access, app incompatibility with device, user experience, and lack of wireless.

Notice NONE of the above has anything to do with cost, developers, or user experience. It’s a fact that users surf the web on web browsers on their devices and expect things to work without having to download an app. If they use it everyday, it’s proven they’re more likely to download an app.

Until iPhone, iPad, and Android remove their web browsers, companies HAVE to have a mobile web strategy, period.

Web applications are a completely different story.

2. Web Application Cost Structure

The marketing goes, “Use HTML5 because it is ubiquitous, and the majority of your code base can be reused between various devices using responsive design.”

That is simple statement that varies in truth depending on what you’re building. A simple website with text content? Sure. Anything more complex, and the question’s answer gets more complex. As you know in software development, complexity == time and money and risk.

For some companies, the increased opportunity mobile usage by consumers covers the cost of new or additional development. For them, native’s a shoe in, as is an HTML5 strategy along side the same teams, even if different companies. For others, they make bets on the technology stack for a variety of reasons. Maybe they only know Android developers. Maybe it’s hard hiring Objective C people in their area with their small hiring budget. For whatever reason, they have to make a cost analysis of the software stack. As Patton would say, this is a “calculated risk”.

Part of that risk assessment is eyeing the current landscape, seeing what was built with the existing stack already, comparing the end product with your current teams capabilities, and sallying forth with much gusto. For others, they don’t have time, they’ve been at this for so long that they know stack often times doesn’t matter. So they sally forth.

The problem with both of the above is that if you’ve done any startup work, you know you sometimes have to pivot. These cannot be predicted, they’re in direct response to both user/customer feedback, stakeholder input, and leadership judgement calls. Can your stack support enough leeway? THAT is hard to predict.

Even if you’ve done a great analysis of your market, your existing product portfolio, your customers’ needs, your technology stacks’ capabilities, your team’s capabilities, hiring prospects, you could still gloriously fail when you hit scalability problems you can’t quickly recover from, or client-side rendering/performance issues that make you re-think you’re entire architecture, even when you’re team has had a lot of sleep and is in a good state of mind to make such a reflective decision.

Just keep in mind not everyone can afford 5 development teams when they used to have 2, or keep 5 afloat and deliver the same expected capabilities form consumers. Everything has a price. Sometimes the increased opportunity pays for that, sometimes it doesn’t. Even if it does, there’s no guarantee you can deliver even with a great cost & capability assessment.

3. Even Great Developers Can Suck

Back in 2006/2007, Yahoo, to compete with Google maps, re-did their maps in ActionScript 3. Right out of the gate, it had some massive performance lag on the server delivering map tiles compared to Google Maps. I also noticed they were not utilizing any of the Bitmap API’s that Flash Player provided for increasing performance of large and many bitmaps. I also knew one of the developers and knew he was great. The press didn’t see those things. AJAX developers didn’t see those things.

What they saw was Flash sucked, and Yahoo wasted their time and choose the wrong technology.

What we Flash Developers saw was Yahoo “doing it wrong”. Here was a golden opportunity for a flagship example to prove to all the haters they were wrong.

If you’ve been in software development awhile, you know a huge percentage of all of the failures are not the developer. They’re leadership and management. Basically people, not code. You get ANY of these dudes who’ve worked on high profile projects like that drunk, and ask them about the drama, it’s insane. It’s hard enough with the pressure, with the multi-team challenges, with the deadlines, let alone good old challenging software development… now you add drama on top?

We currently do not have transparency into how Facebook executed on their mobile app. What we do know is that many assume HTML5 is either:

A. still awesome and the Facebook developers suck and “did it wrong” despite proven hiring practices to the contrary

B. sucks, and I told you so, duh despite many HTML, not HTML5, apps that are wonderful and a staple of the online world today (Facebook, Gmail, Google+, Harvest, Freshbooks,etc).

If you’ve ever actually shipped software, you know it’s hard and it doesn’t always go exactly as you planned. Just because Facebook is Facebook doesn’t make them an alternate reality of software. No, for that, we have Google.

Conclusions

Users have web browsers on their phones and iPads and expect them to work.

Companies do not have scientific ways to ensure the technology stacks they choose are “correct”. Failures happen all the time. We’re just hearing about it more so because of all the hype for HTML5 + Facebook hiring who they hire + their falling IPO. The market is currently laser focused on this use case as some qualitative proof of some preconceived notion.

Unless you developed the Facebook app, you don’t know what really happened. You can do all the DOM vs. CSS rendering debating you want, but even if there were some leadership issues, a more likely scenario was #2; Facebook didn’t anticipate the amount of features users wanted and pushed the HTML5 envelope on mobile. Good for them. They have the capital to do cool things like that and re-invest into native mobile solutions. Not everyone does and we should be thankful they have continued to talk openly about their HTML journeys.

Regardless, native performs faster than HTML5, has more mature tooling, and better languages for larger applications. For consumer focused companies, you can actually monetize those without an existing platform.

That said, web browsers aren’t going anywhere, and people will continue to use them. HTML5 isn’t going away just because Facebook’s users wanted faster mobile apps.

I’d be lying if I didn’t admit it’s nice to see a large company have buyer’s remorse like all us cynical, bitter ex-Flashers said was going to happen. It’s lessened by maturity (yes, I’m getting there), and the fact that this was more user driven than HTML5’s fault.

I’m glad I went to RIA Unleashed this year. First year run by the FITC crew who always have their act together. I always like the crowd in Boston. This year was different for a few reasons.

Corona

I gave a 4 hour work shop on Corona SDK by Ansca Mobile and Adobe AIR for mobile gaming. Some of the Flash Lite team members formed their own company and created Corona, a way to build games and simple applications for Android and iOS. Through a performant, built-in Box2D physics/collision engine, light weight language & API, and partnerships with other social services it has scored a lot of points with people trying to hit the simple gaming & app market for the Indie’s, those learning, and those looking to reduce complexity in their development stack.

The AIR part was a little frustrating because things are extremely in flux right now with Adobe’s stack. The future of Flex is mobile applications. The future of Flash Player is low level functionality to support as high end gaming as you can in browser. The future of the Flash IDE appears to be supporting this gaming & mobile workflows. However, none of the gaming engines & supporting frameworks are mature enough yet, most are browser focused vs. mobile, and Flash Player’s new GPU related display mechanisms aren’t in AIR 3 for devices yet. They will be soon, the landscape itself is in flux, and “learning” to develop “games in Adobe AIR for mobile” will be changing big time for the next 12 months as we wait for the tech to hit devices and the libraries/frameworks to morph/be created to mobile work flows.

I really REALLY enjoyed teaching the Corona SDK. It’s been a LONG time that I’ve gotten to speak on something I enjoyed and had ZERO to do with helping my fellow devs build their skill set for their career. This was, “Learn this, it’s fun!”. Granted, I tried to give an overview of the consumer business landscape regarding paid vs. ads vs. micro-payments.

The trend I’m seeing is those building games, once they see Corona, are blown away with how simple it is, and what you can produce with very little effort, regardless of their background.

Sitting in on some of Jesse Freeman’s HTML5 gaming with ImpactJS session, it’s also very clear there are some great minds working to ensure HTML5 is also a valid platform for gaming. It also pointed out some gaping holes of needs in AIR and Corona gaming with regards to helpful libraries and toolsets.

I may not see any money from this, but damn is it fun and great to be learning something development related that’s out of my comfort zone (…and that’s not Sales or Biz Dev related).

JavaScript

I met this kat named Doug Neiner. He’s part of the jQuery team and is the perfect example of what the negative detractors against Flash/Flex think we should be like. Naturally, I did everything in my power to screw with him and learn everything I could in the short time I spent with him.

In our first meeting at dinner, I spilt my beer all over myself and let him think he did it. He was overly gracious and apologetic. And sincere. We chatted about guns. Damn.

I even tried to screw with him regarding religion. He took that one in stride too. Not insecure. Damn.

So finally with more liquor in me we got into a long discussion regarding JS devs perceptions of Flash, misconceptions about what they get paid, and how they develop, what frameworks & design patterns they use, the nomenclature, and basically every question I could possible think to ask with Andy to help mediate. He did a bang up job considering our language barrier (I butcher and give no respect to true meanings of Design Patterns). He was very forthcoming with information, tactful, unapologetic, and sought to understand. I learned we have a TON in common. I mean like 90%. Damn.

I suggested we do a code review of some of the Flex projects I had worked on in the past. The next day we briefly did so. It was eye opening to see the code they wrote after our previous nights conversations. It + the techniques + the patterns + the lingo seemed very familiar.

They do all the same shit we do. Seriously. What’s truly different?

1. Their display list is slow, ours is fast.
2. They thusly use CSS to not only off load display list redraw code, but save having to write a lot of JavaScript because of it. Most Flash/Flex devs don’t. Our CSS isn’t true CSS and doesn’t handle a lot of mouse/keyboard/touch events.
3. They have to remember what works in what browser on what platform, and remember the already created/solved fallbacks.
4. They are now creating, and getting paid to do so, some of the same types of browser based applications that we do.

That’s it.

For those of you who bring up loose typing, let me just say every single person, me included, who’s gotten used to JavaScript and closures does just fine (doesn’t mean they love it). On smaller projects. Additionally, the amount of tools regarding code coverage, testing frameworks, and other language pre/post compilers out there for JavaScript is solving the problems they have.

I now understand why Flex is 100% focused on mobile. You can’t fight that encroachment, half being true, half being hype with real money behind it.

While the larger scale browser based applications may suffer from lack of a strongly typed language, it’s very clear the JavaScript community has enough resources behind it to “figure it out”. Even if that takes 5 years.

My short time with Doug was great. He’s a really nice guy, helpful, and is extremely hard to take the piss out of. We have much in common with our browser brethren.

What remains to be seen on the technical side is how they handle Enterprise sized applications. Most I’ve seen is coded on the server-side and the client is generated (Google’s GWT, Microsoft’s .NET, Oracle’s ADF, Python/Ruby HTML templates). This is not how these guys develop; they develop just like us. They’re deep into the client code and browser and design. They do the work we do.

What I could gather is most is currently offloaded to the server, but based on some of the projects Doug showed me, it’s very clear traditional Flash & Flex applications (not websites nor widgets) are next in line.

It’s also very clear the jQuery team scored big time getting Doug on board. He is whip smart, passionate, and has good character.

Leadership

Which leads me to leadership. It was very clear a lot of people are lost. I’ve seen it online for awhile, but seeing it in person confirmed it. For 10+ years Macromedia & Adobe have lead us technologically. Now they’re not. (paraphrasing Freeman here… or maybe I’m not… *ahem*) Many of our thought leaders have either left or haven’t recognized their responsibilities. In in the past, I’ve done my best to petition people like Brandon Hall, Keith Peters, and others to recognize what happens when they disappear or do certain things without context. Even normally secure people get the insecurity of the masses leaked upon them like spittle in a violent scuffle. This affects them.

It’s not just us. Microsoft is really taking some bold (crazy?) moves with Windows 8. While Apple recognizes some people drive trucks (Desktops and Laptops) and others cars (mobile) and thus made 2 OS’s for each platform, Microsoft is forcing both into the same OS. While Silverlight still has a lot of value and a future, it’s very clear where Microsoft is heading. Those who don’t wish to ride the Silverlight wave have left to other techs, or migrated back to the Win32 land.

Mobile development itself is still in it’s infancy. We have extreme hype continually thrown at us, yet the toolsets are still growing and changing. While some companies are making a lot of their revenue either partially or wholly from it, the “RIA” aspect doesn’t seem to have transitioned to the Flex and Flash world yet. Keep in mind, this could be because I’ve done zero marketing on what we’ve accomplished on mobile regarding our mobile Dashboard and my mobile gaming & mobile application work. I’m starting to hear about (from FITC Toronto, email, and Twitter convo’s) more and more Agency mobile work. If the consumers are paying, and companies are paying agencies, then it’s only a matter of time before it gets into the Enterprises and startups wishing to fund applications for B2B.

Either way, it’s very clear a lot of people are either picking a path that seems safe, or one that pays the bills. Only a few are saying, “This is fun AND makes me money, I’m going here.” If they do, they don’t define if that money actually pays for their mortgage/rent.

It was clear that there is still a lot of uncertainty, about the tech, business, and political landscape both here in the states and internationally. Thus there is also a ton of opportunity. While I’m disappointed a lot of people I respect haven’t provided what I perceived as much needed guidance in these confusing times, I get why a lot of them don’t. It gets tiring justifying obvious things after awhile. I get tired of telling my 2 year old no, but it’s my responsibility as a parent. Others aren’t the “parents” of the industry, but the power of their words, insight, and confidence about the future really do soothe the masses in ways they may not fully understand. I swear I’m not projecting; I see the impact on people not having their thought leaders spout a direction.

Conclusions

RIA Unleashed is clearly in good hands, FITC did a bang up job. Work shops are fun, I’d love to do another, especially for a younger crowd at a local school or something. It’s very clear from my Refactoring preso I need more imagery to convey humanistic challenges in programming. The next consulting article I do, I’ll remedy that.

It’s also very clear there isn’t clarity the future yet, at least for Flash/Flex devs. If you want to do Ruby, Python, or Java on the server, you’re golden. If you want to do iOS or native Java for companies on B2B and some consumer offerings, you’re set. The Flash agency landscape is very confusing to me, I have no idea what’s going on. The Flex landscape is the same as it ever was. While Adobe’s mostly focused on mobile, there still seems to be a lot of people who aren’t using JavaScript/HTML/CSS on the client for large scale apps yet; if they are, it’s server-side generated. I’m not hearing anything yet for Flex 4 mobile work. I personally blame Adobe’s lack of hard marketing about how awesome it is to build mobile apps in Flex, Europe’s debt, and the USA’s budget woes. Maybe end of 2012 we’ll start to see a change when the bigger companies get balls to start targeting the growing demographic who wants apps vs. websites.

For HTML5, it seems the huge push is out west. While I occasionally hear about growing JavaScript/HTML/CSS application projects here on the east coast, it seems business as usual, and in California/the valley, business is unusual. i.e., we don’t care if this technology is inappropriate, if you say HTML5, we’ll give you tons of Series A funding. Mobile too? Here’s more.

…which, again, is I guess why Adobe is still pushing hard on Flex mobile. They know that once Android saturates the market more, the manufacturers will continue to screw up their browser implementations with crappy GPU’s, thus ensuring those who want highly branded applications with a lot of functionality will choose Flex. Or Flash. It’s strange, because I keep hearing about those who wish to do web deployments to prevent having to do the 3 development efforts (web, iOS, Android). I used to question and get concerned about what they are doing, but after using SoundCloud.com on my iPhone’s browser vs. the SoundCloud applications for both Android and iOS, it’s very clear: those who want the best experience will go native. It remains to be seen if the right someone(s) see what Flex and AIR can really do on mobile, and go, “Man… this looks great, and can be developed in a shorter time frame… and be re-used across tons of devices with just design changes to handle the variety of resolutions and functionality changes with our existing design tools. Let’s do this!”

We’ll see. And that’s what sucks… this whole “we’ll see”. Remember when we KNEW the Ajax guys were full of shit? Now they’re taking some of our widget jobs. Yes, you could do ’em over the weekend, but some of those were fun, man… and nice to have some money on the side of you weren’t a full time freelancer. Things were so certain then. The only certainty I have now is:

1. The AIR for Android and iOS is really compelling and no one who matters seems to know about it.
2. The Flex in the Enterprise and mid-size software shops seems un-moveable. While the HTML5 hype is replacing a lot of Flex jobs, just like the iPad did for financial firms moving to HTML/native vs. Flex for some jobs, the HTML5 is mostly hype. That doesn’t mean you can ignore it; a lot of companies make decisions on a CTO’s whim, even if that decision is completely wrong technologically. Either way, you lose a gig. There still seem to be a lot of people who want to write a TON of ActionScript, quickly, and thus, Flex is still in demand.

#keepYourHeadsUp

Need the Presentations and Code from RIA Unleashed 2011?

If you’re running in AIR2 or Flash Lite 4, there is already a native Geolocation API You can utilize straight from ActionScript 3. If you’re in the browser on the desktop, however, it’s not available unless you tap into the browser API’s which I’ve done.

You expose the browser API’s you need via JavaScript, and just have Flex talk to JavaScript, and JavaScript talk to it. This example below puts a marker on the map once it gets your location. While not needed, if you want to utilize in your own applications, you’ll need a Google Maps key.

Flex Geolocation Example – Larger View | Source

That said, here’s my attempts to correct the lies.

Lie  #1: “Adobeâ€s Flash products are 100% proprietary.”

The Flash IDE, yes.  The Flash Player, no.  Here is a list of technologies open sourced/published by Macromedia/Adobe that are in the Flash Player ecosystem:

1. ActionScript 3 runtime, called Tamarin.  Given to Mozilla to hopefully utilize in future browsers.
2. RTMP (and it’s ilk), the protocol for real-time video & audio streaming as well as data (AMF).  Yes, many want “more” open sourced.  Red5 and Wowza seem to be doing just fine with what is there currently.
3. The SWF format itself, which is what Flash Player plays/runs, has most of it’s spec published in case you want to generate SWF files.

This street goes both ways, too.  Macromedia/Adobe has adopted open source technologies into Flash Player with the hopes of embracing standards, not just the de-facto ones.

1. ActionScript 1, 2, and 3 are all based on EMCAScript.  Yes, it’s not as compliant as many would like.  Additionally, Adobe did participate in many ECMA Script discussions/debates.  Yes, 4 didn’t turn out so well for Adobe.
2. The XML parsing is based on E4X, ECMA Script for XML.

I’m not saying Adobe’s open sourced a lot of the Flash Player.  There’s open source, there’s published, and then there is open source.

Regarding their products, he’s wrong there too.  The Flex SDK, one of the biggest boosts for the Flash Platform in the past 4 years, is also open source (yes, the real kind).  Most utilize Flex Builder, built on top of the open source Eclipse.

Using a blanket statement saying Adobe’s Flash products are 100% proprietary is a lie.  It paints an incorrect & negative picture over all the wonderful things Macromedia/Adobe have done in open source around their products.

Lie #2: “HTML5 being adopted by Google”

Google created the first browser to fully integrate plugins, and continues to work with Adobe to do so.  Google also utilizes Flash Player in Gmail for both file uploading, and configuring your web cam.  Google utilizes Flash Player in their online maps product for street view.  Google Finance utilizes Flash Player for a lot of their charts.  Their video site, YouTube, utilizes Flash Player for their videos.

Google didn’t start out with Flash.  They started with text, AJAX, and later Flash.  They’ve done a lot of forays into HTML5, yes, and will continue to do so.  Saying they are “adopting” it, and only it and not Flash Player, is incorrect.

Lie #3: “…75% of video on the web is in Flash. What they donâ€t say is that almost all this video is also available in a more modern format, H.264, and viewable on iPhones, iPods and iPads…”

Incorrect.  If a video is H264, that doesn’t mean it can play on the iPhone.  If you look at the iPhone specs, you’ll see the only support a subset of what H264 offers, specifically 2 major components to quality video: Using a maximum of the Baseline profile, with Simple for higher bitrates/resolutions, as well as 2.5 for maximum (ish) bitrate.

Not all H264 videos conform to these specs.  YouTube converted a lot of their Spark (Flash 6/7) videos to H264 to support iPhone because there was money to be gained in the large investment.  Even so, not all YouTube videos work on the iPhone, in part because of the aforementioned reasons.  There is a reason why when you upload a H264 video to YouTube, they’ll often re-encode it.

I’ve been in web video for 7 years.  Getting video to work in the browser is the easy part.  Setting up video encoding farms to support thousands/millions of users is not.  It’s hard and expensive.  Not everyone has the resources (read money and time) Google has, and that’s why companies like Brightcove are trying to capitalize on this problem.

Most importantly, HTML5 currently has no universal DRM solution.  That is why Flash Player’s RTMPE, and soon HTTP Streaming via Project Zeri, are the de-facto standard today.  Those who deploy video content they either own or license the rights to will not utilize HTML5 because it cannot be protected.  There is a reason you rent videos in iTunes using their <strike>ACC</strike> MP4 format vs. straight H264.  Legally, those videos CANNOT be utilized via HTML5.

Also, Hulu.com and others aren’t using H264, they’re using On2’s VP6.

Lie #4: “users arenâ€t missing much video.”

Every time a user see’s a blue lego instead of the video they wanted to see, they are missing a video.  There were so many people seeing the blue lego, including Steve Jobs himself on stage demoing the iPad, that they removed the blue lego as a PR effort to make it seem like there was something wrong with the website itself vs. the iPhone/iPad.

…thankfully, Grant Skinner added it back.

Lie #5: “…Flash has recently added support for H.264…”

Incorrect.  It’s been there since August of 2007.  That’s almost 3 years.  That’s a long time in technology.

Lie #6: “…must be run in software…”

Not entirely correct.  Apple FINALLY gave Adobe and others access to hardware for desktop systems, which Adobe has recently utilized.  The #1 criticism for Mac’s & Flash video is lack of hardware acceleration.  This move by Apple will go a long way to improving video experiences, not just for Flash, for browser based video.  Meaning, cooler Macs and more battery life.

For mobile, Safari/WebKit is using H264 hardware decoding just fine.  They just won’t expose it, forcing yet again, Flash to utilize a sub par video experience for iPhone (having to launch a URL to utilize the iPhone’s default video player vs. incorporating the video into the experience).

Lie #7: “…When websites re-encode their videos using H.264, they can offer them without using Flash at all…”

See #3.  Also, not all Flash video is just a video block on a page.  Some are immersive experiences, games, or involved in compositing with other objects (alpha channels, easier particle systems, etc).  HTML5 does not currently support some of these features.

Finally, not all video is pre-recorded and progressive.  Live and streamed events are currently done using Flash Player and Silverlight.  Yes, I’ve seen systems that can do live H264 via progressive with only seconds latency over CDN’s, regardless, they aren’t what’s being used en masse today.  This includes DVR like functionality that both technologies offer, including Adative Streaming capabilities to ensure you can see un-interrupted video regardless of your internet connections’s integrity.

Lie #8: “…Flash was designed for PCs using mice, not for touch screens using fingers…”

Incorrect.  The whole reason Flash Player has continued to stay ahead of the curve is because Macromedia/Adobe innovates it.  There are gesture & touch API’s in the Flash Player; I and many others have used them for the iPhone resulting in a 100+ apps on the App Store.

Lie #9: “For example, many Flash websites rely on “rollovers”, which pop up menus or other elements when the mouse arrow hovers over a specific spot.”

Incorrect.  This was already discounted 2 months ago by Mike Chambers.  Additionally, I tested both MouseEvent.CLICK, MouseEvent.MOUSE_DOWN, and MouseEvent.ROLL_OVER, and all 3 worked just fine on my iPhone.  Additionally, I’ve seen video of a Nexus One using the native Flash Player 10.1 that plays a Flex website I made just fine with no code changes to support touch.

Lie #10: “Appleâ€s revolutionary multi-touch interface doesnâ€t use a mouse, and there is no concept of a rollover.”

Incorrect.  There are roll over states for buttons on the iPhone/iPad because you can click/touch on something, which shows the roll over state, but then drag off to not trigger the up, thus canceling your button click if you didn’t meant to touch something.  Works the exact same way as a mouse does.

Lie #11: “Most Flash websites will need to be rewritten to support touch-based devices.”

Incorrect, see Mike Chambers’ post in #9.

Lie #12: “If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript?”

Those same JavaScript Developers need to do the same work Flash Developers need to do: Nothing.

If both wish to utilize Gesture or Touch events, then BOTH need to re-write/adjust their content to support these events.

Lie #13: “The avalanche of media outlets offering their content for Appleâ€s mobile devices demonstrates that Flash is no longer necessary to watch video or consume any kind of web content.”

Incorrect.  See #3.  Media companies will have to create players like Netflix did to support those devices; these aren’t HTML5, they’re Cocoa.

Half-Truth #1: “Adobe was the last major third party developer to fully adopt Mac OS X.”

iTunes, flagship Apple software product enabling the success of the iPod, selling over 1 billion songs, and empowering digital movie rentals, isn’t Cocoa.

Gruber, the same guy who Apple apparently used as an example of why Flash doesn’t belong on the iPhone, was quoted, when referring to why Apple hasn’t ported iTunes to Cocoa:

What really matters are features and user experience, not the developer technologies used to make them.

Conclusions

I agree with everything else the article says.  While the spin is HTML5 is better than Flash, Apple wants you developing with Cocoa, not HTML5; that’s where the money and good user experiences are.  While many have said that the PR person responsible for writing that article is doing Apple a disservice, I disagree.  Yes, they do lose creditability writing that many lies, and yes, this just fuels the fire for many developers, not just Flash Devs, to focus on Android instead of iPhone.

However, iPhones and iPads still rock.  While Apple is “only the 10th” largest phone manufacturer, they are the only mobile platform people care about right now in the USA (unless you’re a pissed off Flash/Flex Dev).  Their app store, combined with the user experience, is un-matched.

Me?  I’m still trying to learn Cocoa so I too can participate in building applications for these wonderful devices; devices whose sales won’t be hurt by that article.  My colleagues in the industry?  Most are heading towards Android along with Adobe.  Those moonlighting in Flash & iPhone development simultaneously don’t say much, beyond correcting & helping me with my Objective C knowledge on Twitter (y’all rock!).

…oh yeah, and someone cast Cure 2 on Adobe.