Bandwagon
Bandwagons seem to be increasingly popular. The latest surrounds the fact that Apple is intentionally slowing Web applications to make native applications from the App Store more appealing.
Only it’s not a fact.
First we had suggestions that Apple were slowing HTML5 in mobile Safari.
http://m.wired.com/epicenter/2011/03/app-store-html5-slowdown/
Then we have The Register quoting a developer:
Citing a conversation with Apple, one developer told us earlier this week that the company did not intend to add all of Safari’s optimizations to the embedded web viewer. “Apple is basically using subtle defects to make web apps appear to be low quality – even when they claim HTML5 is a fully supported platform,” the developer said.
The headline and opening lines of the article all emphasize degraded browsing experience, and the fact that the lack of optimization is intentional. They also link to a report from a new company called Blaze, which claims to prove the poor performance of the browsing experience.
In a roundabout way, this makes it look like Apple has confirmed that defects are there intentionally, and the motivation is greed.
But this was just a speculative comment from an unnamed developer (not an Apple employee) who based this speculation on something else that an unnamed Apple employee said during a conversation (whose topic, if any, was also unnamed). Not exactly the kind of provenance that one could trust.
Plus, it seems that Blaze only tested the embedded browser component, not the actual mobile Safari, and Apple point out that there are significant differences.
If Apple was not motivated by greed to hobble their browser (or browsing component, to be exact), why else would they omit the optimizations that could improve performance? Well, there are reasonable explanations and the most coherent I have found comes from John Gruber who presents a clear case for the motivation being security.
http://daringfireball.net/2011/03/nitro_ios_43
If John is right, and Apple are working on the issue, then we can expect that the optimizations will appear in the embedded browser component (uiWebView) when they figure out how to use the Nitro JIT safely in uiWebView.
Meanwhile, mobile Safari with all its HTML5 and custom wizardry still performs very well. In fact, it performs better than ever, because it does in fact have the optimizations.
Looks like I missed that bandwagon.
Categorised as: Uncategorized