5 ms·

IOS 4.3 Nitro JS engine disabled for full screen apps and uiwebview

88 points by marcusramberg 16y ago

zitterbewegung 16y ago
I wonder what is the reasoning behind disabling the faster JS engine for full screen apps and uiwebview?
- ig0rskee 16y ago
  Does anybody have insights into general performance implications of using UIWebViews vs Mobile Safari?
  - buymorechuck 16y ago
    There are several, but in particular, JavaScript seems to run 2X slower in UIWebViews vs Safari. on iOS 4.3
  - tgriesser 16y ago
    From what I've been able to find, UIWebViews run as they traditionally have on 4.2, the JS just runs 2x faster exclusively in Mobile Safari, so no performance hit, just no gain either.
- kgutteridge 16y ago
  The cynics view would be because as the web app approach becomes less distinguishable from native apps speed, those web applications end up running as well on equivalent speed hardware such as Android and other platforms as they would on iOS, ceding some of iOS advantage in the richness and diversity of its applications. However it should be noted most of the popular applications in the iOS app store are in fact games The real reason is likely to be more to do with security around the js runtime, especially when UIWebView is placed in "wrapped" applications
  - masklinn 16y ago
    Or just a bug due to the setup process of UIWebView or "offline" webapps not enabling Nitro where Safari's usage of webkit does.
buymorechuck 16y ago
I suspect the reason is due to security concerns about running JIT executable code in 3rd-party apps. I have a harder time understanding full-screen web apps, however. Those should be running within some kind of full-screen Mobile Safari mode.
- dunham 16y ago
  It's possible that only MobileSafari.app is signed with the entitlements needed to do JIT (write to executable memory segments?). The full-screen web apps open as separate applications and might not look like MobileSafari to the OS.
  - comex 16y ago
    Exactly-- only MobileSafari has the "dynamic-codesigning" entitlement, but full-screen web apps open in WebSheet.app. This is almost certainly an oversight. On the other hand, I doubt App Store apps will get that entitlement anytime soon.
- happybuy 16y ago
  Yes I believe when the SquirrelFish (now Nitro) JS engine was initially announced that it relied on allowing certain items in memory to become executable (most likely due to the JS interpretation and then execution) - and that due to the security model in iOS and the ARM processors this was not allowed. In general I believe its good to not allow random bits of memory to become executable as it can easily introduce a large number of security and memory overflow vulnerabilities. Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Which would make sense because they control and are responsible for Safari, but to allow any application to circumvent this restriction could open iOS up to large security issues.
  - blinkingled 16y ago
    >Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Given Safari is the biggest attack surface and regularly falls prey to exploits they should also disable the JIT for Safari. (Most iOS exploits like the Pwn2Own ones, and jailbreakme.com ones are due to bugs in Safari.)
matclayton 16y ago
Does apple actively want native apps to out perform html5? Of course, but enough that would hinder the natural install points, seems a little crazy even for apple...... is this the same on the iPad and iPhone/iPod?
- Klonoar 16y ago
  You can't actively want what will always be. I love Webkit/et all, but people need to get this through their heads that native will always trump JS when it comes to iOS development.
geuis 16y ago
Some numbers for folks to examine based on 3x test of each state: Non-fullscreen: 4094.5ms (test average) Fullscreen: 10528.2ms (test average)
- geuis 16y ago
  A follow-up. I'm running sunspider on both my iPhone 4 w/ 4.3 and iPad v1 with 4.3 to get better numbers on this. I'm actually seeing my iPhone is 2x faster than the iPad in completing this test. This seems odd...
  - geuis 16y ago
    Yes, what was odd was that the 4.3 update started but hadn't finished when I was running those tests. Merde. I'm updating my numbers.
- geuis 16y ago
  I've done more thorough testing and posted the results here: http://news.ycombinator.com/item?id=2318412 http://news.ycombinator.com/item?id=2318412 I've re-done the tests for the iPad. Mobile Safari javascript is more than 2x as fast when run in the browser versus fullscreen mode.
