There are many approaches you can take to develop a mobile app. Which one is right for you really depends on your specific app requirements. The main approaches are: either native code, cross-platform toolkits, or mobile/responsive website design. Each of them can have further variations but for the purpose of this discussion, we will focus on those three.

Native code is where an app is implemented using the toolkits provided by the operating system vendor; for example Objective-C (or now Swift) and Cocoa Touch libraries for iOS or Java and the Android SDK for Android. Because they are specifically created for their operating system, they offer the best performance, best memory footprint, and also provide the best user experience. Moreover, they also provide better access to device specific resources such as the GPS, camera, accelerometer and so on. Unfortunately these languages/toolkits only work on their respective platforms, so if you implement an app for iOS using Objective-C, it will not work on Android. This restriction means you have to redo the work for Android resulting in extra work and higher development costs. This additional work may not necessarily be double the original cost (depending on the approach taken); however, increased development costs are inevitable with this approach.

Cross platform toolkits, as the name suggests, allow a single toolkit to be used across multiple operating systems. Basically you employ one common programming language and the toolkit handles the variations between the operating systems. There are many different flavours of cross platform toolkits. Some use web technologies (HTML5, CSS) with an embedded browser in the app, some use a cross-compiler which converts code from a common language into the specific platform language, and some use a virtual machine to abstract the operating system from the app. The advantage of this approach is that you can reuse the same code on all platforms greatly reducing your development costs. The disadvantages can be more subtle but can be pretty serious in some cases. Firstly, since the code is typically interpreted, the performance can be a little slower than the native equivalent. Secondly, since the hardware and operating system specifics are abstracted, some features are simply not available. In the same manner, when cross platform toolkits are created, the designers must typically take a lowest common denominator approach. For example, if a UI feature works one way on one operating system and another way on the other, they must make a choice on how to present the same UI feature. Finally, because the operating systems introduce new features on a frequent basis, the cross platform toolkit vendors need to play a game of catchup to offer the new features and doing so requires development time and incurs delays. Therefore even when a new feature is available on the operating system, the feature may not available on the toolkit for a period of time after the release of the operating system.

Mobile or responsive websites could also be considered a cross platform toolkit; however, the typical use is where the code resides on a server and is downloaded by the mobile device at runtime as opposed to having an app installed on the device with code running locally. A mobile site is where there is a specific version of the entire site that you get redirected to when viewing the site from a mobile device, for example http://www.cbc.ca/m/news/. Usually the site detects the type of browser used when you hit the main site and redirects you to the mobile site. A responsive website is a single instance of a website where the pages refactor themselves based on the form factor and resolution of the device. A good example of that is our own website www.14oranges.com. The best way to see how it works is to visit the site using your desktop browser and then resize your browser window to a very small size and see how the elements (menu, images, text) adjust on the fly.

Now that we have described all three approaches, the one which is right for your project depends on several factors: user experience & frequency of use of the app, presence on the various app stores, app functionality, and of course budget.

Ask yourself how often do you expect your users to use the app? The more often they will use it the more likely they are going to expect a rich user experience, and the more likely they will need the performance and user experience of a native app. Typically if you reach more than once a day, native is best. The key question is: would your users be annoyed if they had a less than ideal user experience and had to deal with that over and over again? If the answer is yes, then native is likely what you want. If the answer is no, then an app built with a cross platform toolkit might be suitable.. If you expect users to interact with your app very rarely, then a responsive or mobile website would likely be a more cost effective choice.

App Store / Google Play presence is not as important as it used to be but can still be a good primary go to market channel. Receiving favourable reviews of your app on one of these stores is a great way to get traction into your app and ensure future success. Both native apps and cross-platform apps are normally distributed via those channels. Responsive and mobile sites are distributed via the web; however, it is possible to add a native wrapper (with some tweaks) to such sites to make them available on the app store. So if app store presence is what you are after, all options can work for you.

What functionality does your app require? As already mentioned, any functionality which makes use of onboard hardware services will usually be better accessed via a native app. Also if you plan to deliver your app as a suite of apps, native will provide better collaboration. If your app requires push notifications then native is likely the easiest option although it is also possible with cross platform toolkits (with some limitations). You cannot have push notifications from a mobile or responsive website unless you add a native wrapper. In general, the more complex the required functionality, the more the solution points toward a native app; however, cross platform toolkits can provide quite a bit of functionality if you are willing to accept compromises on some features.

It goes without saying that budget is always a factor when developing an app. The more features, the more platforms, and the more user expectations will typically lead to a higher price; however, don’t be discouraged as there are sometimes ways to migrate over time from one solution to another. Rome wasn’t built in one day and neither were Instagram and Facebook. Sometimes looking at your app and figuring out the desired feature set to make it an “MVP” might open up some opportunities to start with a simpler and cheaper option which can then be improved upon over time.

If you still are not sure, feel free to contact us so we can review your requirements and make a recommendation about which solution would be right for you.