Slashdot Mirror
Apple Disputes Browser Speed Findings, Says Mobile Safari's the True Contender
An anonymous reader writes "Apple has hit back over claims that the browser shipped with its iPhone, iPod Touch, and iPad devices is significantly slower than Android's equivalent, calling the independent testing 'flawed.' 'They didn't actually test the Safari browser on the iPhone,' Apple's Kerris argues. 'Instead they only tested their own proprietary app, which uses an embedded Web viewer that doesn't actually take advantage of Safari's Web performance optimisations.' This, claims testing firm Blaze.io, is news to the world. 'Embedded browsers are expected to behave, for the most part, the same as the regular browser,' the company stated, defending its methodology. 'However, Apple is now stating that their embedded browser, called UIWebView, does not share the same optimisations MobileSafari does.'"
1st post, so Chrome must be fastest...
This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
If they allow apps to use UIWebView with Nitro they would need to allow all those apps to mmap(PROT_EXEC,) on pages, download code and stick on to the pages and execute it - bypassing Apple's control.
Now will come a multi process WebKit2 (a la Chrome) that will allow them to only give executable page permission to WebKit2 process and apps can just do IPC to it.
It has been covered that the reason is that Nitro compiles ECMAScript down to ARM machine instructions and then sets the memory region that contains the compiled code to be executable. This is a dangerous ability for arbitrary apps to have and that's why right now only Safari on iOS 4.3 has this capability. No stupid conspiracy theories are needed here. And it's not a bug either.
When 1person suffers from a delusion,it is called insanity.When many people suffer from a delusion,it is called religion
So what do we have now. Natives Apps that run in he browser. If lockin and Apple rules are such an issue, then why no run he app in a browser? Probably because most develpers like the lockin and he profit opportunities i provides. They my bitch about Apple, but they are not exacty running away.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
if "slow" means "the same speed as they were two weeks ago when we weren't complaining about how slow they are", then, yes, they run at the same speed they did two weeks ago when nobody was complaining how slow they were. If you have a 10 terrabyte porn collection, you don't lose porn just because your friend has a 15 terrabyte porn collection.
Do you even lift?
These aren't the 'roids you're looking for.
The problem isn't with the intentional ARM code written by the applications. It is with code injected into the application (via an exploitable bug, like a buffer overflow) by malicious software. Setting noexec on data pages and nowrite on code pages is a security feature that prevents a large class of remote exploits, by ensuring that only the original code is executed.
Compiling code on the fly should only be allowed on applications that have been carefully scrutinized for bugs, not every crappy app with an embedded web-browser. Even enabling it for Safari is risky, but is a lower attack surface than enabling it for any and all apps.
Once iOS gains WebKit 2, this issue should go away. Development activity is pretty rapid right now, so there may be a big push to have this done for iOS 5. A story on Ars indicates bugs about web apps not using the new Nitro engine were closed with "not to be fixed by exec order". Based on that, I'm guessing the following occurred:
Apple execs wanted web browsing to be faster on iOS, by taking advantage of the same tech that is being used to accelerate browsers on the desktop. They also wanted to maintain the secure environment in iOS, and bring more security to the OS X side. WebKit 2 had been in development internally for a little while, and was opened up to the public for contributions in April 2010. Google, and others have been making major contributions to it, and development is proceeding.
Apple also had plans to release the iPad 2, along with an eventual iPhone 5 and new iPod Touch featuring dual core processors. iOS 5 is too far out, so iOS 4.3 had a lot of development effort spent on making MobileSafari faster. Because WebKit 2 wasn't ready, security wasn't ready to open it up to the world, and the decision was made to do what they could in the time frame allowed, and make it open to other developers later.
The "not to be fixed by exec order" is likely in place to prevent engineers from wasting time on trying to bring new improvements to old frameworks, and instead keeping engineers focused on finishing iOS 5, possibly with WebKit 2 in time for the iPhone 5 release this summer.
Apple is a hardware company (as far as where the majority of their profits come from), and so software development relating to iOS will always be driven by hardware release cycles. They may slip features from software, but key pieces have to be in place to meet the hardware cycle. It's looking like March will be new iPad time, June for iPhones, then September for iPods. iPads will debut new CPUs, iPhones will debut new major iOS releases and some other features (gyroscope, possibly NFC, etc), and iPods will just be a phoneless iPhone. Each release comes with a new iOS, iPad being a final point release of the previous iOS, iPhone being the new one, then iPods gaining the first point release of the new OS.
John Gruber had a good analysis of all this. Basically, the embedded UIWebView didn't change in speed between 4.2 and 4.3, but Safari did. The fact that outside apps didn't speed up has been called "Apple slowing down" other apps.
The new JS engine (Nitro) uses JIT, which needs writable, executable pages in memory. In iOS 4.2 and before, this didn't exist because of security concerns. In 4.3, it exists, but only for MobileSafari. Because of this, UIWebView in other applications can't use JIT, which is where the performance gains came from.
So it's a security thing. Apple has decided to error on the side of security here. That's the executive order, that they won't reduce the security (my speculation/interpretation). Android isn't being as pedantic about it. Gruber suggest it could be possible (in a future update) to run the JIT in a separate process, so the main process doesn't need the wrire/execute pages to keep security. It's a good idea, it'd be nice if Apple did it. I'm not sure it matters that much.
So the problem with this comparison is that instead of MobileSafari, they used something using UIWebView, which doesn't have the permissions to do JIT. Thus it's an unfair comparison, in that users will see faster speeds than they are reporting (since users will use Safari, they have no choice).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
No, it's not news to the world, it's news to Blaze.io. It was already widely reported that UIWebView didn't support the latest Safari speed boost days before their study was published.
Bogtha Bogtha Bogtha
John Gruber of Daring Fireball carefully lays out the situation in this post from a couple of days ago. I know that a lot of people like to make up all sorts of conspiracy theories and bizarre motives when it comes to Apple, but the truth is a lot more interesting and a lot less sinister: http://daringfireball.net/2011/03/nitro_ios_43
You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.
Yeah but if you were Nostradamus, the predictions would be much more fun.
Quatrain XI: The searching metal man roze to fell the mighty apple. Chrome, Fire, and Foxes all rejoiced at the silence atop the buffering hills.
PocketPermissions Android Permission Guide
No, there's more to it than that. UIWebView cannot compile arbitrary code, but Safari's JavaScriptCore (Nitro nee "Squirrelfish Extreme") does. http://arstechnica.com/apple/news/2011/03/confirmed-some-web-apps-not-seeing-ios-43-javascript-speedup.ars