Confirmed: some Web apps not seeing iOS 4.3 JavaScript speedup

Apple boasted about significant JavaScript performance improvements in the iOS 4.3 update, but our testing indicates that those improvements only apply to websites and Web-based apps that run in MobileSafari. Some developers suggest the performance differences are a conspiracy against open Web development.

<a href='http://meincmagazine.com/apple/news/2011/03/confirmed-some-web-apps-not-seeing-ios-43-javascript-speedup.ars'>Read the whole story</a>

 

[Joeri]

I really do think it's articles like these that help Apple continually improve

As an apple user for a while now, I can disabuse you of the notion that Apple continually improves. Instead, they improve for a while, and then take a big step back hiding it under a thick layer of novelty. Everyone looks at the shiny new features, not noticing that a lot of stuff that used to work now is broken or missing.

 

[stormsweeper]

Would it not be a security issue if apps could make memory pages executable?
I think this needs to be carefully considered to avoid opening an attack vector..

Theory is that this is JavaScript, so it is kept in the sandbox by the language limitations imposed by it being Nitro that does the writing to memory and the designating of what to execute.

However it is possible that you could have some ARM machine code in a data array in your JavaScript and exploit a Nitro bug to get the A4/A5 executing that data array rather than limited to the JIT generated (and thus JS limited) ARM machine code.

What I am unsure of is what extra exposure would be created by this being available outside Safari? If this is really an issue of QA, of security and otherwise, where Apple felt they needed more time than the iPad 2 release gave them to implement and ensure it was OK outside of Safari.

I think the issue is right now there aren't sub-sandboxes for apps. If you give an app permission to muck with the memory space for javascript, it can do it for other things as well. As others have said, it's an engineering problem.

I suspect this is like all the hysteria over AirPlay when it first launched, since it wasn't complete.

Also, FWIW, Apple said Safari would be faster, not anything using WebKit.

 

[Dynamo Hum]

Funny how some think it's a conspiracy. I think Apple have been pretty open about how they intentionally cripple web apps. It's in their interest after all. For those who want a richer experience there are lots of alternatives coming along. Choose your poison...

 

[Chuckstar]

Also, FWIW, Apple said Safari would be faster, not anything using WebKit.

Yes. In hindsight Apple was particularly careful about this point.

 

[foresmac108]

Isn't just web apps. These were my own tests from a few days ago. Hoping its just a bug.

Did you read the article? It clearly states that any app that uses a web view other than Safari can't use the Nitro JavaScript engine and therefore won't get a speed boost.

Edit: Oops, someone beat me to it!

Yes I did read the article. I said that I took those a few days ago and felt that I would add in a concrete example.

iCab itself is just an alternative browser, which I suppose qualifies it as an in app browser.

Aside from Opera Mini, which basically does its rendering on Opera's servers, all other alt browsers for iOS use UIWebViews, which don't as yet get the benefits of the Nitro JavaScript engine.

 

[Goofball_Jones]

Funny how some think it's a conspiracy. I think Apple have been pretty open about how they intentionally cripple web apps. It's in their interest after all.

Ah, I did not know this. Could you point me to the article or press release that quotes Apple saying that they intentionally cripple web apps? I mean, if they're "pretty open" about it, then they must have said something official, yes? Or is this more assumption?

 

[Dynamo Hum]

Funny how some think it's a conspiracy. I think Apple have been pretty open about how they intentionally cripple web apps. It's in their interest after all.

Ah, I did not know this. Could you point me to the article or press release that quotes Apple saying that they intentionally cripple web apps? I mean, if they're "pretty open" about it, then they must have said something official, yes? Or is this more assumption?

Just need to see how Apple don't introduce things like contenteditable in the iOS browser (and the other points made in the article). It's a common theme with Apple and who can blame them. The money is in apps. Actions speak louder than words. They do have shareholders to consider, and efficient and modern web standards don't pay the rent. Not while the cashcow app store is still running strong.

 

[ReaderBot]

