Submitted by
Users who Dugg This
Mendokusai Daiyo
17822 Followers
Carly Wilson
3024 Followers
adam jones
12155 Followers
Lt Gen Panda
17116 Followers
SleepingZombie
332 Followers
AngelWardriver
11953 Followers
Russ Smith
18390 Followers
meedMar 20, 2011
Apple needs to stop thinking their s**t don't stink if you ask me.
spuy767Mar 20, 2011
You should actually read the article. The blaze test used 3rd party software which, for security purposes, cannot use the same JavaScript engine as the actual safari browser. All anyone needs to do is open one of the myriad of online js benchmarks to realize that the new safari is a whole lot faster.
patrickbrownMar 20, 2011
So the browser may or may not be slower in iOS, but the embedded browser is certainly much slower.
Not as bad as having a much slower browser, but not something Apple wants to advertise either: "We ARE slower for web apps except when using the browser directly." -- not a good message for a company that railed against flash in favor of HTML 5 apps.
jwdavMar 20, 2011
It's more like Safari is faster, not that UIWebkit is slower. The improvements will make their way to UIWebkit at some point in the near future.
r3zonanceMar 22, 2011
As previously said. Mobile Safari is FASTER, UIWebView (embedded web viewer) hasn't, and was not intended to, have changed.
dagamer34Mar 20, 2011
It's not just slower in web apps, but even native apps because the only beneficiary of the new Nitro Javascript engine is the Mobile Safari app. And I spend most of my time in an RSS reader loading up articles, so it doesn't really benefit me that much.
16x9Mar 20, 2011
On the surface of this issue Apple is correct, 3rd party apps are never given access to the cooler (faster) features of iOS that their own apps enjoy.
However, this brings up another more important issue. Why? Apple is famous for making everyone who isn't them use the less efficient methods of getting the task done. And if that weren't bad enough, then Apple has the balls to complain about the efficiency of these apps (as they did with Flash on the Mac) when they know damned well that it is Apple itself that is blocking these apps.
I don't even know how to respond to Apple apologist John Gruber's claim that this is a security issue. Remove only the top layer of topsoil from this argument and you'll see this as absurd.
By the way, I'm a fan of Apple's products from way back (typing this on 27" iMac right now). But their business practices, not so much.
tzodyaqMar 20, 2011
To answer your question of "why": when Apple releases a new/cooler/faster feature to the public, it is only tested with their applications. It's essentially a public beta, but since there was enough QA on their own applications, they release them anyway.
It's only after a few more cycles of these things being available and proven out that they are handed over to the developers. I don't think that this is some nefarious plot against developers or those who are "not Apple" but rather a precautionary step to make sure that what is released to the wild - and what developers rely on to make their product - is stable and reliable.
16x9Mar 20, 2011
Thank you for the thoughtful response, tzodyaq. I take your point and I don't necessarily think you are wrong.
To be honest, my primary issue isn't that Apple sets aside the newest, coolest stuff just for themselves but rather that they then turn around and use the disparity that they have created as a big part of their excuse for blocking certain 3rd party technologies.
jlboanMar 20, 2011
Someone must be holding the browser the wrong way.
silnerMar 20, 2011
Hang on. So we're really arguing that the speed of the Apple apps is fine but all the others are crap, whereas everything on the Android system is equally fast. So we're saying Apple operates an apartheid software system and that's absolutely fine with Apple fans apparently?
jwdavMar 20, 2011
Simply, Apple improved the speed of Moble Safari - nothing to complain about so far.
Those improvements required an app to be able to mark pages in memory as executable. Apple granted Safari the right to do that, but was unwilling to extend this right to third party apps until it had dealt with the inherent security issues. This is not an uncommon approach for Apple ... private beta testing, instead of public - not a bad idea when changes affect security like this.
Unless, you don't have any security concerns as far as what code runs where with what privileges, in which case, everything is "equally fast".
v1ncentMar 20, 2011
This is yet another reason I don't buy Apple - the purposeful limitations forced on me and the lack of choice. Droid X for me.
killerhamMar 20, 2011
Murtaza talked about this on http://untitleddtech.blogspot.com/2011/03/blazes-so-called-speed-test.html a couple of days ago.
vitriolandangstMar 20, 2011
The tests were both Valid and Invalid:
>> The Valid part, was they were using web "features" that other apps that embed functionality would use -- so, it's LIKE what you would find in a third-party application.
>> It was INvalid, in that the Safari browser itself, is much more optimized and uses a very fast Javascript engine -- there is even a custom ASIC to deal with "just in time code" because that normally gets threaded as "data" rather than as code -- which is why Javascript can often run slowly.
>> The other issue I have -- is the embedded browser issue is NOT as simple as just saying; "let third parties use the same thing Apple does." From what I've read, the Safari browser runs in a sandbox on the iPhone -- and it can't access data outside of itself nor run applications that effect anything but inside the browser. The "embedded" browser, is an earlier version -- but it can run on 3G phones without requiring 3GS and newer phones. It has a LOT to do with security.
So, Android has a browser that shoots from the hip -- and can be exploited by rogue apps, or even off the WiFi.
You also need to use "real world" apps and human interactions to really get a feel for the difference in speed. People don't just load a web page -- the interact with it, scroll around and zoom in and out.
>> I really CANNOT say, whether or not Apple is right or not about speed -- I expect they would protest whether it was a real issue or not. But the Blaze study, could easily be corrupted and get whatever results they want, because THEY are creating the embedded app - they might be doing it wrong, or they might be doing what is typical for a developer.
But I would have to point out; Apple will make the web browsing experience better, and the phone you buy now, will be upgraded in the future. With Android -- that isn't even LIKELY. You have to enjoy what you are getting in performance NOW and not depend or hope for future upgrades -- it's pretty hit or miss with all the other platforms.
jwdavMar 20, 2011
Start allowing any third party app to execute code in memory and you have a platform that makes early Windows look secure. This opens up WiFi, memory cards and malicious apps to do whatever they want and access/modify anything on the device.
zahariaoMar 21, 2011
what exactly is the relation between security and the crappy js engine they use for embedded browser view ? they're just full of s.t as usual, the point was made, the embedded browser on ios is 50% slower than droid's, the title could be wrong but the results are correct since even Apple didn't even bother to contest them they only said the browser is faster not that the results are wrong.
jwdavMar 21, 2011
The relationship is that the acceleration is based on JIT compiled code, requiring execute permissions in memory, which is not secure and Apple does not normally allow it. In this case, they made an exception for Safari. Apple often beta tests on their own apps before releasing code to developers.
It will ultimately show up in UIWebkit, which is how third party apps implement web browsing.
The test is a valid test of speed for third party apps, but it is not a test of Safari.
The relation to security, is that if any app can execute code in memory, especially other apps code, that it is a massive security hole. An app should be able to read/write to it's own space only. Safari is the sole exception to this in iOS. Google seems to have no problem allowing it.