Axis, Opera Mini, pseudo-browsers and alternatives to Safari on iOS

Yahoo! has just released the new Axis app for iOS and desktop, promoted on some blogs as a new browser. It’s a good opportunity then to explain how this kind of apps work and why they are NOT browsers. If you are a web developer it’s important for you to know what to expect for this app.

Pseudo-browsers

I know but at some point it’s a matter of semantics. I like to call this apps pseudo-browsers: they pretend to be browsers.

If you have an iOS or Android device and you’ve used Twitter or Facebook you’ve already deal with the idea. When you open a link on those social networks you get an embedded browser and it’s basically using the UIWebView component on iOS and the WebView on Android (image at the right).

You are right. It’s the same component that is the base of native web apps –such as PhoneGap apps-. It’s not 100% the default browser embedded on an app, but it’s quite similar. Basically, both the default browsers (Safari and Android Browser) uses at some point the same code as the web views. However, browsers and web views have also differences in behavior, such as JavaScript execution engines or other HTML5 APIs.

On iOS –that’s for iPhone and iPad-, Yahoo! Axis, iCab Mobile, Skyfire, Dolphin, Mercury Web Browser, and other dozen of apps on the AppStore are not browsers, just apps using the default web view adding different behaviors on the UI, on the search mechanism or sharing features than the default Safari.

For a web developer or designer, it’s the same as the web view. That means that there is no new or removed API than what you can find using the default rendering engine. They are not really adding fragmentation to the mobile web world.

What about Android browsers?

On the Android side we do have different real browsers, such as Firefox or Opera Mobile with real different rendering and execution engines. And we have also some other pseudo-browsers available for download.

Why can’t we find real browsers on the AppStore for iOS?

Because of Apple Review Guidelines saying that any application with web content MUST use the default-rendering engine for HTML, CSS and the default execution engine for JavaScript.

What’s the deal with Opera Mini for iOS?

As you know, Opera has its own rendering engine. Well, Opera Mini, Puffin, iSwifter and other browsers, are cloud-based browsers. That means that your code is not being executed on the device but on a proxy server. There is no rendering or execution engine on the iOS so for Apple, the app is not using a different engine on the device.

Opera Mini had troubles to get accepted at the beginning (look at the joke for Steve Jobs Opera did on Mobile World Congress 2010), but finally Apple flexibilized the rule and accepted it and other cloud-based browsers.

Back again to the problem

Now you understand why there is no Firefox for iOS.

Now you understand why Axis is not a web browser.

Axis may be a tool to browse the web in a different way, but you are browsing the web with a –let me take a break and say- embedded Safari. If your website is being browsed by Axis it’s the same as in the Twitter, Facebook or Flipboard. You can expect mostly all the API support from Safari with an slower JavaScript engine –no Nitro for web view available- and some different behavior on HTML5 APIs.

Some guys were discussing on Twitter that you can say that Google Chrome is not a browser because it’s based on WebKit. Well, wrong! “Based on” doesn’t mean “using”. Chrome is compiling WebKit with additions and removed features, so for developers it’s really a new browser –it has different behavior, and we know that. You can compile your own WebKit flavor on iOS but you will never be accepted on the AppStore -at least with current rules.

 

 

Share

Tags: , , ,

