Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple Disputes Browser Speed Findings, Says Mobile Safari's the True Contender

timothy posted more than 3 years ago | from the you-say-one's-better-I-say-one's-worse dept.

Android 155

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.'"

Sorry! There are no comments related to the filter you selected.

Chrome (3, Funny)

webmistressrachel (903577) | more than 3 years ago | (#35538368)

1st post, so Chrome must be fastest...

Re:Chrome is Fast Because It's Lightweight! (-1)

Anonymous Coward | more than 3 years ago | (#35539338)

1st post, so Chrome must be fastest...

you're female and you got a first post on a Slashdot story

that means youre fat

lose weight, fatty

Re:Chrome is Fast Because It's Lightweight! (2, Insightful)

Anonymous Coward | more than 3 years ago | (#35540076)

I love beating this dead horse! (0, Redundant)

The End Of Days (1243248) | more than 3 years ago | (#35538384)

I'm not sure how this is worth posting... I mean I guess there are the ad views to consider but really, this has been fully covered already in a multitude of stories.

Still, that Slashdottian Apple-hate must be worth a lot of money to Taco and friends.

Re:I love beating this dead horse! (1)

MobileTatsu-NJG (946591) | more than 3 years ago | (#35539648)

I'm not sure how this is worth posting... I mean I guess there are the ad views to consider but really, this has been fully covered already in a multitude of stories.

Still, that Slashdottian Apple-hate must be worth a lot of money to Taco and friends.

This story's redundant, the post I'm quoting isn't.

Mobile Safari's caching and asynchronous loading (2)

bonch (38532) | more than 3 years ago | (#35540240)

However, Apple is now stating that their embedded browser, called UIWebView, does not share the same optimisations MobileSafari does.

UIWebView is just a WebKit view that third-party applications can embed; it's not a complete browser on its own. MobileSafari has custom caching mechanisms and asynchronous loading, which is what Apple is referring to. There's more to a browser application than just the engine.

Re:Mobile Safari's caching and asynchronous loadin (3, Informative)

omfgnosis (963606) | more than 3 years ago | (#35540648)

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 [arstechnica.com]

Oh hell. (2)

revscat (35618) | more than 3 years ago | (#35538396)

This is turning into a Big Deal, isn't it?

So, Mobile Safari proper uses Nitro and has seen some good performance improvements. For reasons unknown, these changes didn't make it into apps that use UIWebView.

You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

1) Apple is evil and trying to cripple web performance so that people buy apps
2) It's a bug and/or simply didn't make into iOS 4.3 because it wasn't prioritized.

Not Reasons Unknown! (3, Insightful)

VirginMary (123020) | more than 3 years ago | (#35538428)

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.

Re:Not Reasons Unknown! (2, Insightful)

Anonymous Coward | more than 3 years ago | (#35538462)

So what you're saying is that Mobile Safari does something dangerous and exploitable, and that it's not a bug, it's a feature?

Just want to make sure we're on the same page here.

Re:Not Reasons Unknown! (4, Interesting)

MoonBuggy (611105) | more than 3 years ago | (#35538498)

Presumably Apple is happy that, being the people who wrote the entire OS in the first place, they can implement this behaviour securely in Safari. They don't have the same faith in giving that ability to any random app developer, who could end up creating a difficult to spot vulnerability via the API either by malice or ignorance.

Re:Not Reasons Unknown! (0)

Anonymous Coward | more than 3 years ago | (#35538548)

If the capability is available to Mobile Safari as a user space applications, how is not available to any other other user space application?

Re:Not Reasons Unknown! (-1)

Anonymous Coward | more than 3 years ago | (#35538994)

read the post you replied to you fucking idiot.

Re:Not Reasons Unknown! (1)

vinehair (1937606) | more than 3 years ago | (#35539058)

read the post you replied to you fucking idiot.

Thanks for the useful reply. But you really don't understand what was just said. What, exactly, is restricting the use of this capability to just Safari? Protections, DRM style authentication? Nobody has ever worked around those ever. Nope.

Re:Not Reasons Unknown! (2, Insightful)

node 3 (115640) | more than 3 years ago | (#35540188)

It's part of the iOS security model. You're right that this model can be hacked. It's commonly referred to as 'jailbreaking'.

However, if the user never jailbreaks their iOS device, this security model remains in place. There's also always the potential for remotely exploitable flaws, but that's no different than any other network-capable OS. By confining the new javascript implementation to Safari, Apple is blocking local exploits.

Also, it's technically feasible that WebKit2 can allow third-party access to the new engine without compromising iOS's security model.

Re:Not Reasons Unknown! (0)

Anonymous Coward | more than 3 years ago | (#35538572)

So surfing the net can open iOS to exploits? It the Web browser that can run any random code from the net, how is that different than some random app developer?

Re:Not Reasons Unknown! (4, Informative)

Random Destruction (866027) | more than 3 years ago | (#35539374)

So surfing the net can open iOS to exploits?

That wouldn't be anything new. I jailbroke my iphone4 by going to a website.

Re:Not Reasons Unknown! (1)

Anonymous Coward | more than 3 years ago | (#35538812)

All JITs are exploitable - even if you could reliably ensure only the JIT can write executable pages, you could just use ROP to make the JIT compile code for you.

Re:Not Reasons Unknown! (0)

Anonymous Coward | more than 3 years ago | (#35538482)

And how is it not dangerous that safari has this?

Re:Not Reasons Unknown! (2)

Nightlight3 (248096) | more than 3 years ago | (#35538516)

Native apps (including those running UIWebView) already use native ARM machine instructions as they wish (you can set compiler to to compile into pure native ARM instructions or write ARM assembly code if you want; Apple only controls which system APIs developers can access, which they can do from JS->machine compiled code equally well). So that "explanation" doesn't make much sense. It is more likely that they merely rushed the iOS upgrade out before their programmers had finished the porting to UIWebView.

That's not the problem. (5, Informative)

pavon (30274) | more than 3 years ago | (#35538730)

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.

Re:That's not the problem. (0)

Anonymous Coward | more than 3 years ago | (#35539502)

Yeah, there's a good explanation why Safari can have a JIT for javascript, and your app with an embedded browser can't.

Because, unlike an embedded browser that usually goes to a specific web page controlled by the app's developer, Safari will happily run javascript from every exploit-ridden page the user can think of.

Oh, wait, that's the opposite of a good explanation.

Wrong (1)

SuperKendall (25149) | more than 3 years ago | (#35539690)

Because, unlike an embedded browser that usually goes to a specific web page controlled by the app's developer,

The embedded browser will go to any other page too, following links. How many mobile developers are displaying pages with no links?

Are you seriously saying a Twitter client should ship with the inability to go to any link but ones the twitter app developer has whitelisted. Madness.

Re:Not Reasons Unknown! (5, Informative)

SiMac (409541) | more than 3 years ago | (#35538776)

The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit [wikimedia.org] to segregate data from code. Because of the way a JIT works, it needs to be able to execute code in the data area of memory. Allowing every app to do this would effectively eliminate the additional security that the NX bit provides.

Re:Not Reasons Unknown! (3, Insightful)

tlhIngan (30335) | more than 3 years ago | (#35540064)

The problem is not using ARM instructions. The problem is where those ARM instructions are. The iPhone presumably uses something like the NX bit to segregate data from code. Because of the way a JIT works, it needs to be able to execute code in the data area of memory. Allowing every app to do this would effectively eliminate the additional security that the NX bit provides.

I believe this to be the case. It may also explain why IOS 4.3 is 3GS and later, excluding the iPhone 3G. I believe the ARMv7 architecture introduces the NX bit into the platform, something that the ARM11 used in the original iPhone and iPhone 3G don't have. The 3GS uses a Cortex A8 and the iPhone 4 is a Cortex A8 derivative CPU, which means they have NX support. This would mean that no, IOS 4.3 will not run on the iPhone 3G.

The other thing is, IOS 4.3 probably also runs Safari in an even more locked down user account - there's root, and mobile (apps run under this user account). Safari may be set to run under an even stricter sandbox that's chroot and has no permissions anywhere else or even alter any files via standard permissions, a la nobody. Apps won't have access to that since there's probably little the account can actually do. This way the attack surface via Safari is minimal as the native code can't really run amok without finding a local root kernel exploit.

Re:Not Reasons Unknown! (0)

Anonymous Coward | more than 3 years ago | (#35538868)

Third party apps aren't allowed to create or modify executable pages, hence no JIT. There's no general way to make JIT compatible with W^X, because even if you check what code is trying to make executable pages you can still just use ROP to call those JIT-approved functions and manufacture the particular code sequence you want.

Re:Not Reasons Unknown! (0)

Anonymous Coward | more than 3 years ago | (#35538520)

Wow. That doesn't sound safe. First thought was guess the 5 sec Apple pown to ownage will be even quicker with this?

Seriously, anybody have any comments on the safety of this / what prevents a small bug in Safari from easily becoming arbitrary code execution?

Or even the possibility that some special javascript doesn't even need a Safar bug, just this feature to do evil stuff on the device?

Re:Not Reasons Unknown! (2)

SiMac (409541) | more than 3 years ago | (#35538820)

Wow. That doesn't sound safe. First thought was guess the 5 sec Apple pown to ownage will be even quicker with this?

Seriously, anybody have any comments on the safety of this / what prevents a small bug in Safari from easily becoming arbitrary code execution?

Or even the possibility that some special javascript doesn't even need a Safar bug, just this feature to do evil stuff on the device?

JavaScript gets compiled to ARM instructions, and those ARM instructions get executed. You can't just put ARM instructions in a webpage and expect it to run. Barring a bug in the Nitro JIT, it's perfectly secure. Any JIT (including V8, JaegerMonkey/TraceMonkey, and the JVM), on any platform, necessarily has the same potential vulnerabilities. If the JIT is written properly and doesn't attempt to execute code in the parts of RAM that contain data from untrusted sources, it's not a problem. Most desktop platforms are much worse because they allow execution of code anywhere in RAM, in any application, regardless of its source. (Ever heard of a buffer overflow?)

Re:Not Reasons Unknown! (1)

Anonymous Coward | more than 3 years ago | (#35539334)

Most desktop platforms are much worse because they allow execution of code anywhere in RAM, in any application, regardless of its source. (Ever heard of a buffer overflow?)

Really? My desktop platform features DEP so it won't execute code that is marked as data. Yes, that does break the Google Chrome auto-updater (since it is a piece of crap that tries to execute data), but most apps work fine with it. When you say "most desktop platforms" I guess you really mean that most users don't enable DEP. On Windows it has been available since Windows XP SP2 - but it isn't enabled unless the user turns it on. I would imagine most other operating systems are the same?

Re:Not Reasons Unknown! (-1, Troll)

bongey (974911) | more than 3 years ago | (#35538630)

Let me see Google can code JIT secure javascript engine V8, but Apple cannot. Sounds like Microsoft, oh I mean Apple rushed an insecure javascript engine out the door. Android has had V8 since August 2010, so the iPhone has been slower until this month.

Re:Not Reasons Unknown! (5, Insightful)

SiMac (409541) | more than 3 years ago | (#35538836)

No. Google's JIT is just as insecure. The problem is not in the implementation, it's that you need to disable the NX bit [wikimedia.org] on an area of memory to run a JIT at all. There is no workaround to this, unless the JIT isn't actually a just in time compiler.

Re:Not Reasons Unknown! (1)

sgbett (739519) | more than 3 years ago | (#35539004)

Steady on, rationality and reason only 4 posts in. Must be a record!

Re:Not Reasons Unknown! (0)

Anonymous Coward | more than 3 years ago | (#35540536)

It is running the way it is meant to in the reality Distortion Field.
I, for one, welcome our sociopathic overlord!

Reason is known (0)

Anonymous Coward | more than 3 years ago | (#35538440)

This is turning into a Big Deal, isn't it?

So, Mobile Safari proper uses Nitro and has seen some good performance improvements. For reasons unknown, these changes didn't make it into apps that use UIWebView.

You don't have to be Nostradamus to see what debate that "reasons unknown" part is going to cause.

1) Apple is evil and trying to cripple web performance so that pople buy apps
2) It's a bug and/or simply didn't make into iOS 4.3 because it wasn't prioritized.

3) 3rd-paty applications are subject to restrictions on dynamically generated code for security. Nitro uses dynamic recompilation, which means that it can't be used int 3rd party applications. Ergo, those apps are stuck with iOS 4.2-level performance.

Re:Oh hell. (1)

mr100percent (57156) | more than 3 years ago | (#35538474)

I don't think Apple is trying to cripple web performance.

  • Apple had been pushing for Web apps as early as 2007, showing developers how to do it at WWDC, showcasing third-party ones on their website, and originally saying that it would offer all a user would need instead of a compiled app. The developer SDK and third-party apps only came after a year of popular demand, and appeared in iOS 2.0
  • Their marketing/PR for the new iOS update stated new faster javascript support etc. They're not going to both promote it while trying to kill it
  • Full HTML5 apps (like Google Wave for iPhone or BlackSwan) skip the App Store completely and show up as icons on the Home screen, they run outside of Safari and have application caches, as Apple specified to developers

While it's mighty peculiar that MobileSafari will run differently than Webkit-using apps, I don't think this is malice by Apple.

Re:Oh hell. (5, Insightful)

Drakino (10965) | more than 3 years ago | (#35538750)

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.

Re:Oh hell. (4, Informative)

MBCook (132727) | more than 3 years ago | (#35538904)

John Gruber had a good analysis [daringfireball.net] 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).

Re:Oh hell. (2)

Hope Thelps (322083) | more than 3 years ago | (#35540518)

That's the executive order, that they won't reduce the security (my speculation/interpretation).

That doesn't appear to make any sense.

Normally you'd expect it to be the exact same code running the embedded web apps as running the browser apps, just no chrome. i.e. you'd expect it to be Apple's code running, with whatever security Apple has written into it.

How does not displaying the chrome give rise to a security risk? If there's a security vulnerability from running your javascript using Apple's engine then that risk is identical with or without the chrome - isn't it?

Re:Oh hell. (5, Funny)

alostpacket (1972110) | more than 3 years ago | (#35539100)

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.

Re:Oh hell. (1)

Tharsman (1364603) | more than 3 years ago | (#35539472)

If you care, and don't just want to pretend Apple is EEEEVILL, you can easily find the reasons.

Here is a link to make it easier. [daringfireball.net]

Short version: Security. Nitro uses JIT and that allows javascript to access memory as a native application.

DUH. (0)

MichaelKristopeit400 (1972448) | more than 3 years ago | (#35538420)

standards be trippin', yo.

Re:DUH. (0)

YoshiDan (1834392) | more than 3 years ago | (#35538574)

your mum's face be trippin

Re:DUH. (0)

MichaelKristopeit423 (2018892) | more than 3 years ago | (#35538622)

you're an idiot.

cower in my shadow behind your chosen digital gaming based pseudonym some more, feeb.

you're completely pathetic.

Re:DUH. (0)

Anonymous Coward | more than 3 years ago | (#35539542)

How do you know YoshiDan picked his nickname based on the Nintendo character? He may instead be paying homage to Naofumi Yamamoto.

Re:DUH. (1)

Falconhell (1289630) | more than 3 years ago | (#35540254)

Pathetic Mike, is copy pasting the same trolls and changing the name.

2 out of 10, need to do better!

Re:DUH. (1)

MichaelKristopeit407 (2018814) | more than 3 years ago | (#35540308)

ur mum's face is copy pasting the same trolls and changing the name.

why do you cower in my shadow behind a chosen aviary religion based pseudonym? what are you afraid of?

you're completely pathetic.

No doubt related to the JS brouhaha (0)

Anonymous Coward | more than 3 years ago | (#35538424)

Ars has a good analysis of why Mobile Safari is different than the embedded browser:
http://arstechnica.com/apple/news/2011/03/confirmed-some-web-apps-not-seeing-ios-43-javascript-speedup.ars

Re:No doubt related to the JS brouhaha (-1)

Anonymous Coward | more than 3 years ago | (#35538892)

No, ars is talking about the red herring of security, if it can run things of the net, it can run things from the local drive at least as safely. Fullstop. What we need to be looking at is performance sensitive applications that would sidestep the new and improved iTax that doesn't let people but via browser if it was started through an app. Oh, look, Amazon has a webapp that can read Kindle books...

Re:No doubt related to the JS brouhaha (2)

icebraining (1313345) | more than 3 years ago | (#35539082)

No, ars is talking about the red herring of security, if it can run things of the net, it can run things from the local drive at least as safely

The difference isn't the origin, is the app running the code. They trust Safari to JIT and keep unknown code from the net contained, but not the any random app.

Real reason (4, Informative)

Anonymous Coward | more than 3 years ago | (#35538426)

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.

Re:Real reason (0)

Anonymous Coward | more than 3 years ago | (#35538470)

You're not supposed to post facts to Slashdot. You're supposed to either (l)ike or (d)islike the entity the story mentions.

Re:Real reason (3, Interesting)

bongey (974911) | more than 3 years ago | (#35538708)

4.3 has address space randomization , which is why the pwn2own exploit doesn't work any more.

Re:Real reason (0)

Anonymous Coward | more than 3 years ago | (#35539854)

>4.3 has address space randomization

That's not the problem. The problem is that some developer might release a program that allows remote code injection if you know the secret code. For example, a game that connects to the developers server and downloads a code library which the program maps in to memory and runs. Apple is afraid of people doing an end-run around their vetting process by getting an injectable program passed then injecting things which wouldn't be approved after it is accepted on to the store.

This is perfectly reasonable with Apple's "protecting the noobs from themselves since they don't know any better" strategy which seems to be working out well for them, even if I don't like it.

Universal benchmark (2, Funny)

countertrolling (1585477) | more than 3 years ago | (#35538444)

Farmville, right?

Re:Universal benchmark (0)

Anonymous Coward | more than 3 years ago | (#35539936)

If only Mobile Safari or UIWebView were able to run it.

Re:Universal benchmark (1)

countertrolling (1585477) | more than 3 years ago | (#35540166)

:) Exactly...

What a wank (0)

Anonymous Coward | more than 3 years ago | (#35538450)

Is this 1997? It's been ten years since browser speed was an issue, and yes these are mobile devices, but they've been faster than decade-old computers for years themselves. I haven't used a mobile browser since 2007 that gave any issues with *speed* of the browser.

It's a metric approaching the uselessness of the old "how long does it take to scroll through a word document" speed tests of the 80s and early 1990s.

Re:What a wank (1)

Joe Tie. (567096) | more than 3 years ago | (#35538568)

I think this has a lot more to do with JIT compilation in webapps than it does for a random page. When considering the limited speed of a phone, using something that's running only as interpreted code is a pretty big limitation.

Safari is fast, it's UIWebView has no Nitro. (1, Interesting)

Marble68 (746305) | more than 3 years ago | (#35538460)

Apple is accelerating JavaScript in Safari, but not UIWebView.
In fact, I think there's a bug they're working on that apps on the home screen that use UIWebView are REALLY slow.

Check out this blog post: http://inzi.com/2011/03/will-phonegap-apps-seemingly-suck-because-of-uiwebview-in-ios-4-3/ [inzi.com]

The Safari browser has Nitro JavaScript acceleration while UIWebView doesn't.

I also read that some think Apple doesn't like the web based apps cause it can bite into their app store revenue. I don't know if that's true or not.

Re:Safari is fast, it's UIWebView has no Nitro. (5, Insightful)

larry bagina (561269) | more than 3 years ago | (#35538584)

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.

Re:Safari is fast, it's UIWebView has no Nitro. (0)

Anonymous Coward | more than 3 years ago | (#35539626)

I've always been complaining about how slow the iPhone's browser is...

Re:Safari is fast, it's UIWebView has no Nitro. (1)

brillow (917507) | more than 3 years ago | (#35539822)

Its not about the speed, but how Apple is putting itself against developers. I remember a few years ago Firefox (or some browser) being slower on OSX than Safari because Safari had access to some undocumented, locked-out resources in the OS. Didn't Microsoft get sued for this?

Re:Safari is fast, it's UIWebView has no Nitro. (1)

UnknowingFool (672806) | more than 3 years ago | (#35539904)

If anything I've seen way more complaints about Safari being slower than anything else. Also it's quite possible that two browsers running on two different engines run at different speeds. Now if Chrome was slower than Safari you might have more of point. Another problem I see with individual installations of Firefox is that users load all sorts of addons which slow it down considerably.

Re:Safari is fast, it's UIWebView has no Nitro. (0)

brillow (917507) | more than 3 years ago | (#35540168)

Of course. The point was that Apple seems to have a history of locking developers out of some features so that their products have an advantage. This isn't surprising, but its not exactly above-board either. If you want to make something nice on the iPad, Apple wants you to make an App so they make money. Even iff the app is free, you gotta buy that $100 dev kit. They just want you in their garden.

Re:Safari is fast, it's UIWebView has no Nitro. (0)

Anonymous Coward | more than 3 years ago | (#35540036)

That "undocumented feature" was a checkbox in the window's nib file to control redrawing rate while scrolling, IIRC, documented and available to everyone. WebView (not Safari) used an undocumented function to set it since it's embedded in a window and the programmer may have forgotten to set it properly.

Re:Safari is fast, it's UIWebView has no Nitro. (1)

agent_vee (1801664) | more than 3 years ago | (#35540404)

"Slow" and "Fast" are relative terms. What was "Fast" 2 weeks ago might not be so today. 10 terabytes of porn is still 10 terabytes of porn no matter what day it is.

Re:Safari is fast, it's UIWebView has no Nitro. (1)

aztracker1 (702135) | more than 3 years ago | (#35540458)

Your friend needs to setup a torrent of that... lol

Re:Safari is fast, it's UIWebView has no Nitro. (2)

RyuuzakiTetsuya (195424) | more than 3 years ago | (#35538646)

UIWebView is still pretty fast. 2 seconds versus 3 seconds is nothing to sneeze at. I'd still take it over say Trident, or whatever they based WP7's JS engine on.

I doubt that it's about not biting into app store revenue, app revenue just simply doesn't make up a huge portion of Apple's revenue. Getting hardware into people's hands is.

Re:Safari is fast, it's UIWebView has no Nitro. (1)

Anonymous Coward | more than 3 years ago | (#35538910)

Do you understand that the absolute time has nothing to do with anything? It doesn't mean every webpage will load in 3 seconds; it means that that particular page took 50% longer to render in iOS than Android.

Furthermore, app store revenue IS a substantial source for Apple. Think about it: while they do make quite a profit off all hardware, apps cost them nothing to produce, but they keep a huge percentage anyway.

What do people want (4, Insightful)

fermion (181285) | more than 3 years ago | (#35538472)

At first Apple wanted apps through safari. This might have been good as the Apps would work on any device, and Apple would have no lockin. But developers and users wanted native apps. So we have the App store, with lockin, and large cuts for Apple.

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.

Re:What do people want (4, Informative)

farnsworth (558449) | more than 3 years ago | (#35538964)

At first Apple wanted apps through safari. This might have been good as the Apps would work on any device, and Apple would have no lockin. But developers and users wanted native apps. So we have the App store, with lockin, and large cuts for Apple.

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.

If you look at the docs and the API that Apple provides for iOS, it's very clear that it was always their intention to provide a mechanism for native apps. Perhaps it was not ready when the first iPhone shipped, or perhaps there is some other reason. But it is not conceivable that the SDK/AppStore/etc was created in under a year due to developer demand.

We don't have "native apps that run in the browser". We have a Cocoa class called UIWebView which native apps can use to render html. There are all kinds of valid reasons for an app to do this. Sure, there are some apps that are *only* a UIWebView with static URLs, but they are the exception not the rule. And I'm pretty sure those are quick to be uninstalled. What we do have is the ability for a user to add a bookmark to their home screen, which basically creates an iOS app with an embedded UIWebView.

There are theories that the API, and therefore "URLs on the home screen", don't use the improved Nitro JS engine because it uses JIT, and would be susceptible to script poisoning attacks, since the App author has full access to the processes memory space. There are theories that Apple is putting this JITing out-of-process, which would mitigate or obviate these attacks. This seems to be the reason that apps that use UIWebView get the older, slower JS engine.

In any case, this has nothing to do with lockin, or profits for Apple. If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple. The only reason they have it is because customers want it, therefore it makes their hardware "more better".

Re:What do people want (2, Interesting)

bigNuns (18804) | more than 3 years ago | (#35539068)

If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple.

How does one go about doing this? Everything I have read has been speculation. As far as I can tell, no numbers have actually been released.

Re:What do people want (3, Informative)

farnsworth (558449) | more than 3 years ago | (#35539140)

If you look at the actual numbers, you will see that the AppStore is a break-even affair for Apple.

How does one go about doing this? Everything I have read has been speculation. As far as I can tell, no numbers have actually been released.

http://tech.fortune.cnn.com/2010/06/23/app-store-1-of-apples-gross-profit/ [cnn.com]

Re:What do people want (2)

bigNuns (18804) | more than 3 years ago | (#35539204)

Those are numbers based on a keynote speech and are full of assumptions. Pretty much each number comes with a "assumed" or "suggests." Anywhere you have seen real numbers and not ones made up based on somethine steve jobs said in a keynote? Not to be rude or anything but Steve Jobs has basically been caught on more than one occasion of, how should we say.... bending the truth.

Re:What do people want (3, Informative)

farnsworth (558449) | more than 3 years ago | (#35539310)

Fair enough, but you can also read the transcript where Apple CFO Peter Oppenheimer tells shareholders pretty much the same exact thing. I guess he could be lying, but that would be a much more serious thing than telling tall tales at a press event.

Re:What do people want (2, Insightful)

UnknowingFool (672806) | more than 3 years ago | (#35539990)

Every time I hear someone grouse about how no one really knows about how much Apple makes on the App or Music store, I ask them if they ever read the quarterly earnings or attend the financial conference calls. They never do but they still insist that Apple must be making gads of profit even though they've never looked at the public data that Apple provides and tried to figure it out for them selves.

For instance for the fiscal year 2010, Apple reported $4.9B in revenue for the iTunes store. At most Apple took $1.5B in revenue for themselves after the artist/holder cut. Between January 2010 and February 2011, Apple sold over 4 billion songs. For arguments sake they only sold 3 billion for the fiscal year. That's 8.3 million songs a day. While not every song is a transaction, that's a lot of transactions. And that's just counting the music. There were probably thousands of movies a day. So for $1.5B a year, Apple had to pay for all the bandwidth, servers, credit card fees, etc and serve up 8 million songs a day and tens of thousands of movies. I would argue that Apple probably makes some profit but it isn't a lot.

Easily fixed! (-1, Flamebait)

davevr (29843) | more than 3 years ago | (#35538588)

In the next patch, they will just slow down all competing web browsers!

Seems like a legitimate complaint (0)

Anonymous Coward | more than 3 years ago | (#35538614)

I know we're supposed to be Apple haters but it seems like a legitimate argument. Why not test the iPhone browser on an actual iPhone? Lots of software perform differently in different environments.

This is a joke. (1)

geekmux (1040042) | more than 3 years ago | (#35538628)

I find it laughable that companies are actually arguing over the browser performance on a device with a screen less than 4" in size. What's next, are we going to start testing surround-sound on cell phones too? Hell of a 1/4" subwoofer you got there...

I guess I'm just the only guy who still uses one of those "old-fashioned" desktop monitors or an HDTV to drive my web experience. Apparently double-digit monitors are overrated.

Re:This is a joke. (1)

Midnight Thunder (17205) | more than 3 years ago | (#35538802)

To some this is just a pissing contest, while others see it as the world changing domination by which their manly hood is challenged. For post people if the user experience meets or beats their expectations, then that is all that matters. I am with you that it really doesn't matter - well unless mine is the winner ;)

Re:This is a joke. (0)

Anonymous Coward | more than 3 years ago | (#35538952)

Something tells me you haven't heard of the HTC Surround [htc.com] . Reminds me of when kids had speakers built into their backpacks...

Re:This is a joke. (0)

Anonymous Coward | more than 3 years ago | (#35539318)

I find it laughable that companies are actually arguing over the browser performance on a device with a screen less than 4" in size. What's next, are we going to start testing surround-sound on cell phones too? Hell of a 1/4" subwoofer you got there...

I guess I'm just the only guy who still uses one of those "old-fashioned" desktop monitors or an HDTV to drive my web experience. Apparently double-digit monitors are overrated.

I dunno, if anything, performance in this space is most important to me. If I want to look something up on my phone, I'm generally on the go and probably want to get it done in a hurry. I know I use my iPhone browser a hell of a lot more than I used my blackberry storm browser. It was sluggish. Didn't use it. Now I find it more than acceptable on my new phone (not a knock on BB, I hear the BB OS 6 browser performs well)

How do webapps even get on iphones these days? (1)

Joe Tie. (567096) | more than 3 years ago | (#35538634)

I haven't used an iphone for a while, so could someone bring me up to speed. If one goes to a webapp in safari that makes use of all the html5 goodies, he can just add it to the homescreen, right? Can it then launch like an application, not having the usual safari behavior of sliding around as a normal page amid other open webpages? Or does a developer essentially have to create a native app, an instance of webkit, and then wrap the html5/javascript within it to get an app written with html5/js onto the phone if he wants it to actually seem like an app instead of a webpage? Because if JIT is disabled in native apps using webkit, I can at least understand that. It's the app store, it's a big brother environment, that's common knowledge from the start. But if they're actually putting effort into slowing down performance of javascript within the context of normal OS functionality, that's something a lot more annoying.

Re:How do webapps even get on iphones these days? (1)

bongey (974911) | more than 3 years ago | (#35538682)

It can be saved to the home page, as this link shows the "Pie Guy" web app doesn't work anymore in 4.3 and full screen web apps don't get to use the new Nitro Engine.

safari true condenender? (1)

laktech (998064) | more than 3 years ago | (#35538644)

"They didn't actually test the Safari browser on the iPhone," Kerris argues. And, We hope Apple will help us enable those [browser] optimisations and repeat the measurement. Until then, for all we know the missing optimisations may not make a big impact." So, yeah, fix your shit and stop crying.

Who the hell uses web apps? (1)

RyuuzakiTetsuya (195424) | more than 3 years ago | (#35538680)

I'm just not convinced that there's a conspiracy here. I'm pretty sure Apple has the same view I'd have. I don't think that many people are using web apps in the first place and I'm not sure if there are any native apps that could use the performance boost that Nitro in this iteration of iOS, so once Safari was set up to use the new JS engine, they shipped it.

Re:Who the hell uses web apps? (1)

dave024 (1204956) | more than 3 years ago | (#35538864)

I still don't know what a web app is, and I use two iPhones and an iPad daily. I can't even come up with a decent site that explains it. Is it just a link on the home screen to a web page? I never knew so many people used them until these recent articles.

Re:Who the hell uses web apps? (0)

Anonymous Coward | more than 3 years ago | (#35538986)

Web apps are like AI. Once something qualifies as a web app or AI, it's thereafter called a website or non-AI.

Re:Who the hell uses web apps? (1)

bigNuns (18804) | more than 3 years ago | (#35539094)

I used to use the YouTube one... I no longer have an iPhone... but the YouTube web app was actually better than the built in YouTube app in my opinion. Also, as far as I know, WebApps aren't the only use of the embeded WebUI thingy... you use that in actual apps the get browser functionality. If you haven't noticed HTML in any of your apps you aren't looking very hard.

What's the issue here? (0)

Anonymous Coward | more than 3 years ago | (#35538906)

I don't see what the problem is...

after all when you buy apple kit you demonstrate to the world that you don't have the foggiest idea about computers and what makes them so great - you know, stuff like performance, freedom to tinker etc.

And for supporting a company that is evil (by just about any definition) you get done right up the pooper. It's a well-deserved but rather thorough and rigorous violation. What's the problem here?

FIRST POST!!!!! (1)

flyingsquid (813711) | more than 3 years ago | (#35538936)

Wait... oh. $#!*. Never mind.

Stupid iPhone...

Sour grapes from Blaze.io (4, Informative)

Bogtha (906264) | more than 3 years ago | (#35538938)

This, claims testing firm Blaze.io, is news to the world.

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 [slashdot.org] .

If you really want to know more, read this... (4, Informative)

DavidinAla (639952) | more than 3 years ago | (#35538974)

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 [daringfireball.net]

Re:If you really want to know more, read this... (1)

mSparks43 (757109) | more than 3 years ago | (#35539420)

I don't think anyone ever considered Apple charging a lot of money for a substandard piece of kit a "conspiracy theory". Branding is a well established and apparently acceptable method to con people.
Personally I use a large advertising budget as a sign no-one would recommend it to a friend. Which I find an infinitely more useful purchasing tool.

So Sloppy Programming... (0)

Anonymous Coward | more than 3 years ago | (#35539742)

With Android taking the lead, I'm surprised that this "half-ass"ing by Apple gets any approval from their consumer base... but then again, they're consumer base is (to put it nicely) unique...

To get to the point quickly (I do not own an iPhone, so...) Web Apps are basic bookmarks that you placed in launcher form on the Home Screen area. They happen to use UIWebView system instead of Mobile Safari. But they are nothing more than glorified web pages that you can "bookmark" to your Home Screen.

So, if I may ask, Why didn't Apple have those Launchers launch Safari and navigate to said webpage? Maybe have Safari's UI change so users can't see the URL bar or what not. Although it might be comparing Apples to Oranges in speed tests, WHY didn't Apple just go about it the right way instead of that really nasty way that leaves them with egg on their face? I mean seriously, they could of coded it better, and backport it to the rest since I'm sure they've had this feature for a long while.

Is it Chrome on Android? (1)

MichaelSmith (789609) | more than 3 years ago | (#35539782)

This little script [glitch.tl] says that the user agent on my LG Optimus phone is Safari.

Apple admitting it? (1)

brillow (917507) | more than 3 years ago | (#35539806)

Are they admitting that javascript performance is not "enhanced" universally in iOS? Makes the issue about full-screen webapp performance seem pretty legit doesn't it?

ffs (0)

Anonymous Coward | more than 3 years ago | (#35540604)

can people stop jizzing themselves and spreading apple's shit everytime they release any little crumb of information
this shit was already covered in the goddam original submission of:

http://mobile.slashdot.org/story/11/03/17/1810253/Nexus-S-Beats-iPhone-4-In-Real-World-Web-Browsing-Tests

which linked to the bloomberg article:

http://www.bloomberg.com/news/2011-03-17/apple-iphone-loses-web-speed-test-to-google-s-android-blaze-software-says.html

which in the second section of the damn article says:

Seconds to Load

Apple regards the tests as flawed because the browser that customers access by tapping on the Safari icon on their iPhones has performance enhancements not available when users access the Web through applications, said Natalie Kerris, a spokeswoman for the Cupertino, California-based company.

What were those guys thinking? (2)

satuon (1822492) | more than 3 years ago | (#35540652)

I don't understand why they decided to compare the embedded browsers. "Ya, we'll go and compare Android and iPhone browser. But we won't compare the real browser, cause that would be too boring. Instead we'll compare the embedded browser, so if our assumption that it's the same turns out to be wrong, we'll become a laughing stock."

Seriously if I were doing this test, it would have never even occured to me NOT to use the real browsers in the first place.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?