We at McKenna Consultants get asked a lot about building “Apps” for mobile devices. Mostly we get asked to build iOs Apps (iPhone and the iPad), but the world is waking up to the 300,000,000 Android devices that are out there too!

No-one is asking for Windows 8 Apps yet, but I guess in twelve months or so we will start to see an increased demand there too. Let’s just forget about Blackberry. Sadly, I don’t think they will be with us as a platform for much longer. They are already showing signs of becoming a rights licensing business

If you are considering building an App, you need to consider platforms. Most Apps at the very least are going to need to work on iOs and Android. This is our first problem, and it’s a real pain because they use completely different technology and programming languages. You can use PhoneGap or similar technologies to minimise the duplicate investment, but your problems don’t end there…

Apple are not big fans of PhoneGap. This is our second problem. Apple really want you to invest in their platform, not their competitors platforms. You also have to deal with the snail’s pace that the Apple approval process runs at. Android stores tend to be quicker and the Microsoft Windows 8 store is the quickest of the lot (about 90 minutes from submission on average so far!). Remember too that you need to repeat this arduous process whenever you re-submit an update for your App to the store.

You also need to manage your App Stores when you create an App. This means you need to manage at least Apple, Microsoft, Google Play, Amazon, Samsung and whoever else you want to include your App on their store. That’s a fair bit of form-filling, download tracking etc that needs to be done for your App. You also need to be aware of the constraints of the various App Stores. Apple don’t like Apps that duplicate existing App functionality or replace default Apple App functions. Age restrictions may apply for different types of content etc. Apple won’t let you delivery subscription services without demanding a cut of the revenue. The list goes on…

So the alternative is to build your “App” not as a true App, but as a mobile web site using the principles of Responsive Web Design. By doing this you will avoid all the hassles of managing different App stores, duplicate programming effort for different platforms, App Store restrictions etc.


A mobile web site has its own share of problems…

First off, you can’t use all the features of the device as much as you would like. For example, you will struggle to provide a rapid barcode scanning interface on your web site. You might not get access to motion detection sensors etc. If these are critical, you need to consider a native App.

One of the single most important considerations is that web sites don’t work (easily) when you don’t have an Internet connection! There are solutions to this problem, but they are expensive and hacky! A native App can always be written to work offline pretty easily.

Despite the problems of App stores, people have got used to them and understand how to install Apps from them (they click the ‘Install’ button!) Getting your mobile web site pinned to the user’s home screen requires you to get them to jump through a couple of (fairly simple) hoops. There are some nice examples out there of how you can implement this. Weejot has a particularly nice approach to this.

It is also worth noting that the vendor App stores offer familiar marketing routes (highest selling App etc) for both you and your customers. You won’t get this luxury for your mobile web site, which leaves you with more traditional means of web-marketing your site.

Finally, an App provides a great App-like experience (duh!). Your mobile web site will struggle to provide the same App-like user experience. It can be costly to reproduce those nice user interface widgets that work out of the box on a mobile device. You can make it work, but it can be hard!

I don’t think that there is a definitive correct approach to mobile development today. All of the factors above need to be carefully considered and taken into account before you devise a mobile strategy. Failure to do so will lead to an expensive mistake down the line…