Apple Disputes Browser Speed Findings, Says Mobile Safari's the True Contender 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.'"
Chrome (Score:3, Funny)
1st post, so Chrome must be fastest...
Re: (Score:2, Insightful)
Re: (Score:2)
My last troll put paid to his "fat bitch troll". Look it up, there's pics and everything. But hey, he doesn't need to, I'm pretty damn sure he was there - the comment is almost verbatim!
Oh hell. (Score:3)
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! (Score:4, Insightful)
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)
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.
Comment removed (Score:5, Interesting)
Re: (Score:2)
If you're asking how it's technically restricted, the next-generation features of the "Nitro" JavaScriptCore engine are not in the UIWebView libraries. That's how it's not available.
To the great-grandparent-post's broader point about security distinctions, it's hard to imagine that an app implementing UIWebView is more of a security risk than an app specifically geared toward visiting sites which execute arbitrary code with JSC. If JSC is vulnerable to malice or ignorance, then Safari is much more vulnerabl
Re: (Score:1)
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: (Score:3, Insightful)
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
Re: (Score:2)
In iOS, apps are sandboxed by the kernel. Look up "seatbelt."
The kernel is fed a permissions document which dictates what the app is allowed to do.
Basically, MobileSafari gets special privileges which other apps arn't given.
Attempts to use the Nitro engine result in success in MobileSafari.
Attempts to use the Nitro engine in other iOS apps is likely to just fail or get auto-killed by the kernel. (not sure which one)
Re: (Score:2)
That's one protection, but there are others.
Like on Linux, you have root, and users run apps
Re: (Score:2)
Something I'm curious about is the extent of the difference between the privileges given to MobileSafari compared to the normal iOS 3rd party apps. We know they're different, but by how much?
I have a feeling that jailbreakme.com might not have worked from a UIWebView in a 3rd party app. But nobody ever bothered to try it since it's easier to use MobileSafari.
Re:Not Reasons Unknown! (Score:4, Informative)
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: (Score:1)
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: (Score:3)
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
That's not the problem. (Score:5, Informative)
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: (Score:2)
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.
Re: (Score:2)
It's not; a webbrowser is a pretty damn big attack surface. But Safari + other apps is a larger attack surface than Safari alone.
Re: (Score:2)
Re: (Score:2)
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.
Wrong (Score:2)
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: (Score:2)
The usual usage scenario will use a web view to load local html. A Twitter client would open links in a browser. Even putting that all aside though, the worst case scenario is still that the app is equally vulnerable to Safari.
Re:Not Reasons Unknown! (Score:5, Informative)
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! (Score:4, Insightful)
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: (Score:2)
Steady on, rationality and reason only 4 posts in. Must be a record!
Re: (Score:1)
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?
Re: (Score:2)
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 platf
Re: (Score:1)
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! (Score:5, Insightful)
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: (Score:2)
I don't think Apple is trying to cripple web performance.
Re:Oh hell. (Score:5, Insightful)
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)
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: (Score:2)
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: (Score:2)
> 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
Re: (Score:2)
Re:Oh hell. (Score:5, Funny)
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: (Score:2)
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)
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)
Re: (Score:1)
Universal benchmark (Score:2, Funny)
Farmville, right?
Re: (Score:1)
:) Exactly...
Safari is fast, it's UIWebView has no Nitro. (Score:1, Interesting)
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
Re:Safari is fast, it's UIWebView has no Nitro. (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
How about accelerated H264 then? It took Apple a couple of years to release that in an SDK.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
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: (Score:1)
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.
Re: (Score:2)
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
What do people want (Score:5, Insightful)
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 (Score:5, Informative)
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)
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 (Score:4, Informative)
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: (Score:2)
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 (Score:4, Informative)
Re: (Score:3, Insightful)
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
Re: (Score:2)
"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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
This is a joke. (Score:2)
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: (Score:2)
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: (Score:1)
Re: (Score:2)
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
How do webapps even get on iphones these days? (Score:2)
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
Re: (Score:1)
safari true condenender? (Score:1)
Who the hell uses web apps? (Score:2)
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: (Score:1)
Re: (Score:1)
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.
Re: (Score:2)
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.
FIRST POST!!!!! (Score:2)
Stupid iPhone...
Sour grapes from Blaze.io (Score:5, Informative)
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... (Score:5, Informative)
Re: (Score:1)
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)
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
Is it Chrome on Android? (Score:2)
This little script [glitch.tl] says that the user agent on my LG Optimus phone is Safari.
Apple admitting it? (Score:1)
What were those guys thinking? (Score:2)
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.
Sensationalism and sloppy from the start (Score:2)
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 (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
Browser speed matters because browsers can and will do a lot more than they have done in the past. Browsers have been "fast enough" primarily because developers only push functionality to the limits of browser performance.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re:Mobile Safari's caching and asynchronous loadin (Score:4, Informative)
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]
Re: (Score:2)
Pathetic Mike, is copy pasting the same trolls and changing the name.
2 out of 10, need to do better!
Re: (Score:1)