I’ve recently been discussing a mobile web app module we have in development for our CMS with a number of existing clients and potential new ones and I’ve learnt a few things of late about peoples understanding of mobile applications; that is to say, as soon as I mention ‘native apps’ in the same breath as ‘mobile web apps’ I confuse at least 80% of my audience. It has been an interesting learning curve for me establishing just what level of understanding people have on these two distinct (but similar… confused already?) methods of reaching an audience and delivering content so I thought I’d write a bit more to help clarify a few things in an attempt to aid an informed choice of which direction to take.
What is a Native App?
Generally speaking, if a customer comes to us with a requirement for a ‘mobile app’ most (99%) will be thinking about a Native app. Native apps are pre installed application featured in a specific device, learn more about mobile betting here, and be one of the best! By Native I mean an application built for a specific mobile handset (they will be picturing a shiny iPhone), purchased from and delivered by a central store (they will be picturing Apple’s App Store), installed on the mobile device with an icon on the homescreen with updates managed through the store from which it was downloaded.
Do your clients Actually Want a Native App?
When you delve into what it is the client actually needs, it is not always apparent that a native app is the most suitable or appropriate tool for the job, especially if it is one being developed in a specific language (Objective C for instance in the case of an iPhone) which then needs porting to other target devices (for example BlackBerry, Android and Nokia).
As is often the case, what a lot of people think they need is down to a preconception (often established through marketing, advertising, trends and fads) that one way of doing things is the only (and best) way of doing things. The alternatives are not explored because they only appear on the periphery whereas particularly with the iPhone, iPad and the App Store people have perceived understanding of the end–to-end delivery and usage of a native app.
What is a Mobile Web App?
On the other hand, when I discuss mobile web apps it is clear from an early point in the conversation that most people think I am discussing a native app whereas what I am actually describing is an application developed on the web specifically for mobile devices (at present many sites use the ‘m’ subdomain to host their mobile web apps); to all intents and purpose this website (mobile web app) might look, behave and feel much like a native app but it is accessed through a browser and doesn’t have to be downloaded via an app store. In a lot of circumstances mobile web apps are actually advantageous:
- You can better manage development across multiple platforms
- They can look and behave like a native app (even having an icon on the homescreen) so UI/UX can retain a ‘familiarity’ across both types
- Other than fetching the initial data / framework the app does not have to be online to run (a common misnomer) as content can be cached and we can use HTML5’s offline mode
- You don’t have to go through the App Store acceptance procedure and updates / enhancements can be released as and when required (see point one)
- There is no reliance on someone else’s business model (eg Apple) to monetise your idea
- You get to keep 100% of the revenue you generate
- As you will see in the final paragraph, mobile web apps can be packaged as native apps for multiple platforms (eg iOS, Android, Symbian, Blackberry) using mobile frameworks such as PhoneGap and Appcelerator Titanium
- Applications can be developed more rapidly (see all above)
Native is Still Best (sometimes)
That being said, there is no denying some advantages that native apps (particularly in the case of Apple) have:
- End users currently better understand the concept (of the store – application – handset relationship)
- Businesses currently better understand the business model because it is quite simple
- People feel confident in the application vetting process and therefore have confidence they are not being scammed or having malware/viruses delivered to their handset via the app
- You can access all the handset features and hardware (eg: the camera, geo locations, graphics acceleration, file system and so on)
- Monetisation of the app itself – if your idea is to produce an app which makes money just because it sells 1 million copies at 59p then this is the only way you can go
There is a Third Way
Our mobile web application development uses the Sencha Touch framework (a HTML5 Mobile Web App Framework for touch screen mobile devices). We can expose various methods of our content management system (for getting content or defining functionality) via webservices which take parameters and data and return data in json format (or XML if you desire) to the Sencha Touch application. The framework allows development of mobile web apps and provides a local storage proxy for saving data offline.
The Sencha Touch framework runs on Webkit which is shipped with all the major mobile devices these days (and Google Chrome) so when browsing the mobile web app via a web browser on the mobile handset the user experience is fairly consistent and as previously discussed can very much be like a native app.
However, if you want to deliver your mobile web app as a native app this is now possible using frameworks such as PhoneGap or Appcelerator. In our case we use PhoneGap which allows us to provide native functionality such as access to geo location, camera, storage, contacts and so on (list of PhoneGap API features).
The steps are fairly easy (paraphrased here):
- Develop your mobile web app in Sencha Touch (or other)
- Add any native functionality your require (and is supported by your framework)
- Package this up for your target device in PhoneGap (or other)
- Send native app to appropriate store for acceptance testing
- Sell / provide your app via the app store
See, sometimes you can have the best of both worlds!