Why consider a mobile site instead of an app?

In these years we find, that especially in the B2C segment, a lot of apps are developed based on arguments like “That’s what all the others do”, “The trend is …” and “That’s where the customers are”. But an app is not necessarily always the right solution. An equally good or maybe even better solution can be a mobile website.

It goes without saying that all technology choices have pros and cons: You win something and you lose something else. Where we, in Aros IT, often have won something by choosing a mobile website, the win has been on the costs and development time.  Where we’ve lost something, by choosing a mobile site instead of an app, it has been on the technique and the user experience.

One app is rarely enough

An app is a technology tailored to mobile devices, and of course it has a big advantage. In addition, if offline functionality or heavy graphics (e.g. for a game) is required, an app is the obvious choice. The challenge is often that an app is not just one app but closer to two or three, so both Android, IOS and maybe Windows Mobile are supported. At the same time, if the system should work on a computer in a browser, a version must be made for this as well.

Updates and bug fixes are starting to be both difficult and expensive when supporting that many platforms so this is where a mobile website can offer something better. With the right structure and design, a mobile site can work in any browser on any device, i.e. on a mobile phone, tablet and computer. Updates can be done centrally and only once, making it both cheap and fast to distribute new versions.

The trouble with the App Store

It does not mean that the Holy Grail is well preserved. For example, I will be the first to admit that it’s easier said than done for one mobile website to support all devices and browser versions. But it’s certainly not easy for an app to support all OS versions and screen sizes as well!

Likewise, one can and will be challenged with a mobile website in terms of accessing, for example, camera, flash, GPS and file storage locally on the mobile device. Here, an app distinguishes itself from being distributed through an App Store which determines these permissions during the installation of the app.

On the other hand, App Stores can be a troublesome part in the process, that even costs money and requires the App Store owner to approve the app or, even worse, it is not approved. In other words, to a certain degree, you lose control over the length of time it takes to distribute a new version or a bug fix.

When an update to an app is finally ready in an App Store, one may further be challenged by the fact that it is up to the end user to ensure that the update is done locally on his or her mobile device. Thus, with an app, you should decide whether it is possible to use different versions at the same time or whether it should be completely denied, so that all users are forced to update.

Less time spent on development

In Aros IT, we have recently developed the first part of a system for a customer, where we have experienced the dilemmas close up. It is a solution for handling photos and the usage scenario is that the customer wants to take photos from mobile devices, where each photo is enriched with customer-specific data and uploaded to a central system. When uploaded, the photos are exposed via an API from the central system to a number of internal systems that make use of these photos in different ways.

In dialogue with the customer, we reached the conclusion of building the solution as a mobile website instead of traditionally building it as an app for i.e. Android, IOS or Windows Mobile. This has proven to be the right choice, which can be seen on the economic bottom line, where the time spent on development, maintenance and distribution is much lower than it would have been for an app. At the same time, the customer is not subject to external conditions such as an App Store and has total control over all hardware, operating systems and devices.

But what do you think? And do you have any experiences that you would like to contribute? Then write to me at jbg@arosit.dk or post a comment below.


Om forfatteren:

Jørgen er certificeret Scrum Master og Scrum Product Owner. Han har arbejdet med IT-udvikling siden 1996 og har været selvstændig siden 2007. I 2011 indtrådte han som medejer af Aros IT.

Læg en kommentar