• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

iPhone vs. Android

Not necessarily. The tests should be considered inconclusive because the testing methods are flawed.

Android Loading Websites Faster Than iPhone Report Debunked - SlashGear

Android beats iPhone on browser speed--or not | Deep Tech - CNET News

My understanding is that the testing method did not exactly simulate the use of the Safari browser on the iPhone. It seems that Apple may optimise Safari a bit more than the method apps on the iPhone use to browse. The tests did not test Safari directly and thus does not properly measure the speed of Safari.

I don't think that the testers deliberately did it this way to make the iPhone look worse. I think that this seemed like a good way to test the browser with what ever app or method they use to measure speed and it turns out to be different than using Safari directly.

I would call this a no decision.
 
If iphone won, nobody would say the test was flawed. :/
Remember that webview was used for android as well. It's not as if android was treated differently.
 
I almost think the point is moot myself. I've seen tons and tons of comparisons between the iPhone and various Android phones in real world load situations, and to me it doesn't seem like either of them blows the other one out of the water by any means. If anything Android may load a page a split second faster than the iPhone one time. The next time the iPhone may load a page a split second faster than the Android device it was up against.

But at any rate, even if it had always been the iPhone a split second faster than the Android device, it still wouldn't have lured me to go get an iPhone, because it just wasn't that big of a difference. They both load pages very quickly. I'm sure they will just keep getting quicker and quicker, but even if they stayed right where they are right now... I'd be completely satisfied with it.

It's just not that big a deal IMO.
 
I use firefox on my PC and it's not the fastest thing in the world but I just can't tolerate browsing with other browsers because they don't have the extensions that I use.

It's like watching a TV show in someone's house and they don't have a DVR. I may need to play around with several remotes just to turn on my TV but I can't stand a TV without a DVR
 
Outlaw71 said:
I almost think the point is moot myself. I've seen tons and tons of comparisons between the iPhone and various Android phones in real world load situations, and to me it doesn't seem like either of them blows the other one out of the water by any means.
Click to expand...

Right on.

The Android web browser and the iPhone web browsers are BOTH based on WebKit code (read: same as Safari) - in other words - the sources are kissing cousins.

When I set my user agent string to "Desktop" in the stock browser, sites I visit log me as a Mac using Safari. (Hmmm - wonder how many reported Macs running Safari in use are really Androids running the stock browser set to give the full web experience?)

For that reason, there are a ton of so-called shoot-out YouTubes where the iPhone wins on one page, an Android on the next, for load times. The differences are more a case of which device is optimized to render which web content.

As far as my personal needs go, the Android browser experience isn't about load time - it's about load completeness - I visit Flash sites.

ari-free said:
If iphone won, nobody would say the test was flawed. :/
Remember that webview was used for android as well. It's not as if android was treated differently.
Click to expand...