naz 16y ago
I think Hanlon's razor applies here. A lot of people will be slating Apple for sabotaging non-native apps, but it's really just a bug.
- benologist 16y ago
  Yes, it's bug #108978: Can't figure out where to extract 30% of revenue from.
  - alextgordon 16y ago
    How does making app store apps slower increase apple's revenue?
    - thought_alarm 16y ago
      That's the beauty of conspiracy theories: they don't have to make any sense.
      - statictype 16y ago
        Missing the point. Apple doesn't and can't control web apps that are outside the App Store. They can control what goes into the App Store. Preventing web apps from performing on par with native apps will discourage development outside their controlled app store. I'm not saying that Apple is doing this, just that the conspiracy theory does make sense and even has prior art (see Microsoft and IE6)
      - alperakgun 16y ago
        web apps on home page and apps wrapped web components which still use html, js etc are punished. so it is not a conspiracy, it is a bug but if it is intentional by apple; it is a faux pas. welcome to ie6 in ios; intentional punishment of web apps to cut itunes cannibalization.
    - jrockway 16y ago
      It makes web apps (that work with any platform) slower, while native apps are not penalized. That increases Apple's revenue because it will encourage people to make native apps instead of web apps, which has a two-fold effect: one, they get 30% of the app's revenue, and two, you have to buy an iPhone to use it. I'm sure it's a bug, but if it's not, it's not really a bad thing for Apple.
some1else 16y ago
I would paraphrase this to "Nitro JS not enabled for fullscreen apps and UIWebView". Their exact motives will be revealed when they announce whether they plan to fix it or not. Sure looks like a convenient bug though. In a sense, Microsoft probably didn't intentionally loose to other browsers with IE6, it was just very convenient for them to keep the entire web application ecosystem gimped for a few releases of Office...
geuis 16y ago
To add another note to this, its a bug that Apple seems to know about. I can't link to it because its marked CONFIDENTIAL across the top of the dev forums, but in short its known about and being investigated.
g-roc 16y ago
it's a known issue to apple, several bug reports have been filed, so let's wait and see (hope). it's pretty discouraging nevertheless. if you want to confirm with the V8 benchmark, you can use my homescreen-enabled version (version 5) here: http://pavingways.com/test/v8-5/ http://pavingways.com/test/v8-5/ - numbers are around 230 in safari to only 90 as a homescreen app :(

88 points by marcusramberg 16y ago

zitterbewegung 16y ago

I wonder what is the reasoning behind disabling the faster JS engine for full screen apps and uiwebview?

ig0rskee 16y ago
Does anybody have insights into general performance implications of using UIWebViews vs Mobile Safari?
- buymorechuck 16y ago
  There are several, but in particular, JavaScript seems to run 2X slower in UIWebViews vs Safari. on iOS 4.3
- tgriesser 16y ago
  From what I've been able to find, UIWebViews run as they traditionally have on 4.2, the JS just runs 2x faster exclusively in Mobile Safari, so no performance hit, just no gain either.
kgutteridge 16y ago
The cynics view would be because as the web app approach becomes less distinguishable from native apps speed, those web applications end up running as well on equivalent speed hardware such as Android and other platforms as they would on iOS, ceding some of iOS advantage in the richness and diversity of its applications. However it should be noted most of the popular applications in the iOS app store are in fact games The real reason is likely to be more to do with security around the js runtime, especially when UIWebView is placed in "wrapped" applications
- masklinn 16y ago
  Or just a bug due to the setup process of UIWebView or "offline" webapps not enabling Nitro where Safari's usage of webkit does.

buymorechuck 16y ago

I suspect the reason is due to security concerns about running JIT executable code in 3rd-party apps. I have a harder time understanding full-screen web apps, however. Those should be running within some kind of full-screen Mobile Safari mode.

dunham 16y ago
It's possible that only MobileSafari.app is signed with the entitlements needed to do JIT (write to executable memory segments?). The full-screen web apps open as separate applications and might not look like MobileSafari to the OS.
- comex 16y ago
  Exactly-- only MobileSafari has the "dynamic-codesigning" entitlement, but full-screen web apps open in WebSheet.app. This is almost certainly an oversight. On the other hand, I doubt App Store apps will get that entitlement anytime soon.
