For some time now I have been reading passionate debates about the relative merits of developing native mobile applications versus those of developing web apps that work on mobile devices. There are great arguments on both sides; covering every aspect from how the user experience works through to the cost of development and maintenance. But, every time I have read an argument it has been presented in a far too black and white manner for my liking.

There is no denying that if you are in the business of providing an online product or service you need to be thinking about mobile. Encouragingly, even the big multinational clients I work with have quickly picked up on the trend and are thinking about it.

But how you think about mobile and to what degree you choose to invest in and develop for it is another question, and one that some of those clients are struggling with.

Ignoring gaming, which is a special case and doesn’t need to be considered by most organisations, the majority of online products and services fall into one of two categories: either they are web based applications (allowing users to create or manipulate data), or they are web based information portals (presenting data).

For both types of product there are three popular approaches you can take to supporting a mobile user base:

1. build your web application as a universally accessible web application (using techniques like responsive design and methodologies like designing for mobile first)
2. provide a mobile optimised (usually a cut down, less feature rich) version of your application along side your existing offering, and using clever redirection to filter mobile traffic to the mobile specific version of your application
3. build a native mobile app that compliments your existing offering.

Which of these options you choose needs to be dictated primarily by your user base, their content and functionality needs and their mobile usage.

But here’s the important bit; you don’t have to pick and stick to only one of these options. They are not mutually exclusive. In fact, I’d suggest that options 1 and / or 2 are compulsory, even if you are developing a native application as described in option 3.

Choosing option 1 as a minimum future-proofs your product: If (or rather when) a new device launches next year, as long as it has a browser, you already support it. After launch you can track and evaluate how many of your users adopt the device before rushing to support something natively that none of them end up using.

Even if you provide a native application (option 3), people will still try and access your site via their mobile browser and not supporting those users is a dangerous strategy. As more devices and variations of those devices emerge, supporting and adapting native applications for all possible versions becomes more challenging (and costly), a universally accessible version of your web application is a good baseline for supporting all visitors, whether they choose to visit via a bleeding edge device or not.

This baseline version of your product or service can then be complemented by a targeted mobile optimised version of your web application (option 2), or native apps (option 3) where your user base will benefit most from them. If for example you find that 90% of your mobile traffic is coming from iOS powered devices, and you feel that a native iOS app would enhance the experience for those users then making an iOS native app becomes a logical business investment. If, however, 90% of your mobile traffic is coming from Android users, the same iOS investment is not as desirable and your resources would be best spent on improving the experience for Android users.

When thinking about how to support mobile, instead of thinking about having to choose from one option or another, think about building your mobile strategy around a number of different degrees of support; with browser based access the bare minimum basic level, mobile optimised support as one level up and native applications as the ultimate, highest level of support possible.