Loading Facebook Comments ...
  1. #1 written by Gruml June 1st, 2012 at 09:31

    Seems to be odd for me to declare an app as browser only if it is using not the same web engine as another browser. You could also say that safari is not a browser, because it is using webkit which is used by atomic. You could say that Firefox is not a browser because it is using the gecko engines which is also used by other apps…

    Even if you say, that for example iCab Mobile is using WebKit and therefore can not provide more features than Safari, and so can not be called a browser, you are certainly wrong. Though both browsers do use the same webkit engine, iCab is able to upload files for example at Flickr.com, which safari and other iOS browsers can not do. Does this make iCab a real browser, or is this still a fake? The same web engine does not mean that the browsers have the same abilities to process and display web pages.

    In the real world, certain web engines are used by many browsers and all of them are real browsers. A browser is not just a web engine, it’s much more. Features like download managers, filters, bookmarks, tabs etc are much more important for the end user than the web engine. And these features are the reason why users prefer one or another browser. They don’t care about the internal tech stuff.

    RE Q
  2. #2 written by firt June 1st, 2012 at 15:04

    Hi Gruml, thanks for the comment. It’s a matter of semantics. However, Safari is not using WebKit; it’s based on WebKit. The same for Firefox. There is a difference. Safari and Firefox can remove, add and modify any feature of WebKit/Gecko. Axis can not. Axis is not in control of the rendering and execution engine, so in the next iOS version it may work differently (more APIs, less APIs) without Axis control. I don’t think you can have a browser business without having control.

    iCab Mobile can NOT add features to the rendering engine. Only because Apple is not allowing that. So the Flick.com upload is a fake. The HTML/JavaScript is not really working with an . When they are detecting that you are on Flickr then it’s like having a native client to upload pictures there. The same for SkyFire and downloading Flash video files. It’s a trick. I’m not saying that is useless, I’m saying that you (as a developer at least) should not consider them as a new browser for portability/testing purposes.

    I agree that from a user perspective it may not be so different, but in this blog I write about internal technical stuff for web developers. From a web developer’s perspective, it’s not a browser. And you should understand that. I’ve seen some tweet saying “oh, now we need to deal with a new browser”, and I need to be clear to say NO. And for me the best way to get the idea is saying that is not a browser. Then, you can read the whole explanation.

    Regards!

    RE Q
  3. #3 written by Gruml June 1st, 2012 at 21:21

    Actually icab mobile does have real support for file uploads. It’s not a fake. You can create your own upload form, which iCab can not know about, and it will work. Of course there are some limits because of restrictions of the iOS.

    Why don’t you talk about web engines instead of browsers. It simply does not make any sense to declare Camino, atomic, iCab that these are not browsers. These are browsers, they do what browsers are supposed to do, in ever aspect.

    Some of them use the same web engine, so as a web developer you don’t have to do something special for them. So just categorize the browser by their engine. This makes sense.

    Just telling that one computer is not a computer because it has the same processor as another computer makes no sense. And the same is true for a certain software type, like browsers.

    RE Q
  4. #4 written by firt June 1st, 2012 at 23:38

    I’m sorry Grumi but I can accept that this apps are being marketed as browsers, but not from a technical perspective.

    It’s not true that on iOS we need to deal with more than 50 different browsers just because there are 50 apps using the same Web View. You are starting iOS web development from a wrong perspective if you believe that.

    Just look at Axis on desktop; it’s a Chrome plugin. It’s a “plugin”, not a browser. On mobile there is no plugin architecture unfortunately, so creating a pseudo-browser is the way to implement that. And it’s fine! But Axis is not a browser from my point of view :P

    In your example of “computers” with the same processor. In this case, I believe that we are dealing with an iPad sold with an external keyboard accessory”. Is that a new iPad? no. It’s something around the same iPad with new features, a keyboard. So that’s what I think about pseudo-browser.

    You will need more to convince me :) Remember, my concern is about developer stuff.

    RE Q
  5. #5 written by Gruml June 2nd, 2012 at 00:09

    You have a very strange idea of a browser. Nobody has said that you would have to deal with 50 browsers. As a web developer you have to deal with web engines. A web browser needs a web engine, but of course it’s odd to state that there can be old one single browser on earth which uses a certain web engine. And while axis is a plugin on a desktop computer, it is a real browser on the iOS platform. It does not need a host browser, it’s a standalone browser on the iOS platform.

    the problem with your argument is that you are talking about browsers, but you mean and should talk about web engines,

    Back to the computer example. Following your arguments,
    this would mean that because a Windows PC with an Intel processor is a computer, a Mac or Linux PC with the same processor can not be a computer. Silly idea ;-) The processor speaks the same language, in all cases, that’s true, but does this make one device a real computer and the other a fake?

    RE Q
  6. #6 written by firt June 2nd, 2012 at 00:23

    Same argument, same answer. Thanks for your opinion!

    RE Q
  7. #7 written by Gruml June 2nd, 2012 at 09:30

    Sorry, but maybe you need to publish a new dictionary, so you can redeclare words, names with a well-defined meaning with your own strange view to the world ;-)

    Clearly when you talk about “browser” you are not meaning a browser, but only a small internal component of it (like when talking about cars, you are meaning it’s motor, when talking about computers, you mean the processor, when talking about a human being, your talking about the brain etc.).

    I don’t understand why you don’t just talk about web engines? Everybody has a clear understanding about what a browser is: an application that lets you visit web pages, save them, bookmark them, download stuff from the Internet etc. why do you need to change this meaning. You even don’t have a proper name for the thing anymore, all of the rest of the world calls “browser”. You have to call it pseudo browser. But you can’t explain why Safari is not a pseudo browser as well. Why is iCab on the iOS a pseudo browser in your point of view, even though it has added the webkit engine with (at least) one new feature (file uploads), but chrome is not a pseudo browser, but it also uses webkit like safari and also has a few other features?

    This all does not make sense, especially if you want to approach the topic as developer. As a develer you know that the web engine is the component you need to deal with, so name it.
    Please do not re-invent and redeclare the language and semantics. This makes communication a lot of harder.

    RE Q
  8. #8 written by firt June 2nd, 2012 at 16:14

    Now you have a great point to discuss. Yes, we need a new dictionary. Mobile web doesn’t have taxonomy. What is the definition of a webapp? What is the definition of a native app? Is a PhoneGap app a native app? When do you have an HTML5 app? Hybrid? What “native vs. web” really means? Is Axis a browser? ;)

    I’m just saying that everyone has a different meaning, so semantics are a BIG problem today in the mobile web world. I’m pretty sure you believe that there is only one answer to those questions but I can assure you that no.

    Developers and designers cares about browsers.

    Therefore yes, I’m writing a new dictionary. I’m starting with pseudo-browser, you can like it or not. I’m not the owner of the truth, I’m just publishing my point of view. Take it or leave it.

    1) It’s clear that Yahoo! didn’t want to create a “browser”. That’s why on desktop it’s just a plugin. On mobile, no plugin architecture. Call it however you want, but for me clearly there is a big difference between real browsers and these apps.

    2) It’s not just the rendering engine, you have also the execution engine, network protocols availability and configuration and other stuff around.

    3) The well-known list of rendering engines in the web community is: WebKit, Gecko, Trident, Presto. The mobile web browsing market today has 75% of WebKit-based browsers. If you believe that then mobile web it’s easy because you have only one rendering engine to test on, you are wrong and you’ll have lots of problems. Just compare Safari on iOS with Android Browser. The differences with the same rendering engine are huge.

    4) Safari on iOS, Android Browser, webOS Browser, BlackBerry Browser, Google Chrome, Nokia Browser, Bada Browser and Tizen Browser are WebKit-based, same rendering engine, and they are all DIFFERENT. Some browser had even different execution engines (JS). From a developer’s point of view, they are different browsers. When I’m saying different, I’m not just talking about the UI.

    5) Axis!, SkyFire, Dolphin, iCab are not just using the same rendering engine. It’s a very different scenario. They are exactly the same. Again, the iPad with a keyboard accessory it’s not a new iPad. It’s the same developer’s platform, the Web View. They need to be in a different level.

    So yes, I will re-invent and redeclare the language and semantics because we don’t have one yet unfortunately. Thinking that the mobile space is the same as desktop it’s a big mistake and leads only to problemas on the development side.

    We do have lots of browsers in the mobile space (around 40) but Axis is not on that list. Axis and company are counting as only one web platform.

    I’m just trying to make communication easier and let anyone understand what’s going on really. I prefer to exaggerate with definitions and not confuse developers that I found on Twitter complaining that with Axis now we have more fragmentation on the mobile web world. Well, clearly not.

    RE Q
  9. #9 written by Gruml June 2nd, 2012 at 23:42

    The problem is, if you change the meaning of words, you don’t make communication easier, instead communication will be much more difficult. And the fact that you think you have to write this blog post proves, that your new meanings for common words is not understood by others.

    Just do it right: it you need to distinguish between different web engines, talk about webkit of chrome version x, webkit of chrome version y, webkit of safari version z etc. then you can let a browser a browser and don’t need to confuse people with pseudo oddities ;-)

    RE Q
  10. #10 written by firt June 3rd, 2012 at 13:58

    I’m not changing meanings, I’m creating new ones because the current names are not valid anymore in the mobile space and they only confuses developers coming from desktop. You’ve made your point. Thanks.

    RE Q
  11. #11 written by recognitium August 2nd, 2012 at 15:05

    Hi Guys, sorry for the intrusion. Just a quick suggestion trying to encompass both the exact and right use of words and the impact objectives on the message: why not use the term
    Pseudo-new-browser?

    RE Q
  12. #12 written by David August 15th, 2012 at 14:13

    Recently I found that certain browsers, take Mercury as example, get a different HTML5 scores compared to Safari, but if all browsers are basically “skinned” Safari, then how is this possible?
    And a Chinese one UC Browser even claims to have a custom “core”, which also performs not like Safari at all (and I don’t think it’s like Opera Mini, no)
    What’s the deal with these browsers? Thank.

    RE Q
  13. #13 written by firt August 15th, 2012 at 14:46

    David, UC Browser is a proxy-based browser -like Opera Mini-. Therefore, the rendering engine is on their server and not on the iOS device. That is how they can use a custom core

    RE Q
  14. #14 written by David August 18th, 2012 at 14:56

    Thanks. What about the HTML5 scores?

    Also, the way how browsers render the page seems to be different across those third party “browsers”, for example Grazing still uses the “checkerboard”, iCab seems to go full throttle and lags a bit on the original iPad, while Mercury performs relatively well, quite like Safari.
    I’m not quite familiar with iOS programming, but I thought they’re all using some UIWebView-thingy?

    What’s with all that differences? Thx again.

    RE Q

SetPageWidth