Given that iOS 4.3 absolutely had to ship with ipad 2, resources and timing may well have been issues. And most users are going to see far more benefit from Nitro in Safari than in home screen web apps.

They were so pressed for time that they released it early?

My question is, doesn't this improvement just open up MobileSafari to drive-by code execution? Don't web pages now have the exact same attack vector they're worried about in mobile apps?

 

[Tyler X. Durden]

Given that iOS 4.3 absolutely had to ship with ipad 2, resources and timing may well have been issues. And most users are going to see far more benefit from Nitro in Safari than in home screen web apps.

They were so pressed for time that they released it early?

He is suggesting that to release it on time they had to make a hard decision about scope. Well, I guess you always have to make hard decisions about scope to be able to ship on time, but in this case one of the hard decisions about scope was how widely Nitro was implemented.

 

[Tyler X. Durden]

I think the issue is right now there aren't sub-sandboxes for apps. If you give an app permission to muck with the memory space for javascript, it can do it for other things as well.

While that fits for in-app browsers, and third-party browsers, that doesn’t strictly fit as a problem with Web apps. There it is likely just the work to have things rerouted so Web apps are executed by Nitro.

 

[Goofball_Jones]

Funny how some think it's a conspiracy. I think Apple have been pretty open about how they intentionally cripple web apps. It's in their interest after all.

Ah, I did not know this. Could you point me to the article or press release that quotes Apple saying that they intentionally cripple web apps? I mean, if they're "pretty open" about it, then they must have said something official, yes? Or is this more assumption?

Just need to see how Apple don't introduce things like contenteditable in the iOS browser (and the other points made in the article). It's a common theme with Apple and who can blame them. The money is in apps. Actions speak louder than words. They do have shareholders to consider, and efficient and modern web standards don't pay the rent. Not while the cashcow app store is still running strong.

Ah, guess we have different understandings of "pretty open" then. I'm not denying that this is what they're doing, but since they've neither confirmed nor denied these allegations, they've been anything but "pretty open" about it anything.

 

[foresmac108]

I think Apple have been pretty open about how they intentionally cripple web apps. It's in their interest after all.

How is it that Apple "intentionally cripples" web apps?

If you remember, web apps were originally the "official" SDK—Apple didn't roll out a native development SDK until iOS 2.0. And Apple includes the ability to save web apps to the home screen so they can be accessed just like regular apps. Furthermore, WebKit is seen as the best platform for deploying web apps. Given that, how is Apple "crippling" web apps?

 

[Beren]

Given that my Tweet was quoted, I should probably weigh in here. I don't have any inside information on what Steve Jobs (or any other Apple executive) is thinking. I *have* seen a distinct slowdown in web apps with which I'm familiar of late, and I've heard (like those quoted in The Register, apparently) that it's due to a bug, and that there are no immediate plans to fix it.

As for my Tweet, let's just say 140 characters is not nearly enough to explain what I meant.

It's true that I've heard that there's an executive order not to fix the bug. It's also true that I have no clue how high up that "order" goes, or what, exactly, it means. It could mean that Apple is being very prudent about security, and doesn't take changes lightly. In other words, it's a "not to be fixed [YET] by executive order," as Apple strives to cover its bases completely before issuing a fix.

Of course, we wouldn't be having this discussion if Apple were just a bit more open about what it does, and why. But it isn't, and based on its market cap, I suspect the company isn't planning to change anytime soon. Fine. But it makes life harder for those of us who build upon Apple's various platforms, and consider ourselves Apple fans. (I have 4 Macs sitting around the house, an equal number of iPhones, and an iPad.)

We're trying to deliver apps to Apple devices that abide by the spirit and letter of Apple's terms and conditions. It's made a little harder by this recent performance hit, but given our customers' general approach to mix HTML5 and native code, it's not a deal-killer by any stretch.

Thanks for coming over and shedding some light on your quote. That said, "I've heard" is a lot less convincing than an email or a direct quote. However, you do go on to note that the exact meaning of what you heard is unclear, which is good.

