Focus – Developing Mobile Applications – and why you should care
By Aidan Caffrey - Application Development Manager
All around the world more users have a smart-phone and/or a tablet every day 1. This change has caused the application marketplace to change drastically over a short space of time. In this new world, it is now easier (and maybe faster) to connect with and generate revenue from a large audience. It’s also easy to be left behind with the high pace of change, or build an app that nobody wants…
More statistics are continually produced comparing web-traffic from mobile browsers to that from desktops, and revenue figures from apps/advertising 2. The world is full of predictions of “mobile browser traffic surpass[ing] desktop in 2014” 3. This means discussions have moved away from whether to be considering the mobile space to we need to go mobile – but which way is best in our exact scenario.
So let’s consider and evaluate the different options:
It’s entirely your prerogative to ignore the mobile
space. In some rare domains mobile doesn’t make sense. It might actually cost
you more to solve this problem that you’d generate in revenue.
Make your app look good on a mobile browser
You need to answer this key question – are
you updating your app purely to look good on mobile browsers, or are you
building different functionality for the mobile version of your app?
If your vision goes beyond look and feel, you
are actually building a different app. At this point your thoughts should turn
to code re-use, maintenance of the dual code bases, and how they evolve in the
If it is just a User Experience issue, there
are two major options; – firstly, can you manage the differences purely with styling
changes? If so, CSS3 Media Queries could be the answer – provided your target browsers
support HTML5! If you cannot the alternative is for the server to respond with different
HTML based on the browser. In ASP.NET MVC 4 this is implemented with “Display
Port your app to a native app for a particular OS.
What platforms are you going to target? Windows
Phone, obviously… but how about iOS and Android? Once you’ve decided, do you
have the skills and tooling in your team to do this? You may need training,
physical devices, emulators, IDEs, and more. How do you build it in a CI
environment, and what is the impact on your testers?
Native apps have a very different lifecycle; they
are in an “often disconnected” world, and the platforms will evolve
independently of your app; updates might change the way the app can run, its permissions, or the device
capabilities. Planning for the maintenance involved and determining the
economic and servicing model are fundamental to your success.
with a thin native wrapper around it. This reduces the amount of native code to
write, maintain, run, port and test, but can increase the skillset required.
Alternatively you could use tooling to do this part for you, but it is likely
to be limited to the “lowest common denominator” rather than fully utilizing
the device capabilities.5
Which approach you select depends on your priorities and what you are trying to achieve. If you don’t need to support mobile, do nothing; although this is rare today. If you do, using Media Queries or Display Modes can be a cost effective way to prevent a loss of business through a site not compatible with mobile devices, or to start providing great mobile experiences for like-for-like feature scenarios. When your gear shifts to investment, seeing mobile as a true growth area and a distinct part of your offering, start thinking about native or hybrid approaches. This brings the ability to target your feature set and User Experience directly at mobile users in return for additional effort in development, maintenance, and related disciplines such as