Sunday, December 21, 2014

Using browser versus app to deliver your services on mobile devices

The full fledged mobile computing devices are far more common these days than the desktops had ever been. The websites are delivering services more to mobile devices than the desktops. Google now claims to get more searches through the mobile devices these days.

Today most websites will ask you to download their app and install on your mobile device. With package managers like "Google Play Store" people find it extremely easy to do so. Just with a single click and a disclaimer of all possible privacy violations, people install the mobile app.

It is strange that html browser that has been the de facto standard for delivering content and untrusted code has been swiftly replaced by the mobile app. Browsers provide security from untrusted code as the exposed scripting language like javascript is managed code wih limited functionality. In cases where people install "native code" like Adobe Flashplayer, people are at mercy of the "severe bugs" in flashplayer that keep appearing every week. No doubt today that social engineering attacks targeting vulnerable flash player has been quite common on facebook.  Javascript engines never had that many issues.

If installing any "native code" is so dangerous, the obvious question is how come folks are installing mobile apps from untrusted sources without any second thoughts? Some would argue that Android provides a Java framework and so all apps are written in Java and so there is little chance of having vulnerable programs. That is quite untrue as apps are allowed to bundle native code that they can be invoked through the JNI interface. Bugs in native code could be exploited by any other untrusted app.

Beside security, mobile apps have also turned the head upside down on traditionally asynchronous applications. For example, I used to open up a mail app to check for new mails. With the mobile apps, it will beep you everytime you get a mail. And yes not all mails deserve my attention immediately. So converting asynchronous applications into synchronous ones provide little utility and very annoying beeps.

Some people believe searching the app is faster than typing it on browser. But today's browsers provide easy navigation by using bookmarks and clickable thumbnails. So that argument is also spacious.

Lastly, there are many sensors in a mobile device (like GPS, compass etc) that can be used by a mobile app to deliver better services. While HTML 5 has incorporated some of these sensors,  that remains the perhaps only legitimate resign for installing a mobile application.


4 comments:

Saurabh Jain said...

I really see no point in ecommerce mobile apps, other than them annoying you with asynchronous notification about sales and deals. The apps waste bandwidth every time they update or precache content. The only advantage to the customer is app only offers. And the annoying messages to install the app, when perusing the mobile ecommerce site, are no longer there.

freemind said...

fix typo ("resign"): only legitimate resign for installing a mobile application

freemind said...

the topic you brought up is very interesting. apps, IMO, does break some of the basic ideas that built the internet.

however, I also did a quick experiment with my cell phone. I can confirm an ola cab booking using the app with 5 taps. if I have to use the browser, it's > 10 taps (that includes typing "ola" in url-cum-search box). looks like ola's mobile site is not optimally designed. and I don't have any shortcut/bookmark for ola.

however, the app still "feels" better. I see an "ola cab" experience as soon as I tap on the app. the browser, on the other hand, subjects me to a blank screen while the page loads. again, the experience on the app is better designed. I don't know if a similar design is possible in html/javascript/css.

anil said...

Will love to use it, just read Carl tweet pl
Share anilg@sristi.org