Report Finds Performance of Web Apps Throttled on iOS Devices

http://www.readwriteweb.com/archives/report_finds_performance_of_web_apps_throttled_on.php

by minalecs • 15 years ago

72 33 15 years ago

th0ma5• 15 years ago

A big part of me thinks that Apple doesn't quite get that both developers and users both want the full capability of the device to be theirs ... whilst Apple still clings to the idea that they can control the line between device and network.

martythemaniak• 15 years ago

Well, Apple practically invented that concept in personal devices. Before the iPhone sideloading apps and owning your device was the norm.

cooldeal• 15 years ago

That doesn't mean Apple should get 30% of all money that flows by their devices like Apple seems to think, enforced via DRM.

That'll be a bit like the ARPA/Vint Cerf asking 30% of all e-commerce revenue that flows over the net and Tim Berners Lee for all things over HTTP traffic. After all, they invented it, right?

Comcast spent the money to wire through the last mile, they feel they deserve some of the money that Google, Amazon, Netflix are making, net neutrality notwithstanding. Do you agree?

bengl3rt2• 15 years ago

They probably just forgot to rebuild the WebKit view built into the Springboard that runs homescreen webapps with the new JS engine. I am sure they will issue an update soon.

grayrest• 15 years ago

I'd prefer to give them the benefit of the doubt, but this after breaking the web application cache for homescreen items in iOS 4.2 is a disturbing trend.

bengl3rt2• 15 years ago

Well, I'll grant them that regressions occur during software development. However, it's highly unlikely they are unaware of these problems, they just deprioritize fixing them instead of things that affect their precious curated native apps.

webXL• 15 years ago

Is it possible that with multi-tasking, having two threads of the new Nitro JS engine open in memory slows everything down? It's not that big of a deal with 512mb of RAM and dual core, but the iPad 1 could be sluggish. I guess it's possible they only use one JS thread for everything (even the 9 "tabs" in Safari), and this really is just a bug.

ryanpetrich• 15 years ago

There's one web thread per process (and JavaScript can either run on it or the main thread), but home screen apps run in their own process.

Nitro doesn't use substantially more memory than the earlier engine.

rahoulb• 15 years ago

In another thread discussing this there was the suggestion that Nitro's JIT compiler may need special privileges to mark writable memory as executable as iOS doesn't allow that under normal circumstances.

Maybe that flag's been set for MobileSafari but not set for Springboard.

recoiledsnake2• 15 years ago

Apple forgot? With their so called obsessive attention to detail, that's hard to fathom. If this was about performance in native games, they would've rushed out a patch by now.

rbarooah2• 15 years ago

Where 'throttled' means just as good as before.

Occam's razor suggests that they simply hadn't finished the integration work before the ship date.

SigmundA2• 15 years ago

Exactly, UIWebView simply wasn't updated with the latest WebKit engine the Safari app is running.

Web Clips use a special app wrapper that uses UIWebView, that is all.

This affects real apps that use UIWebView to display HTML content, which is a lot of apps, including probably some of Apples own apps.

You would think UIWebView would share the same WebKit with Safari, but Apple didn't do this, I doubt their reason are nefarious, probably just allows them to try new stuff out in the browser while being more conservative for the developer component.

dunham• 15 years ago

I think it's the same UIWebKit. If you're willing to Jailbreak your device, you could take a look at the files and find out.

The issue is that no apps other than MobileSafari can do JIT compilation, due to security constraints put in place by the kernel. You can't write to a segment of memory and later make it executable.

To pull this off with MobileSafari, I suspect that Apple put a back door in the kernel, and requires apps to be signed with a specific entitlement to get access to it. And I'm guessing that MobileSafari is the only app with this permission.

For full screen web clips, it might be possible for Apple to give the wrapper the right permissions without breaking their security model. Hopefully they do this in the future. But I doubt that 3rd party native apps will ever be given the ability to modify code.

bsaunder• 15 years ago

So, here's the link to the actual referenced report:

http://www.theregister.co.uk/2011/03/15/apple_ios_throttles_...

IMO, it doesn't add much to the discussion except for this nugget at the very end of the article:

"This developer reiterates that if Apple didn't specifically introduce these problems in iOS, it's aware of them now. And he says that the Mobile Safari team has indicated the issues will not be fixed."

rbarooah2• 15 years ago

Right, because Apple are generally in the habit of providing details of their development plans to anonymous developers.

What does 'indicated' mean? Presumably not the same as 'said'.

hexis• 15 years ago

I think aside from whether this problem was intentionally created by Apple (I don't think it was), I think it does show that Apple considers these web apps to be second class citizens. Making sure the new JS engine worked for these web apps apparently either was not on the list of things to test before shipping 4.3 or it was something that was allowed to slip. Either way, web app performance was not a release blocker for 4.3.

jaxn2• 15 years ago

I don't think users actually do this anyway.

I am running a twitter poll on how many web apps people have saved to their iPhone: http://twtpoll.com/r/g3bnth

I have a pretty techy following and this just doesn't seem to be done with any regularity. Maybe half of the people have saved at least one web app, but how many native apps have they installed.

I think this tells us two things:

1) saving a web app doesn't really make it any better than just using that web app in mobile safari.

