Forgot your password?
typodupeerror
Android Iphone Open Source Safari Apple News

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

Posted by timothy
from the you-say-one's-better-I-say-one's-worse dept.
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.'"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Chrome (Score:3, Funny)

    by webmistressrachel (903577) on Friday March 18, 2011 @07:36PM (#35538368) Journal

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

  • by revscat (35618) on Friday March 18, 2011 @07:40PM (#35538396) Journal

    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.

    • by VirginMary (123020) on Friday March 18, 2011 @07:45PM (#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: (Score:2, Insightful)

        by Anonymous Coward

        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.

        • by MoonBuggy (611105) on Friday March 18, 2011 @07:56PM (#35538498) Journal

          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.

        • by Anonymous Coward

          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.

      • 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 UIWebVi

        • by pavon (30274) on Friday March 18, 2011 @08:28PM (#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.

          • by omfgnosis (963606)

            How on Earth is a web browser—designed to access anything and everything on the web—a lower attack surface than apps with a WebKit view? At the very worst, in the case of apps which are also web browsers, the attack surface is equal.

            • by pavon (30274)

              It's not; a webbrowser is a pretty damn big attack surface. But Safari + other apps is a larger attack surface than Safari alone.

          • by tepples (727027)
            Then why can't UIWebView be set up to run in a separate process under the control of a "crappy app", in much the same way that Chrome runs?
            • by pavon (30274)

              That would be a good architecture, provided the carefully audited the interface between UIWebView and the other applications. Who knows if Apple will ever bother to rearchitect it in that manner.

        • by SiMac (409541) on Friday March 18, 2011 @08:32PM (#35538776) Homepage

          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.

          • by tlhIngan (30335) <.slashdot. .at. .worf.net.> on Saturday March 19, 2011 @12:46AM (#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.

      • by sgbett (739519)

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

      • by iserlohn (49556)

        But Safari is exposed to the wider internet, while UIWebView is only exposed to the site that the app dev has coded in. With Apple's leash on the app store, wouldn't it be more safe to enable Nitro on UIWebView compared to Safari on i(phone)OS?

    • 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 i
      • Re:Oh hell. (Score:5, Insightful)

        by Drakino (10965) <d_slashdot@min i i n f o.net> on Friday March 18, 2011 @08:30PM (#35538750) Journal

        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. (Score:5, Informative)

          by MBCook (132727) <foobarsoft@foobarsoft.com> on Friday March 18, 2011 @08:49PM (#35538904) Homepage

          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).

          • 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?

            • > 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?

              Presumably applications embedding the browser have access to Obj-C interfaces that aren't exposed to the web.

              This means that the browser and JS engine have to run in the same process space as your non-safari program.

              Which means that your non-safari program is one buffer overflow away from executing arbitrary machine code stored in data segments, bec

              • by MBCook (132727)
                Right. It's a little odd for web apps saved to springboard (where you just save the link from Mobile Safari, so there is no 3rd party code involved), but it makes sense for a game or other app that may use a UIWebView to display news or such. It probably doesn't need the extra performance, but it would be a big security risk.
    • Re:Oh hell. (Score:5, Funny)

      by alostpacket (1972110) on Friday March 18, 2011 @09:23PM (#35539100) Homepage

      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.

    • by Tharsman (1364603)

      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.

  • Real reason (Score:4, Informative)

    by Anonymous Coward on Friday March 18, 2011 @07:44PM (#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: (Score:3, Interesting)

      by bongey (974911)
      4.3 has address space randomization , which is why the pwn2own exploit doesn't work any more.
      • by bongey (974911)
        Charlie Miller comments who has won the pwn2own contest portion for the iPhone for that last few years. “The first one [in 2007] was really, really easy. They had nothing, no sandboxing. Everything was running as root. It was super easy. The SMS one [in 2009] was harder because of DEP but there were no sandbox issues because the process that controlled SMSes wasn’t in a sandbox.” “As of 4.3, because of the new ASLR, it will be much harder,” Miller added.
  • Farmville, right?

  • 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 o

    • by larry bagina (561269) on Friday March 18, 2011 @08:08PM (#35538584) Journal
      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.
      • by brillow (917507)
        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?
        • 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.
        • by omfgnosis (963606)

          Safari was faster than Firefox because Firefox was a dog in desperate need of serious updating, and because Safari's release schedule is somewhat more aggressive than Firefox's. There was never any "secret APIs" that Safari could access and Firefox couldn't. The "secret APIs" haven't been opened up, but Firefox is closing the performance gap. How does that fit into this little conspiracy theory?

      • "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.
      • Your friend needs to setup a torrent of that... lol
      • by tepples (727027)

        if "slow" means "the same speed as they were two weeks ago when we weren't complaining about how slow they are"

        I have a hundred U.S. dollars. I wait 20 years. I now have less real money than before because of inflation. Computing has inflation too: look at how hashcash implementations deal with Moore's law.

    • 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.

      • by Anonymous Coward

        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.

        • Natural home birthing is twice as likely to kill the mother or the child as birthing at a hospital.

          Here's the rub with that statistic, the number is insanely low to begin with, meaning that the reality is that home birthing with a midwife really isn't all that dangerous(it's still all natural woo woo, but that's not the point).

          Sure, UIWebView is 50% slower than Android in this test, but, the real measurable difference isn't say the difference between IE6 and Chromium's daily build in Sunspider. The differe

  • by fermion (181285) on Friday March 18, 2011 @07:51PM (#35538472) Homepage Journal
    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.

    • by farnsworth (558449) on Friday March 18, 2011 @08:58PM (#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: (Score:2, Interesting)

        by bigNuns (18804)

        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.

        • by farnsworth (558449) on Friday March 18, 2011 @09:33PM (#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]

          • by bigNuns (18804)

            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.

            • by farnsworth (558449) on Friday March 18, 2011 @10:02PM (#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: (Score:3, Insightful)

                by UnknowingFool (672806)

                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

                • by LodCrappo (705968)

                  "I would argue that Apple probably makes some profit but it isn't a lot."

                  man.. i was totally with you right until this part. why would you argue that? its 5 BILLION dollars in revenue. Bandwidth and servers, in quantity, are very inexpensive.

                  • Revenue != profit. Dell made $53 billion in revenue last year but they lost $1.4 billion overall. Would you argue: "But they made $53 billion in revenue! They must be swimming in money!"

                    It appears that you didn't really read carefully anything I wrote above that sentence. The iTunes store revenue was $4.9 B. That's gross revenue and before they pay out any costs. Right off the top, $3.4B goes to the copyright holders. That's money they can't figure into any profit calculation. At most Apple keeps

                    • by LodCrappo (705968)

                      It's easy to imagine things being very expensive when we start using millions and millions of something, hard for the brain to conceptualize it so we just assume it must be alot and don't usually go much further. But just for fun lets do a little guessing and some math...

                      8 million songs per day = ~92 songs per second, lets call it 100

                      100 songs, lets say 10MB per song (google says average size is much less, but why push it).. 1000 MB per second.. so we need a roughly 8000 Mbps connection (for now, lets assu

                    • Do you even read what I type? I said clearly above:

                      "That's more than just bandwidth and servers; that's the entire system including backend-end payment processing and data centers."

                      And the first thing you start doing is calculating bandwidth costs.

                      My question to you which you have not answered is this: What will it cost you to build/maintain a system that is capable of selling and serving up 8 million songs a day? Remember the system probably should compose of multiple data centers for redundancy and performance. It has to handle multiple languages and currencies on the payment end. BTW every credit card transaction is at least 3

                    • You are aware that most major companies, manage to record a loss, right? This is so they don't have to pay taxes.

                      So you're saying that companies break the law and lie about how much they didn't make? And Apple reported a profit. So they lied less? Sure . . .

                      And BTW, Yes, I could serve eight million songs a day for less than 1.5 BILLION a year. Your cost figures are off by an order of magnitude.

                      Please you don't have the slightest idea of the infrastructure that's required. The only companies that might are Amazon and MS in that they sell music as well. MS, though, probably doesn't sell nearly as much as Amazon or Apple. In Amazon's financials, they don't specifiy how much profit they make on their music store. Nor do we know how much they sell or

                    • by LodCrappo (705968)

                      My point is that when we use big numbers like millions and billions, it's difficult to have a sense of what a reasonable range for any calculation will be.
                      I calculated bandwidth costs (poorly) merely as an example of this and because it's the only metric where we have any data (the number of songs to be delivered) and I personally have any idea at all of costs involved. When someone says they are selling that huge number of songs, my first reaction is to think "shit, the bandwidth to deliver 8 million song

                    • The only metric you provided is bandwidth but my point is that bandwidth is not the majority of the costs. In my opinion, the construction of the data center and its operation is probably the biggest cost. The fact that Apple has been building them recently and they cost in the billions to build is probably a better indicator that Apple doesn't make a lot of profit in the end. Apple probably makes some profit, but they're not swimming in money because of iTunes store sales. Also due to the ever expand
                    • by zmollusc (763634)

                      Well, you have to store songs, perform transactions and serve songs.
                      The bandwidth to do the serving appears less than $1.2 million, let's look at the storage.
                      Wiki says iTunes store has: More than 14 million songs worldwide, 1,000,000+ podcasts (USA), 40,000+ music videos (USA), 3,000+ TV shows (USA), 20,000+ audiobooks (USA)2,500+ movies (USA), 300,000+ App Store Apps.

                      Say 10Mb for a song, 80Mb for a podcast, 80Mb for a music video, 400Mb for a tv show, 200Mb for an audiobook, 1G

                    • I make that about 250 Tb, so a minimum of $12,500 on disks. Let's put those disks in some server hardware, allowing $1000 of ancillary kit per disk. We are now at $270,000 or so, so let's have some redundancy here. 100 mirrors should do, bringing the total to $27,000,000 . I will let someone else work out the electricity costs.

                      I suppose the building to house all that equipment costs nothing? What about the A/C? The thing is building a data center isn't cheap. Google is probably the company with the most experience doing it. However their purpose is massively parallel processing not transaction and downloads. Even then they spend hundreds of millions on each data center. They must be foolishly wasting their money according to you.

  • 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.

    • 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 ;)

    • by znerk (1162519)

      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 find it laughable that you don't have enough imagination to figure out why the "tiny screen" on the phone may or may not have anything to do with why people want a faster browser.

      I have a Motorola Atrix. I used to have an EVO. The Atrix has a dual-core 1Ghz processor, 1GB of RAM, 16GB of onboard storage, and the SD slot allows for another 32GB. This "phone" beats the pants off the machine I was using a few years ago to play GTA3 and Neverwinter Nights... and it fits in my pocket.

      Both phones have the abili

  • 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 pho

    • by bongey (974911)
      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.
  • "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.
  • 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.

    • by dave024 (1204956)
      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.
    • by bigNuns (18804)

      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.

      • I could name a few iOS apps that use the HTML/JS rendering API available to native Apps, for example, ANY twitter client will open links in a browser. My bank's banking app is just a thin wrapper around their mobile page.

        I'm just not sure the previous generation of JS engines were all that slow, and while JS performance boosts are always welcome, I'm not sure if any app right now *needs* it.

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

    Stupid iPhone...

  • by Bogtha (906264) on Friday March 18, 2011 @08:54PM (#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].

  • by DavidinAla (639952) on Friday March 18, 2011 @09:01PM (#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]
    • by mSparks43 (757109)

      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.

    • Re: (Score:3, Insightful)

      While Gruber may be right on this he is still the dick who concocted the widely quoted fantasy as to why cross compilers were definitely bad for iOs consumers and Jobs was so right to ban them give that Apple only do things that are good for the consumer blah, blah fucking blah.

      He was suspiciously silent when Apple un-banned cross compiled apps. Which is a shame. I was desperate to know why cross compilers were suddenly good for consumers in a way that didn't reference the EU investigation on the issue

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

  • 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?
  • 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.

  • If you look at Blaze blog entry, you'll find this gem:

    On average, Android 2.3 was a 52% faster than iPhone 4.3, with a median load time of 2.144 seconds vs. iPhone’s median load time of 3.254 seconds.

    If it were relevant (which is not the case as it's supposed to compare web browsers), then the iPhone would be 52% slower than Android. Which is equivalent to say that Android would be ~34% faster then the iPhone, not 52% faster (for this, Android would need to complete in less than half the time of the iPhone). I guess that it's not politically correct to use the negative version (iPhone is slower), but then it's hard to resist using the higher number

  • If you believe this, then Steve has a bridge to sell you. Actually, rumor has it that the bridge will come free with your iDevice 5.0.

Algol-60 surely must be regarded as the most important programming language yet developed. -- T. Cheatham

Working...