I'm confused as to what performance hit you took, unless not getting a performance bump is a performance hit...

In any case, major kudos for coming here to explain further. I, Mr. Random Intarweb Poster, appreciate the effort and the additional context.

 

[bb-15]

Given that iOS 4.3 absolutely had to ship with ipad 2, resources and timing may well have been issues. And most users are going to see far more benefit from Nitro in Safari than in home screen web apps.

They were so pressed for time that they released it early?

He is suggesting that to release it on time they had to make a hard decision about scope. Well, I guess you always have to make hard decisions about scope to be able to ship on time, but in this case one of the hard decisions about scope was how widely Nitro was implemented.

Obviously, shipping dates can affect how many features of a new OS can have. As for Apple's ability to impliment mobile OS features, Apple has been able to ship an almost complete mobile OS/hardware ecosystem (phones, tablets, media players) which in tems of features and performance are competitive.

- Someone mentioned Microsoft in this thread as if MS could do better than Apple in terms of producing mobile OS software features. If that is so, why can't MS add copy and paste to WP7 yet? And if producing mobile products is so easy, why was the Zune platform just dropped? Answer, it isn't easy.

- Let's add Android to the mix. Android OS phones are good performers but a tablet with Honeycomb according to Ars testing trailed the iPad2 in terms of performance. Again, producing these mobile products at the highest levels of performance is not easy.

* Bottom line; how long has iOS 4.3 been released to the public? 7 days. And there is a complaint that this new OS is not perfect and that this somehow can only be due to a conspiracy by Apple? Ridiculous.

 

[Daza]

I think the issue is right now there aren't sub-sandboxes for apps. If you give an app permission to muck with the memory space for javascript, it can do it for other things as well. As others have said, it's an engineering problem.

I suspect this is like all the hysteria over AirPlay when it first launched, since it wasn't complete.

Also, FWIW, Apple said Safari would be faster, not anything using WebKit.

Anyone paying attention to how Apple rolls knows that they tend to implement stuff incrementally. Should Apple have delayed the new version of Mobile Safari until they had developed a solution to allow third party apps to have webkit2 sub processes that can be sandboxes and allowed to convert data pages to code pages in order for Nitro Extreme to be able to run? Or maybe Apple should have implemented a half baked insecure version for third party apps? There are good reasons why smart developers like to "eat your own dog food".

 

[fatimid08]

Given that iOS 4.3 absolutely had to ship with ipad 2, resources and timing may well have been issues. And most users are going to see far more benefit from Nitro in Safari than in home screen web apps.

They were so pressed for time that they released it early?

My question is, doesn't this improvement just open up MobileSafari to drive-by code execution? Don't web pages now have the exact same attack vector they're worried about in mobile apps?

My guess is that the devs were able to finish some sort of sandbox taylored specifically for JIT compilers for use with Nitro in MobileSafari but weren't able to finish it for general use on time, so Apple decided to push it out now with Safari only and enable the rest in a patch. If the sandbox isn't ready at all, then the patch that has it better come quickly. At least, any potential liability is currently limited to Safari.

 

[lgerbarg]

Just need to see how Apple don't introduce things like contenteditable in the iOS browser (and the other points made in the article). It's a common theme with Apple and who can blame them. The money is in apps. Actions speak louder than words. They do have shareholders to consider, and efficient and modern web standards don't pay the rent. Not while the cashcow app store is still running strong.

Where does this "the money is in the apps" nonsense come from. Apple has publicly said it has paid out $2 billion to app developers, which means their total gross on the app store is $3 billion. That is the total since it was launched. iPhone grossed $10 billion in the December quarter, and iPad grossed $5 billion. So that is $15 billion in 3 months. Since the iPhone originally shipped iOS devices have grossed at least $60 billion dollars, which means the apps are worth ~5% of the gross of the hardware sales. While we don't know exactly what the net profits are by product, you can simply look at Apple's overall numbers and tell that the app store is a nice profit center, but that it is not where the real money comes from. They make money on hardware sales, and use the app store to catalyze those.

