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.
Right, and does Apple allow alternate web browsers? Last I knew they disapproved anything that competed with an iPhone built-in app, like Google Voice, which duplicated phone functionality.
iCab and all other "browsers" on iOS are skins round the built in webkit. (It would be interesting to see if and how they are effected by this bug).
Opera hasn't released its actual browser for iOS since doing so is banned by Apple's policies. Same for Mozilla. What they have released is Opera Mini which displays pages rendered by what is effectively a server-side browser.
Their mobile browser is called Opera Mobile, Opera Mini is something slightly different from a browser, for example it doesn't execute client-side javascript.
Well, not really. Web Apps are faster, it is the "packaged apps" using a UIWebView that did not gain anything, and Apple is getting 30% of those as well.
So, it would not have make sense to slowdown UIWebView and accelerate Web Pages only for revenue point of view.
I think it is, as often, a interlaced tech-business issue:
1) Security: There might a genuin security concern the way the JIT works.
2) Exclusivity: I think Apple exec saw #1 as an opportunity to keep the performance gain as an exclusivity benefit for a while (Safari vs other browsers).
3) Developers: Apple's exec are probably realizing that there is a momentum starting to build around "Universal HTML5 Packaged apps," which would allow developers to decouple production from distribution. So, while they probably do not want to completely stop this momentum, slowing it a little might be seen as a good compromise for them.
Now, do not get me wrong, I am really disappointed at this news, and hope Apple will bring Nitro to UIWEbView soon.
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)
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.
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.
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.
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.
>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.)
A JIT works by compiling some chunk of code into a section of executable memory, then jumping to that location. As I understand it, iOS hasn't previously allowed execution of code from "data memory" (various people were curious about this very thing when it was announced they were shipping a JIT). Presumably, the Safari process has some special flag that allows it to write to executable memory, but most other processes do not. My guess is that someone forgot to add this flag to whatever application handles "full screen" pages, although maybe there is a legitimate reason for this.
Probably time for Apple to start using the process sandboxing from Chromium in Safari. If you are running a jit you need to make data executable so it isnt going away. As Apple control the OS they should be able to design a good Javascript sandbox.
Actually, it looks like Apple's approach is WebKit2 <http://trac.webkit.org/wiki/WebKit2>, which will handle the UI/web process separation itself, allowing any client application to benefit (as opposed to Chromium's current approach).
Perhaps you just meant the UI/web process separation itself, but it's interesting to note that Apple is going for a more general-purpose solution.
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.
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.
Can't be security. From what I understood Web apps work in the browser but when bookmarked as home-screen icons, they don't use the new js engine (even though it's still running in Safari)
Benign explanation: some bug in safari
Tin foil hat explanation: Apple doesn't want web apps to be as good as native apps. This explanation kind of falls apart when you ask why they would bother boosting the js engine at all.
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...
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...
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?
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.
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/ - numbers are around 230 in safari to only 90 as a homescreen app :(
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
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.
