Apple: Yes, Safari outperforms embedded iOS web viewer Apple has confirmed that the web viewer embedded with iOS 4.3 does not offer certain optimizations included with the Safari browser bundled with Apple's mobile operating system. "The embedded web viewer does not take advantage of Safari's web performance optimizations." Apple spokeswoman Trudy Muller tells The Register. It …
No, it\s obvious why; Apple are being conservative, they didn't want to unleash a new version of the optimisations on app unsuspecting app developers without letting them test their applications worked as planned (not least because when an app suddenly stops working people are pretty miffed and blame the OS update - reasonably so). But Apple wanted to get these optimisations in play for Safari as soon as possible (especially with faster dual core Android devices arriving now).
So, Safari has all the optimisations, and runs a slight risk that some stuff won't work as planned (but this is the web - we're all used to this) where applications don't get the speed ups, but will still work (many users won't understand the distinction when it comes to these web apps - so would be really annoyed if they stopped working).
I'm sure Apple will urge developers to test against their new technology and up date as needed, then we'll see these optimisations across the board.
Isn't that obvious?
I have an existing web application that worked fine under the previous iOS 4.2 running on either Safari or the embedded browsers offered by some other app.
However, after I updated by iPAD to iOS 4.3, the web application now CRASHES when running in Safari. So I had to use other apps to "download" my web application and then run it using its embedded browser. Then it will work.
Now, until Apple fixes the problems with NITRO, perhaps they can provide a "switch" to turn off the optimization on the Safari browser so that I can still use my existing working web apps.
...why Apple included a redundant framework for browsing in iOS. That's effectively what this is; instead of Safari without the controls, you get Safari minus minus without the latest gadgets and gear. This means that said web apps are going to have different user experiences from the optimizations and tweaks made in the latest version of Safari, and it's now apparent this is completely true, because they've admitted the underlying engines are different.
This isn't just about native apps either - this is about web apps, which are basically just bookmarks on the home screen. Apple has no financial interest in helping out these apps, so the idea it would hold back optimizations to discourage their use, as conspiratorial as it is, is quite in tune with their past form. I'm not saying that this is the case, only offering an opposing viewpoint. From my technical perspective at least, it's an unusual policy to maintain two different libraries or applications in the same OS for the same purpose.
"Apple has no financial interest in helping out these [Web] apps..."
How many Web apps require users to pay for them? Answer: very few. Therefore, if the developers turned those Web apps into native iOS Apps, they would almost certainly be sold for free. And Apple loses money on free Apps.
Ergo, it would appear to be in Apple's best interests to make Web apps as good as possible.
Now, I agree that it is odd that there are now two HTML(etc) rendering back-ends, but I suspect that it was easier to plumb in Nitro et al to Safari, than the more general UIWebView part of iOS (since that probably has to deal with varying app permissions, etc). If there is still a discrepancy come iOS 5.0, then we can start to complain.
Yeah. All that's happened is web apps didn't get the speed up - they use the same "tried and true" implementation.
There is work underway within the WebKit project that will mitigate this (providing security for web apps outside of Safari Mobile) and it gives developers more time to assure their web apps run as intended.
"This isn't just about native apps either - this is about web apps, which are basically just bookmarks on the home screen."
Actually it is about native apps. Native apps and full screen web apps both use the UIWebView "widget". UIWebView is coded in to many, if not the majority, of approved apps at one place or another. These apps frequently invoke JavaScript functions within the UIWebView control. What you are sugesting is that Apple should foist the Nitro engine changes on approved apps. Of course it should be ok and everything should work, but should isn't good enough. Developers have to have time to test all still works OK. As I wrote in a post against the earlier Register article, I am developing an app on iPhone against Google docs. Google have several times now changed the implementation of GoogleDocs in small subtle ways without warning (ways that you would think should make no difference). But they have broken my app on a number of occasions. The last time was because they changed the way .DOCX uploaded files are parsed. One day the DOCX files i was generating and uploading working fine, the next, with the same app version, they weren't. If my app were live my customers would be rightly annoyed. Apple, in my experience, are more professional in how they deal with change management.
There is as yet no evidence of conspiracy.
No, these run is separate processes, that's why they appear distinct from Safari in the multitasking UI. Users see these as 'Apps', and rightly so, this is exactly what they are.
This situation is not permanent.
One should also remember these haven't become "slower", they run as fast as they ever did. All that's happened is Safari Mobile has been speeded up...
Come on, people - UIWebView, as Gruber points out in his comprehensive disembowelment of this entire reach-for-a-story, is also used by apps sold within the app store. Only Safari in iOS has gotten any faster. Nothing has actually gotten slower, except in comparison. Please read: http://daringfireball.net/2011/03/nitro_ios_43
But I think the main point still stands, that if Safari is being made faster than UIWebView, yet UIWebView is used by apps from within the app store as well as web apps, then this can hardly be called an attempt by Apple to force the app store down developers' throats.
Although having removed that possible motive, it's difficult to tell why Apple are approaching it this way at all.
@SuccessCase, I don't know if I buy it. People have had apps break from one iOS to the next and had to come up with fixes for it. I don't think they would turn away a nice speedup that is supposed to not change behavior at all over this.
@thickasthieves, that's the question. Some think it's a conspiracy of Apple apparently. SuccessCase and some think it's intentional but that it's to be a benefit. I figure two possibilities 1) During development the UIWebView got a seperate branch of at least Javascript code (and possibly the entire HTML renderer) from Safari, and they weren't synced recently enough. Or 2) They tried to sync, or maybe even have UIWebView use the Safari libraries, it blew up on them and they couldn't get it to work for a timely iOS release so they used older but working code.
For those who think it's intentional, I must make one comment -- it's in Apple's best interest to make things as low power as possible. If the goal was just to slow down apps on the desktop, they should use the newer, more efficient code and throttle CPU usage. This would save battery life.
@Henry Wertz 1: Thanks for your comment. Is it fair to say that most end-users have no idea that 2 browsers exist on their phone, and also have no idea how to go about using a specific browser?
Is this also true of a developer, or do they know which one their code will be running in? Can they choose which browser to use?
I don't have an iOS device. By default, do Apple apps use one browser, and apps from the web store or from the internet use the other browser?
Thanks for any answers and for cleaing up the mystery.
The reason for this is purely commercial and it comes back to the subscription rake off plans apple introduced a few weeks ago.
Full performace of web apps would negate the requrement to offer an App from the Itunes store with the in app purchase and forced price fixing.
So anyone with subscriber content doesnt need to offer any form of Itunes purchase or sub rake off.
So if your a newspaper, magazine etc or any other sub or payment service you can web app instead and avoid the iTax.
I will of course get flamed by the fanboi for pointing this out but it follows all the other steps apple have taken including the price fixing of in app and out of app purchasing.
Apple have already seen subscriber based content providers moving to web apps since the announcement so its no surprise really.
So, The Register can make a conspiracy out of the fact that Apple made their browser faster?
The fact the improvements haven't been extended to UIWebViews and full screen web apps is nothing more than a security issue, which will probably be overcome sooner or later:
http://daringfireball.net/2011/03/nitro_ios_43
Matthew, Matthew, Matthew. The possibilities and applications for of HTML 5 have sailed right over you head haven't they?
This is about HTML5 APPLICATIONS - not static websites - lots of client side rich UI, local caching of data, local databases, etc, etc. Performance is quite important here, you see. It means you can do stuff like offline rich document editing, spreadsheets, databases, games.
Maybe "tech nerds" are the only ones who care about how the performance is delivered, but end users will appreciate the functionality that it brings with it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