happybuy 16y ago
Yes I believe when the SquirrelFish (now Nitro) JS engine was initially announced that it relied on allowing certain items in memory to become executable (most likely due to the JS interpretation and then execution) - and that due to the security model in iOS and the ARM processors this was not allowed. In general I believe its good to not allow random bits of memory to become executable as it can easily introduce a large number of security and memory overflow vulnerabilities. Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Which would make sense because they control and are responsible for Safari, but to allow any application to circumvent this restriction could open iOS up to large security issues.
- blinkingled 16y ago
  >Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Given Safari is the biggest attack surface and regularly falls prey to exploits they should also disable the JIT for Safari. (Most iOS exploits like the Pwn2Own ones, and jailbreakme.com ones are due to bugs in Safari.)

matclayton 16y ago

Does apple actively want native apps to out perform html5? Of course, but enough that would hinder the natural install points, seems a little crazy even for apple...... is this the same on the iPad and iPhone/iPod?

Klonoar 16y ago
You can't actively want what will always be. I love Webkit/et all, but people need to get this through their heads that native will always trump JS when it comes to iOS development.

geuis 16y ago

Some numbers for folks to examine based on 3x test of each state: Non-fullscreen: 4094.5ms (test average) Fullscreen: 10528.2ms (test average)

geuis 16y ago
A follow-up. I'm running sunspider on both my iPhone 4 w/ 4.3 and iPad v1 with 4.3 to get better numbers on this. I'm actually seeing my iPhone is 2x faster than the iPad in completing this test. This seems odd...
- geuis 16y ago
  Yes, what was odd was that the 4.3 update started but hadn't finished when I was running those tests. Merde. I'm updating my numbers.
geuis 16y ago
I've done more thorough testing and posted the results here: http://news.ycombinator.com/item?id=2318412 http://news.ycombinator.com/item?id=2318412 I've re-done the tests for the iPad. Mobile Safari javascript is more than 2x as fast when run in the browser versus fullscreen mode.

naz 16y ago

I think Hanlon's razor applies here. A lot of people will be slating Apple for sabotaging non-native apps, but it's really just a bug.

benologist 16y ago
Yes, it's bug #108978: Can't figure out where to extract 30% of revenue from.
- alextgordon 16y ago
  How does making app store apps slower increase apple's revenue?
  - thought_alarm 16y ago
    That's the beauty of conspiracy theories: they don't have to make any sense.
    - statictype 16y ago
      Missing the point. Apple doesn't and can't control web apps that are outside the App Store. They can control what goes into the App Store. Preventing web apps from performing on par with native apps will discourage development outside their controlled app store. I'm not saying that Apple is doing this, just that the conspiracy theory does make sense and even has prior art (see Microsoft and IE6)
    - alperakgun 16y ago
      web apps on home page and apps wrapped web components which still use html, js etc are punished. so it is not a conspiracy, it is a bug but if it is intentional by apple; it is a faux pas. welcome to ie6 in ios; intentional punishment of web apps to cut itunes cannibalization.
  - jrockway 16y ago
    It makes web apps (that work with any platform) slower, while native apps are not penalized. That increases Apple's revenue because it will encourage people to make native apps instead of web apps, which has a two-fold effect: one, they get 30% of the app's revenue, and two, you have to buy an iPhone to use it. I'm sure it's a bug, but if it's not, it's not really a bad thing for Apple.

some1else 16y ago

I would paraphrase this to "Nitro JS not enabled for fullscreen apps and UIWebView". Their exact motives will be revealed when they announce whether they plan to fix it or not. Sure looks like a convenient bug though. In a sense, Microsoft probably didn't intentionally loose to other browsers with IE6, it was just very convenient for them to keep the entire web application ecosystem gimped for a few releases of Office...

geuis 16y ago

To add another note to this, its a bug that Apple seems to know about. I can't link to it because its marked CONFIDENTIAL across the top of the dev forums, but in short its known about and being investigated.

g-roc 16y ago

it's a known issue to apple, several bug reports have been filed, so let's wait and see (hope). it's pretty discouraging nevertheless. if you want to confirm with the V8 benchmark, you can use my homescreen-enabled version (version 5) here: http://pavingways.com/test/v8-5/ http://pavingways.com/test/v8-5/ - numbers are around 230 in safari to only 90 as a homescreen app :(