2) apple has little incentive to prioritize the testing and developing of this feature since so few people actually use it.

Seems like a non-issue to me.

SigmundA2• 15 years ago

This effects UIWebView which web apps, technically called web clips just so happen to use.

However many normal apps use UIWebView to display HTML content. Any app you use the jumps to a web page but stays in the app definitely does, some apps you might not even know you're using HTML UI instead of Cocoa, the integration is pretty tight, sometimes it simply easier to make parts of your UI in HTML and embed as a resource and just point UIWebView to it.

So yes users use it all the time, but usually as part of a real app.

jaxn2• 15 years ago

Ahhh, I miseed the part about this affecting all UIWebView.

Though doesn't that really lend credence to the idea that this was an oversight and not an intentional slight at web apps?

bambax• 15 years ago

> I don't think users actually do this anyway.

Ordinary users may not do this (yet?); but I develop webapps for companies (to be used internally) where we have users add the app to the home screen (or we do it for them). Once this is done, they don't know the difference between a native app and our webapp.

For non-technical users it would be quite complex to launch Safari and select a bookmark to operate an "application".

pak• 15 years ago

Some mobile web app "stores", like http://openappmkt.com/ , provide all the JS and HTML to force users to install the app to the homescreen first, in the interest of preserving their user experience.

Try installing an app that is based on OpenAppMkt like http://khanapp.com and notice that it asks you nicely to add it first to the home screen before running.

As an iOS web developer you can use the navigator.standalone JS var to detect if the app is running straight from the home screen, and ask the user nicely to install it if they haven't done so.

Why would you prefer users to do this? Because it removes the location bar chrome, which can result in a near-seamless fullscreen interface that more closely resembles a native app.

minalecs• 15 years ago

i created http://nibzy.com for my own purposes because I prefer on tablet and mobile to go to mobile sites, I find it faster to switch and navigate through content. http://home.nibzy.com/plain link to fast loading plain text list of best mobile sites

rektide• 15 years ago

remember when Steve Jobs announced the iPhone, and said the only applications for it would be web applications? [1] and how, across the next 5 months before native apps were announced, people alternatively wondered how they were going to possibly develop for it, or whether it was going to be a second genesis for the web? yeah, good times.

[1] http://www.engadget.com/2007/06/11/apple-announces-third-par...

nathanwdavis• 15 years ago

If this is a problem with the UIWebView in general, then the problem affects a lot more than just saved Web Apps. Many, many native apps use the UIWebView.

Niten• 15 years ago

But read the article. This specifically affects web apps run launched as fullscreen applications from the iPhone home screen, as opposed to other applications making use of UIWebView.

Relwal• 15 years ago

This seems like a mighty convenient "bug" given that HTML frameworks like jQuerry Mobile are just starting to be able to deliver a native-app-like user experience.

geuis• 15 years ago

No, this was NOT "The Register's discovery". This was originally discussed here on HN last Friday, http://news.ycombinator.com/item?id=2317804 by marcusramberg, http://news.ycombinator.com/user?id=marcusramberg.

After replicating some of the tests, as I documented here http://news.ycombinator.com/item?id=2317975 in the comments, then here on my site in full, http://trending.us/2011/03/12/performance-numbers-for-nitro-....

That was Friday. Then yesterday the author of the Register story, Cade Metz, contacted me out of the blue about my blog post. I more or less told him (what I imagine every developer he contacted about this story) was that Yes, it runs slower in UIWebViews and that No, its not an Apple conspiracy, and that this appears to be a bug that Apple is now aware of going by posts in the Developer forums. I told Mr. Metz that if he can get into the dev forums, he can see for himself, but that I could not directly provide links or anything because the forums are confidential. I don't intend to lose my developer license, thank you.

Then yesterday afternoon, the story was published. I was not referred to directly (for which I am thankful), though perhaps one of his anonymous sources was a paraphrasing of some of the things I said.

Now here we go again in the echo chamber that is the Valley, where ReadWriteWeb is regurgitating a non-story published by The Register, that was verified by me and others on our personal sites, that I (we?) heard about from Hacker News, that was originally reported by someone else who first found the problem.

Assuming marcusramberg was the original discoverer of the this, has he gotten any credit? No.

Fucking mountains out of molehills.

flashgordon• 15 years ago

You know I would really like to see Gruber (and Siegler) defending this. yes yes, "apple can do what it likes with its product" is a common retort, but it would be refreshing to see a different one.

Report Finds Performance of Web Apps Throttled on iOS Devices

Related Stories