Part I

– Frequently when I tell people I create mobile applications for a living they respond with their own idea for a mobile app. I see they are brimming with questions – more than they can articulate. Where to begin… what’s involved, how to find developers, how much does it cost. I’m happy to answer these questions – I love what I do and I love to talk about it. It occurs to me however what might be of more use is to supply a link with answers to the more common questions. The following article serves this purpose.

 

First things first, let’s enumerate the three avenues for creating content for mobile – Mobile aware web, Hybrid Applications, and Native Applications.

Mobile aware web

Simply put this is any website that takes steps to render differently for the smaller screen size of mobile devices. This is commonly referred to as “responsive design” – the site responds and adapts to different screens sizes. In general the site will become more compressed and elongated. Menu’s will be collapsed into what is sometimes called a “hamburger menu” (three horizontal lines denote the menu), mobile friendly graphics will be substituted, and the site is reviewed for any features that do not display appropriately on a small screen. There are various frameworks that help with this process taking some of the work required away from developers and designers – a prime example, Twitter’s Bootstrap framework. This site is an example of a mobile aware website, a custom wordpress theme done with Bootstrap. The format changes considerably for display on a mobile device. All sites should give at least some consideration to responsive design within the bounds of available resources and the likelihood of consumption on mobile.

Hybrid Applications

The quickest way to describe hybrid is to say it’s like a mini-website running locally on the mobile device. It may make use of content external to the phone but strictly speaking a hybrid application does not require a connection to the internet to run. Hybrid applications are installed on the device and are downloaded from the app stores. As such hybrid applications must undergo the same submission and review process as native applications. Hybrid applications allow for the use of web development skills and techniques like CSS, Javascript, and Html to create an app and frequently have a shorter development cycle then native applications. They do this by putting a “layer of web” in-between the developer and the device. There are numerous frameworks that facilitate the creation of hybrid application with the most well known being Phone Gap. Some of these frameworks claim they produce native applications – this is not true. The application runs natively on the phone (it is not web based) but it is not a native application. A native application is created by interacting directly with the mobile platform – Android, iOS, Windows Phone. Hybrid applications talk to a middleware that wraps communication with the platform and exposes a subset of functionality that can be manipulated using web methodologies (css, javascript, html). As such a hybrid application will always be slower and will always have a smaller feature set available. You can extend the feature set available but that requires writing native code to add those features to the middleware – more or less defeating the purpose of developing a hybrid app. I do not mean to imply hybrid applications are innately inferior to native application – not at all. Rather, it is simply a question of the right tool for the right job. If you’re looking for high performance, if you need custom and/or platform specific features, or if you find yourself with need to extend the middleware you may want to consider developing a native application from the start.

Native Applications

A native application talks directly to the devices operating system – there is no middleware. It has access to all the phone’s features and all things equal will run the fastest of all methods. Any code written is platform specific and cannot be used on other platforms. Code written to grab a picture and upload it to a website on Android will only work on Android – new code must be written to perform the same task on an iPhone. The platform should not be confused with the language that was used to write the code. On the Android platform traditionally the language used is Java while on the iPhone historically it was Objective C and more recently Swift. In theory any language could be used to create a native application – point of fact it’s not generally the case. Google and Apple publish their development kits for the languages they support – if you choose another language it’s on you to figure out how to make it talk to development kit and operating system. The one exception to this is C# – with C# you can write native applications for both Android and iOS (and Windows phone though it comprises less than 3% of the mobile phone market). It’s possible to write a native application with C# without having to worry about how to communicate with the phone because this work has already been done and made available by a company called Xamarin. Xamarin is both the name of the company and the name it uses for it’s C# for mobile framework. Xamarin is a paid product where developing with Java and Objective C or Swift is free. The question of which to use really boils down to whether you believe the benefits of using single language outweigh the costs of purchasing the product – speed/performance is on par between the choices.

Choosing among the options

As with most things it depends on your needs. If you don’t actually have a need for a mobile app save yourself the expense and go with mobile web – if you’re using Bootstrap you are 80% of the way there already. The case between hybrid and native is less clearly defined. In general I shy away from hybrid in all but the simplest use case. I’ve written both and while hybrid typically has a shorter development cycle the costs of a hybrid app should you outgrow it overshadow the savings. Like many “quick start” tools they are great so long as you stay tightly within their use case. Once you start to push the bounds of customization – slick screen transitions, large “infinite” lists, lazy load functionality – you run into problems. It becomes more work to implement these features for the hybrid app then native, if you can implement them at all. Use case for hybrid are more basic apps that either aren’t expected to be extended in a material manner or that it is acknowledged at some point hybrid development will end and a new native app will be developed. It may also be the case that money for development is extremely limited and in-house web staff exist that are keen on learning mobile – a win win. Native apps are expensive, it’s a given. Mistakes are much more costly and I’ve met more than a few that lost their entire initial investment using a less than reputable firm – there are a lot of sharks in those waters. The rewards however can also be big – a game or utility can produce a substantial windfall and a really well written app can be a show piece for a company. If a mobile app is a need then nine out of ten times I will say go the native route. Hybrid has it’s place but it’s limited and the other two options, native app or no app at all, should be well considered before making a decision for hybrid.

Next up: Starting Development – making the rubber hit the road