Apple will cripple the Kindle web app

If you've been following the Apple in-app purchase fracas of late, then you might know that a log of people are hoping that web apps will be able to get around the need to pay Apple's vig. If not, then let me explain. The way a web app works is that it uses HTLM5 to run entirely from inside your web browser. It's kinda a trick that builds an app into what you might think of as a web page. Unfortunately, Apple have been caught throttling web apps. In particular, if an app installs its icon on the home screen, it won't be able to use all the features of the Safari browser. iOS is setup so that app will run at less than half the speed of the same app if you opened it in the browser.

I know it sounds strange, but developers really have noticed the difference. One has even gone so far as to post test results on his website which show the difference. To be fair, Apple aren't degrading the speed of home screen web apps; They're boosting the speed of web apps in the browser and they're not providing that same boost to the home screen web apps.

Is it a bug? Maybe, but I don't think so. It fits too well with things Apple have done in the past. For example, it's a well known fact that Apple have code for iOS that they won't share with most developers (fact, not urban legend). This code gives Apple's own apps an advantage over the competition.

So what this means for reading apps is that even if Amazon get the Kindle Web App working well, it's still going to be at a disadvantage. And the same goes for all the others.

Let's wait and see how long it takes to get fixed. TBH, I don't think it ever will be fixed because I believe this was deliberate. It just feels too much like something Apple would do to harm the competiton. What do you think?

via The Register

About Nate Hoffelder (11392 Articles)
Nate Hoffelder is the founder and editor of The Digital Reader: "I've been into reading ebooks since forever, but I only got my first ereader in July 2007. Everything quickly spiraled out of control from there. Before I started this blog in January 2010 I covered ebooks, ebook readers, and digital publishing for about 2 years as a part of MobileRead Forums. It's a great community, and being a member is a joy. But I thought I could make something out of how I covered the news for MobileRead, so I started this blog."

3 Comments on Apple will cripple the Kindle web app

  1. Apologies for the massive comment.

    I’m assuming that you’ve seen the discussion on the security implications of Nitro on ARM processors and dismissed that as a concern? http://news.ycombinator.com/item?id=2318028

    The data memory code execution issue is real enough and, in my view, a valid reason from barring Nitro from third party applications that Apple isn’t in complete control of down to the source level.

    That doesn’t explain why home screen web apps don’t have Nitro, but as I explain below I think that is an honest omission based on engineer resources.

    In general, I’m not fond of Apple’s actions and am ready to assume that their actions are based on some sort of agenda but in this case I have to strongly disagree with you.

    First of all, most people, in my experience don’t use home screen bookmarks but use web apps in Safari, maintaining a constant set of tabs or screens in Safari rather than using web apps as full-screen apps. Most web use takes place within Safari and so if Apple wanted to cripple or compromise web apps they simply wouldn’t have ported Nitro to ARM in the first place. Mobile Safari is much more of a threat to the App Store than the full-screen web apps.

    Second: WebSheet.app, the application that actually runs full-screen web apps, is probably using UIWebView and not the multitudes of private APIs that Safari relies on, and so only provides the features inherent in UIWebView (almost none). I’d wager that Apple wants to focus its engineering resources on Safari proper instead of an edge case. It’s rare that removing a web browser’s UI will improve a web app and in most cases removing it means that the developer has to re-implement a host of features otherwise provided by the browser chrome.

    Third: Web app developers can get all of the benefits of home screen bookmarking and Safari performance by having their web app always launch Mobile Safari instead of WebSheet.app.

    Fourth: Web app developers can get a more noticeable performance boost by using hardware-accelerated CSS animations and thoughtful design. Raw JS performance does not automatically result in a more responsive UI or applications. If Apple really wanted to cripple web apps they’d have disabled hardware acceleration in UIWebView and in WebSheet.app.

    Fifth: Web-based ebook readers aren’t crippled by this, not by a long shot. These apps are well engineered and perfectly usable even in older generation iOS devices and will benefit enormously from the increased memory and graphics performance in the iPad2. They’d benefit from Nitro as well, sure, but the omission does not threaten their viability in any way, especially when you consider iBook’s overall bugginess and countless quirks.

    In general, I’d say that Nitro’s existence on Mobile Safari itself disproves the theory that Apple is out to get web apps. If they had such a machiavellian goal in mind they wouldn’t have ported it in the first place.

    • Thanks.

      Every time I forget that I shouldn’t trust The Register, it bites me in the ass. When am I going to learn? Seriously, I’ve seen stories in the past where they were being sloppy or had details wrong. I should have stuck to my doubts.

      Thanks again.

    • Baldur,
      Don’t apologize! Very interesting/informative.

      Nate, thanks for bringing it up even if maybe believing the Register just a bit beyond your usual inclinations there.

Leave a comment

Your email address will not be published.


*