Given that both stock browsers are based on WebKit and that users use stock browsers, there was no need to replace either to assess load times fairly. A stock browser comparison would not have been comparing apples to oranges, iow. (Ok, sorry, couldn't resist the pun to hammer the point.)

Seems like Blaze has an agenda and it's not to just test load times.
 
From TFA you linked:

Embedded browsers are software components available to mobile apps to invoke the browser, and are the only ways both platforms allow users to interact with a browser. It’s important to emphasize – we used each platform’s embedded browser, not our own browser.
Click to expand...

I have no clue what they're talking about.

I use HTC's News app for my RSS feeds. At the bottom of every blurb is a button to read more - I click that, I get the stock, multi-page native browser. I often copy a url from a page I got to that way, switch to an active AF forum window, and share the link.

Full browser access directly from the app - flatly contradicting that quote, especially the bolded part.

Maybe other's mileage varies, I don't know.

In any case, they've uncovered some deficiency that does not indicate load times on the native browsers, as any who have used both devices or have seen the side-by-side vids can attest.

So - I dunno.
 
Embedded browser means the Webkit libraries used by the native browser can be used with other apps to create browsers inside apps. These libraries are also used by third parties to create third party browsers.

For example, Dolphin and Skyfire browsers on Android all use the Webkit libraries. Or shall we say, the same Webkit engine. Compared to the native browser, there is no practical difference when it comes to the benchmarks. The true "foreign" browsers on Android are like Opera Mini, Opera Mobile and Firefox Mobile. These got their own engines and don't use WebKit.

Examples of embedded browsers are for example, among iOS Twitter apps, plus some Android Twitter apps as well. When you click on a link, it opens to a browser within the app itself, and not a separate browser outside of the app. iOS apps often use embedded browsers because they got no quick way to return from the browser to the Twitter timeline unlike Android apps, where a simple <= button returns you from the open browser to the original Twitter app that spawned the browser process.

It really doesn't matter if its Safari or the embedded browser because you're still testing the core Webkit engine and the other differences are nothing more than differences of mascara. In fact, in Android, you won't see any real differences in speed between the third party Webkit browsers and the native browser, and it is only with truly independent non Webkit using browsers (Opera or Firefox) that you can see the real differences in speed.

In any case, we still do know that for example, in Javascript, Android 2.2 or 2.3 is still faster than iOS 4.1 or 4.2.

Samsung Exynos vs OMAP 4 vs Nvidia Tegra 2: Benchmarked
 
I am having a problem with this.....
If someone said to me they created an application that displayed a webpage, using lets say.. the IE COM control... I would expect it to behave the same as viewing the webpage in IE - and for me it does with the exception that my created-in-30-seconds web viewer.. was created in 30 seconds and loaded a static page.

I would expect similar behavior from the Android platform or the iPhone OS.

What boggles my mind is why Apple would make a move akin to farting in church by actually altering the way the embedded browser performed?

Or is it because of what I read in the press the other day.. that Apple made the embedded browser intentionally slow to hinder apps that used it...
That being the case.. yeah the test is flawed because Apple made it flawed by making some jerk anti-consumer move like that.

Remember 1984.... :eek:
 
I'll believe it. Apple might not have optimized the browser for the simple fact is they expect most users to interact with content via an application.

It's a different manner of user expectation. And, not too far out in left field, since Apple more or less said they will not support 95% of the Media on the web.

Instead, they expect content providers to write customized apps to serve their own content.
 
PSkeptic said:
I'll believe it. Apple might not have optimized the browser for the simple fact is they expect most users to interact with content via an application.

It's a different manner of user expectation. And, not too far out in left field, since Apple more or less said they will not support 95% of the Media on the web.

Instead, they expect content providers to write customized apps to serve their own content.
Click to expand...

I think you got that in reverse,

Apple optimized the stand alone Safari browser, but not the embedded browser that is used in many applications. Many applications indeed, use the embedded browser, among them Twitter for iPhone and Facebook for iPhone. In that sense, the embedded browser is even more important than the stand alone browser. In my use, I am far more likely to open the embedded browser than the stand alone one. For example, the Google Reader apps on the iPhone often use an embedded browser. If you see an app like the new Google Search for iPhone, it too opens an embedded browser.
 
Guamguy said:
I think you got that in reverse,

Apple optimized the stand alone Safari browser, but not the embedded browser that is used in many applications. Many applications indeed, use the embedded browser, among them Twitter for iPhone and Facebook for iPhone. In that sense, the embedded browser is even more important than the stand alone browser. In my use, I am far more likely to open the embedded browser than the stand alone one. For example, the Google Reader apps on the iPhone often use an embedded browser. If you see an app like the new Google Search for iPhone, it too opens an embedded browser.
Click to expand...

You are missing what I am saying here.

Apple is working under the expectation that content providers will write customized applications, distributed through the app store, rather than the expectation that content will be delivered via the web.

Hence, they just aren't all that concerned with web browser optimization. Why worry about it when all (Well, most) of the content served will be through an app, and not through a browser?
 
A lot of apps use browser code (CSS, Javascript, HTML) to format and display web content. And to further display more web content, they go into the full embedded browser. Its actually illegal for an app to display the content of a web page without including the advertising that subsidizes the article, as doing so would be stealling. That's why in proper news readers, you are only given a summary of the news article and then a link to read further that displays the full page which can include page advertising.

In both cases, with the summary, you have to use HTML/JS/CSS within the app to format and display the summary and then go into the embedded browser itself to display the full page. A good example of such an app would be Pulse News Reader.

One of the main points of HTML5 itself was to make browserless webapps. It was originally one of the premises of iOS---webapps are supported from v. 1.0 of iOS even before there was an App Store. It is also the mainstay of OS like Palm WebOS and Google ChromeOS. In fact, creatiing browserless webapps was one of the premises of Webkit, and its also the reason why WebOS and ChromeOS are based on Webkit.

So indeed, not optimizing for browserless web apps is surprising. Considering all the talk and support for HTML5.

You cannot divorce the use of browser code in modern mobile apps. In fact, if you are app centric, you really need to optimize execution of browser code for browserless webapps.
 
I'd venture to say many of the badly coded apps are application launchers that skin the web browsers on both platform.

So the webkit engine is very, very important.

It takes like a few lines of code to do it on the Android SDK. Embedded webview is easy to do. It took me a total of 15 minutes from after installing the SDK to make a "proto-type" web app for one of my clients.
On iOS, there are 3rd party dev tools for those who don't want or know how to do it via Objective-C.

HOWEVER,
we really don't know how Blaze did it. For example, did they do the web app on the SDK in Android and use a 3rd party app tool like AppAccelerator Titanium on iOS?

Thats how most Android developers I know would do it. Many of those who are more comfortable w/ Java but not with Objective-C would take the easiest route to get their app cross-platform. Did Blaze use the iOS SDK and not some 3rd party insta-app creator?

If so, the results can be highly skewed.

I do agree that the web-kit engine needs to be optimized across for all the developers.

Still, we do know this finding is inconclusive.
 
EarlyMon said:
No opinions on those Register comments?
Click to expand...

You mean this one?

App Store not invited to web's date with destiny [printer-friendly] ? The Register

Well, there are some real web-apps that perform better than their stand-alone native app-store versions.

E.G> take Youtube for example. The web version lets you play HD over 3G which bypasses AT&T's restriction.

It even looks and feels like a standard app. It even makes a custom icon on the home-screen.
So this example goes with what the Register is implying.

However,

There are some legitimate use for stand-alone apps.
Apps that require specific hardware like gesture shakes, access to camera or requires the ability to output to a dock accessory.

For example, the facebook apps is leaps and bounds more intuitive than the touch or mobile version of the website. It has contacts to users' phone book,etc...
Then there are news apps that cache the entire day's news once without further internet access.

Most of the apps I download myself are tailored for "stand-alone" apps anyways. E.G. Camera apps, Photo processing, music creation apps or apps that require remote/file access.

I can't see myself using a VNC web app that uses another person's server to connect to my own machines. I've seen those web-based AJAX SSH/VNC apps.


Lastly, another benefit of some "web-apps" are the fact they cached. E.G.

When I travel, I use XE currency and update my exchange rates whenever I get internet I may or not have internet access again for 2-3 days so It is vital to have a stand-alone app that caches that data.
 
EarlyMon said:
^Interesting.

Calls to mind two recent articles -

Apple handcuffs 'open' web apps on iPhone home screen - The Register

App Store not invited to web's date with destiny [printer-friendly] - The Register
Click to expand...

You bring up a very interesting point. Recently Apple was suspected of trying to muscle out eBook competitors like Amazon. Seems they didn't like these sellers by-passing their app store so they are requiring them to provide a means of purchasing through their app store as well as online. Otherwise their apps could be rejected or perhaps removed from iOS.

Apple is working under the expectation that content providers will write customized applications, distributed through the app store, rather than the expectation that content will be delivered via the web.

Hence, they just aren't all that concerned with web browser optimization. Why worry about it when all (Well, most) of the content served will be through an app, and not through a browser?
Click to expand...

If the embedded browsers on apps perform worse than the native Safari counterpart, what alternative would shoppers have in terms of making purchases?

I'm sure you know where I'm going with this...
 
NatesMom said:
If the embedded browsers on apps perform worse than the native Safari counterpart, what alternative would shoppers have in terms of making purchases?

I'm sure you know where I'm going with this...
Click to expand...

I'm not talking about embedded browsers, I'm talking about apps that pull in their own content, and manipulate it themselves, without using any webkit.

For example, I don't have to use webkit to bring in data from a website. I can use:

* SOAP
* XML
* Push/Pull mechanisms
* etc

Apple is expecting content providers to not just reskin their web content, but actually deliver it to the device.
 
^Understood - the second article, if I read it correctly, says that is full of fail - the app approach itself is insular.

My point was, if that's true, then we might care about the full browser experience.

Counterpoint example I can relate to would our Phandroid app or similar. I don't use that on my phone, I use the full web.

For those that do use apps instead, as you said earlier - Apple is pushing for an orthogonal approach.

I think one or the other makes sense - as I completely hate the mobile-browser settings, I can't imagine liking embedded browsers.
 
PSkeptic said:
I'm not talking about embedded browsers, I'm talking about apps that pull in their own content, and manipulate it themselves, without using any webkit.

For example, I don't have to use webkit to bring in data from a website. I can use:

* SOAP
* XML
* Push/Pull mechanisms
* etc

Apple is expecting content providers to not just reskin their web content, but actually deliver it to the device.
Click to expand...

I think we're talking about 2 different aspects of applications on iOS. Yes, you're right the apps can deliver content all they want using the various means you've mentioned above. I don't argue with that. I'm talking about apps that allow some type of purchase process, which then opens up an embedded browser interface and allows you to make a purchase over the web vs. through Apple's app store.(the Amazon mobile app is what comes to mind). At that point, you're technically outside of the application and in a browser window. Kind of the same lines as what Guamguy was getting at.

Forgive me if I don't have all the details of the Amazon app since I no longer have an iPhone but I think that's how it works and that's what I was commenting on in terms of why Apple may not want to optimize webKit.
 
The problem is that without an embedded browser, it is very hard to run an automated browser test.
What's better? Those artificial javascript tests that have nothing to do with real world performance? But you'll see everyone pushing those.
 
Seems they could write a test web page that auto-updated itself on a short timer with a counter, let it run a specific time, check the counter, do the math; repeat for other device.
 
You must log in or register to reply here.
Back
Top Bottom