You may have a point about things like contenteditable not working, but your logic behind why it doesn't work is built on an a faulty premise.

 

[Uncouth Youth]

Big deal, the iOS 4.3 update broke my Exchange webmail. Now no Javascript buttons work, so no sending, saving, moving to folders, etc. Is anyone else seeing this?

 

[dru`]

I *have* seen a distinct slowdown in web apps with which I'm familiar of late

It's made a little harder by this recent performance hit, but given our customers' general approach to mix HTML5 and native code, it's not a deal-killer by any stretch.

Twice you mention "slowdown" or "recent performance hit" without specifics. Are you calling no speed boost a "slowdown" or "recent performance hit" (like Democrats call no spending increase a cut) or is there a verifiable slowdown vs. iOS 4.2? Apple never said web apps would see the Nitro boost in iOS 4.3, they said Safari would.

I've heard (like those quoted in The Register, apparently) that it's due to a bug, and that there are no immediate plans to fix it.

It's true that I've heard that there's an executive order not to fix the bug. It's also true that I have no clue how high up that "order" goes, or what, exactly, it means...

Hell, I've heard Elvis is alive! You don't take ownership for knowing this as "fact" just that you've "heard" about it. Conclusion: it's rumor, at best. You use weasel words and back away from the spin the incompetent Chris Foresman put on a tweet you say contained too few characters to express your thoughts.

When is Chris Foresman going to edit the article to reflect his own source is running away from the quote used?

 

[0megapart!cle]

This is a pretty big issue. I use iCabMobile regularly, and it won't benefit from the speedup in iOS 4.3 because of this issue. Given how long Apple goes between major updates, and their enormous resources, there is absolutely no excuse for a bug like this. Apple should be ashamed of themselves, whether this was intentional or not.

 

[SamTheGeek]

I read somewhere (twitter, can't find the reference) that the problems with the non-nitro performance wasn't a conspiracy but merely an incorrect permissions setting on Web.app (the core service that provides UIWebView). If/when Apple fixes it, the web view will benefit from Nitro.
It may also be that Nitro was untested outside of Safari, and they didn't have the time to test it with a sampling of apps and such to ensure performance with Web.app. Note that the iOS version had to be Gold Master as soon as the iPad 2 production ramped up....likely a few days before the GM was released to Devs.

 

[Gary Patterson]

It's true that I've heard that there's an executive order not to fix the bug. It's also true that I have no clue how high up that "order" goes, or what, exactly, it means. It could mean that Apple is being very prudent about security, and doesn't take changes lightly. In other words, it's a "not to be fixed [YET] by executive order," as Apple strives to cover its bases completely before issuing a fix.

That's a very serious allegation, and one that requires more than "I heard" as a source.

Who did you hear it from? Or at least, where did you hear this? Can you give anything to corroborate your story?

I'm not judging this, but it seems that you need more than an anecdote for that point to stand.

 

[xyglyx]

Safari
iCab Mobile

Isn't just web apps. These were my own tests from a few days ago. Hoping its just a bug.

Darn. That's exactly what I was hoping wouldn't be the case.

 

[xyglyx]

Who cares if only Safari gets to use Nitro? Only losers use apps like Instapaper, Reeder, and alternative browsers. Apple knows this, which is why they didn't bother enabling Nitro outside Safari.

 

[wanorris]

Wait, people still use web apps?

Believe it or not, some of us haven't converted full-time to the iInternet.

Huh?

Where we ignore the big scary web and retreat to the safety of equivalent "apps" that usually only run on a platform or two and have to be blessed by platform vendors.

 

[daGUY]

The argument that this is a "conspiracy" is totally ridiculous. Just because Apple isn't disclosing why this bug/limitation exists doesn't mean there's any malicious intent behind it; they don't disclose anything.

If you think about it before jumping to conclusions, it doesn't add up. First of all, no web apps run slower under iOS 4.3; they run at the SAME speed as they did in 4.2, unless they're running in Safari - in which case they run faster. A week ago, before 4.3 came out, nobody was complaining about web apps being "hampered" or whatever under 4.2.

Second of all, if the supposed goal of this is to push people toward developing native apps, why would Safari have these speed improvements AT ALL? Wouldn't it make more sense to not ship those improvements entirely, if that were the plan?

Third of all, how would this even push people to develop native apps anyway? Again, web apps under 4.3 don't run any slower than they did under 4.2. If the supposed lack of speed is supposed to push developers toward native apps, that would have already been the case with 4.2 and earlier.

It's obviously either a bug, or they simply didn't have the development/testing time to get these speed improvements out everywhere with 4.3. It'll be addressed in 4.3.5 or 4.4 or whatever, and everyone screaming "conspiracy" will suddenly be silent.

 

[deet]

Can you imagine the outrage if MS slowed down web apps on other browsers apart from their own?

I don't have to imagine, I remember. I don't know if you're out of sixth grade yet, so maybe it happened before you were born, but MS was the subject of tremendous outcry when it was found that other web browsers were limited in performance when running on Windows systems, and that IE was effectively using undocumented APIs to make other browsers look weak.

Of course, as similar as this situation may or may not seem, it is hardly uncommon in Safari's case for the app itself to have newer libraries than the ones used in UIWebView. The improvements tend to show up in new releases fairly quickly, though.

At least now I know why I haven't been seeing the Ars features box look any smoother... I always launch Ars from a home screen icon.

 

[deet]

Asay characterized that scenario as "slimy" and "malicious," believing it is designed to make Web-based apps appear to perform poorer.

Sigh, but web apps aren't made to perform poorer. Poorerly? Poorlier? Whatever. Also, apparently there's no problem when running the app from within MobileSafari. So just tell people not to save it to a home icon. Is there something I'm missing about web apps? Is he referring to those insipid apps that charge you two bucks to show you a web page in a UIWebView?

 

[MAlan]

I have a few questions:
1) Is it possible to develop an html5 app for IOS that runs in Safari that can do full screen mode?
2) What is the advantage of developing a web app in html5 over making your app live within safari?

Thanks.

 

[stormsweeper]

I think the issue is right now there aren't sub-sandboxes for apps. If you give an app permission to muck with the memory space for javascript, it can do it for other things as well.

While that fits for in-app browsers, and third-party browsers, that doesn’t strictly fit as a problem with Web apps. There it is likely just the work to have things rerouted so Web apps are executed by Nitro.

Those technically run as another app (as mentioned in the article), and Apple probably forgot to enable it for that wrapper.

 

[stormsweeper]

Just need to see how Apple don't introduce things like contenteditable in the iOS browser (and the other points made in the article). It's a common theme with Apple and who can blame them. The money is in apps. Actions speak louder than words. They do have shareholders to consider, and efficient and modern web standards don't pay the rent. Not while the cashcow app store is still running strong.

This is a limitation of mobile webkit implementations (including Android):

http://www.symphonious.net/2010/09/13/c ... le-webkit/

 

[Tyler X. Durden]

I think the issue is right now there aren't sub-sandboxes for apps. If you give an app permission to muck with the memory space for javascript, it can do it for other things as well.

While that fits for in-app browsers, and third-party browsers, that doesn’t strictly fit as a problem with Web apps. There it is likely just the work to have things rerouted so Web apps are executed by Nitro.

Those technically run as another app (as mentioned in the article), and Apple probably forgot to enable it for that wrapper.

"Forgot to enable” would constitute an ENORMOUS cluster-bang oversight collectively made by multiple people across multiple teams, and it would be more than just forgetting to set the “this app can change data to code” flag, because that’d just break it.

That seems far less likely than the task/feature fully consciously getting the axe during a planning meeting to ensure hitting the release date [with fully tested feature set and confidence in the security and stability of the implementation].

I mean it could have happened as a oopsie I suppose, but it would require a brain fart, and active steps and missteps, that would positively dwarf the infamous iPhone alarm clock fiasco in the chain of steps to happen and number of people that had to screw up [in certain ways], especially considering the much wider focus Nitro had as part of this release.

 

[stormsweeper]

Out of curiosity, are you a developer on a large team? That kind of stuff happens in big teams all the time, every day.

 

[Tyler X. Durden]

Out of curiosity, are you a developer on a large team? That kind of stuff happens in big teams all the time, every day.

Yes, I have been. For commercial release software (that works different than in-house projects). Actually, if you want to get out the YOU-HAVENT-BEEN-THERE dick measurer...I’ve also worked in QA, documentation, and tier 3 support roles on large teams, too….I don’t drink enough to be in marketing/sales.

Mistakes happen but what has to have happened here is extensive, it isn’t just a flag flip or a single file checked in wrong.

 

[stormsweeper]

I mean more that they forgot that app even existed and needed the change, but in any case it's not enabled because they haven't done the work.

 

[Tyler X. Durden]

I mean more that they forgot that app even existed and needed the change, but in any case it's not enabled because they haven't done the work.

Translation: It never got added to the scope document/feature list to start with….because it wasn’t important enough.

And if someone on some team somewhere points it out and enters a defect in the bug list for it, because “are you sure we wanted it like this”, and that gets evaluated as “don’t fix [for this release]” AKA “yes, we really meant/intended that". Which really amounts to the same thing as cutting it later.

 

[foresmac108]

the spin the incompetent Chris Foresman put on a tweet

Ok, your insult isn't very enlightening or useful, but maybe could explain what "spin" I put on his tweets? They are direct quotes, and you can read the tweets for yourself assuming Matt didn't delete them.

When is Chris Foresman going to edit the article to reflect his own source is running away from the quote used?

This is the first I saw Matt's comment, and I'm glad he added to the conversation, but I don't see the need to edit anything. Matt said what he said—in multiple tweets—and I quoted it. I could run out and say "Steve Jobs is an asshole," then later when a reported quotes me, I could leave a comment and say, "That's not what I really meant." That in no way means the reporter is "incompetent," as you seem to suggest.

 

[RustyRocket]

And Apple includes the ability to save web apps to the home screen so they can be accessed just like regular apps.

This in article about how that slows them down? Holy-cognitive-dissonance-batman!

And to everyone going on about security... If the JIT is insecure, then exposing it the net (Mobile Safari) is braindead, if it isn't than webapps by should be able to run safely since they, by definition, work in a modern browser. If Apple can't expose a system component that is made to handle unsafe data to applications without blowing up the "security" model, then the platform has serious issues.

 

[Tyler X. Durden]

For anyone still reading the thread, the in-extinguishable Gruber has mentioned (Update at bottom of that link) that WebKit2 has an engineering solution to allow Nitro for all JS without having to flag all processes as being able to convert Data pages to Executable. It’ll compartmentalize the JS into it’s own process.

 

[zelannii]

Here's another reasonable explanation if it's not just some odd bug they didn't catch:

Enabling Nitro for in-app browsers was probably in plan, but another higher priority item slipped or Apple lost dev/test resources somewhere which caused the functionality to be deferred into a subsequent patch to cover a resource gap. The limitation could have been better documented by Apple though.

I'm secretly hoping this IS a conspiracy, being an Apple hater is just too much fun

I'd suggest instead that webkit/webapp changes like this might potentially cause 3rd party crashes/issues, and Apple instead released safari-only changes allowing 3rd party devs to test in-app content against a field deployed browser version prior to releasing the same changes to web-app in an upcoming beta version. Apple COMMONLY deploys this same logic to other aspects of both iOS and OS X, giving devs access to the change without impacting existing running code, and then gives them 1-2 release versions to accommodate the change before they risk breaking legacy code.