Of all considerations when developing a mobile app – by far the most important would be which architecture to choose for the client application. Should you build a native app or a mobile web app? Should you try to build a single application that works across all mobile platforms? Tough questions – and there is no one right answer or one best option for mobile app development. There a number of factors to consider including:
- Target audience – who will be using the app?
- Target platforms – what devices will be targeted?
- App features and functionality – what features will be in the app? What hardware features (mic, camera, compass, gps, etc.) will be used
- Timeline and budget – how fast do you need an app and how much are you willing to pay?
- Developer skills – what languages and platforms do your developers already know how to use?
The client architecture options can be broken down into a couple different areas…
Native apps are binary executable applications that are stored on and run locally on the device. Native apps usually work just like any other built-in app (mail or web browser, for example) and have full access to the device APIs and features, as provided by the vendor. Native apps are usually obtained via an app store (i.e. the iOS App Store or Android Marketplace), though can also be obtained via enterprise or ad-hoc deployment depending upon the platform. Native apps are also usually updated via an app store (or similar) and there can be a lead time and approval process involved before updates can be deployed to end users.
Native apps are usually developed in the default language of their respective mobile platform, for example – Objective-C on iOS, Java on Android, and C# on Windows Phone 7. As native apps are usually written using a programming language, framework, and tools specific to a single mobile platform – they cannot be used on other mobile platforms. So, perhaps an obvious example – but Android apps can’t run on iOS and vice-versa.
Mobile Web Apps
Hybrid Mobile Apps
Now that we’ve defined our three client architecture options, we can get into the detailed strengths and weaknesses of each platform. We’ll look at a couple different areas including performance, distribution, deployment, access to hardware features, offline functionality, cost, and the portability of code between mobile platforms.
One key performance topic to keep in mind is UI performance. Few mobile web apps can fully replicate the smoothness and responsiveness of a native app UI without some minor jitteriness, lag, and inconsistencies. Some can get very close (usually on iOS), but then the UI works poorly or not at all on other platforms. UI performance should be a major factor in the consideration of which architecture option to use. If the absolute best UI performance and user experience are required, or the app is a highly visible “marquee” application, go with a native app. If the app requires performance-intensive client side processing, go with a native or hybrid app. Otherwise, a mobile web app may work well if the app will be built on multiple platforms and doesn’t require the top-quality UX.
While mobile web app performance isn’t currently on par with native app performance, web app performance as well as tools and libraries for building cross-platform apps have both improved greatly even within the past year. These areas will see advancements as mobile hardware is upgraded, platform vendors enhance their web browsers, and commercial and open source developer tools are improved eventually bringing mobile web app performance up to par.
Native and hybrid apps can be downloaded and installed directly from an “app store” on most modern platforms, which provides a potential marketing boost and an easy way for potential users to discover and download apps. The vendor’s app store is then also responsible for alerting users and deploying updates to apps. However, one issue with app stores is the inevitable lead time involved in waiting for approval of new apps and app updates, which can take a week or more depending on the time of year. If delayed updates or approvals would be an issue for your app, you may want to consider a mobile web app instead.
Native and hybrid apps can also be deployed to internal corporate users via “enterprise deployment”, by a mobile device management (MDM) solution or an internal “app store”. Being limited to internal corporate users, enterprise deployment of apps requires no vendor approval for updates, etc. – putting control in the hands of the IT department.
Mobile web apps also require no approval from a vendor for deployment, as they’re usually accessed by the user entering a URL into the web browser. Most mobile platforms usually offer some way to “install” or bookmark a mobile web app so that it will appear on the user’s home screen and can be launched by clicking an icon, similar to a native app. Updates to a mobile web app can be deployed by simply updating the server-side code. If there is a need to iterate quickly on updates, a mobile web app may be a good choice. Mobile web apps have an additional benefit of being discoverable and directly accessible via search engines.
Another item to consider about vendor app stores, most vendors (Google, Apple, and Microsoft) take a 30% cut of any purchases (of functionality, subscriptions, services, upgrades, or content) completed within an app. If in-app purchases are core to the app and revenue – consider building a mobile web app. To note, an app submitted to the Apple App Store that uses any alternative, non-Apple in-app payment system would be rejected – so a hybrid app would not be able to circumvent these rules by routing purchases through a web view.
Access to Hardware
Native apps generally have full access to the hardware features of a mobile device, i.e. the camera, accelerometer, GPS, compass, file system, storage cards, microphone, etc. While mobile web apps are improving in this area with HTML5, they still have more limited access to the hardware features in most cases. Furthermore, it’s unlikely that the same web code will be fully supported and usable across all platforms (i.e. iOS, Android, and Windows Phone 7) as they all currently differ in their level of support for HTML5 and hardware device access. For example, GPS is currently well-supported by web apps on most platforms – but accessing the camera or uploading photos is poorly supported by most mobile web browsers.
Native apps generally have the most capable offline functionality, as they usually have some ability to run background processes and it’s easier to gracefully handle offline scenarios in a native app. Mobile web apps traditionally require internet access in order to use. However, this is an area where web apps are rapidly improving – but support is still not uniform across platforms, and a user can always blow away an offline web app by clearing their browser cache. Mobile web apps also currently have limited capabilities to run background processes (when the app is closed) or worker threads (while the app is still open) – for example, it would be impossible currently to build a mobile web app that plays music in the background while other apps are running.
Native apps, on the other hand, must be completely re-written between platforms – Objective-C code won’t run on Android, and Java code won’t run on iOS. For a hybrid app using a mix of native and web code, only the web-based portions would be portable between platforms and the native portions would need to be re-written.
Cost and Timeline
Cost and timeline are usually the most important factors in most software projects. Native applications have to be completely re-written between platforms and thus have the highest cost if you plan on building an app on multiple platforms. In a perfect world where mobile web app code works perfectly across all platforms, mobile web apps would theoretically be the lowest cost option for cross-platform development. Unfortunately, a significant amount of time is often spent at the end of a mobile web app project ironing out inconsistencies and performance across different platforms usually increasing the cost beyond that of building a native app on a single platform. Nonetheless, developing a single codebase will always be less costly than developing three separate codebases. For hybrid apps, only the native portion of the app must be re-written between platforms, placing the cost of building cross-platform hybrid apps somewhere in the middle between native apps (highest cost) and mobile web apps (lowest cost).
For example, Xamarin MonoTouch and Mono for Android allow you to write native apps for iOS and Android using C# and re-use all non-UI code. That code can then also be re-used for Windows Phone 7, which uses C# and .NET APIs by default. UI code usually makes up about 40-60% of a mobile codebase (depending on the UI complexity), which allows a significant amount of code to be re-used between platforms. Xamarin also provides a set of agnostic APIs that allows for a unified cross-platform method of accessing features like GPS, contacts, camera, media, etc., which makes code sharing across platforms easier. These native cross platform products are a viable option (especially MonoTouch, from personal experience) for building true native applications, while still retaining some level of code portability between platforms.
Each architecture option works best for different kinds of applications. Native applications currently work best for:
- Performance-intensive apps
- Apps with offline or disconnected requirements
- Games or apps with rich visuals
- Apps that require background processing
- Apps requiring heavy interaction with local data or device hardware
Native apps also work well for marquee applications that can’t compromise on user experience or performance, where cost savings and productivity gains from cross-platform code sharing is not a goal. Native apps also make sense if only a single platform or device is being targeted, where there is no reason to re-use code on other platforms.
Hybrid and Mobile Web applications work well for business and content applications, and apps with more basic user interface and functionality requirements. They both also work well for apps targeting multiple platforms. Hybrid apps work well for adding native functionality to existing mobile web apps, or simply creating a native wrapper around a mobile web site. Mobile web apps also work well for creating a simple mobile-optimized version of an existing web site.
Keep in mind that these technologies and decision points will continue to rapidly evolve – browser compatibility and performance will improve, HTML5 standards will be solidified, and products like MonoTouch will be developed further. While there is no one best client architecture option, the best option for your app can be determined by weighing your requirements and goals against the capabilities, advantages, and disadvantages of each architectural option.
A short deck summarizing the options and their strengths and weaknesses is available here.
Our consulting professionals are experienced in developing enterprise and consumer mobile applications on the Apple iOS, Android, and Windows Phone platforms. Click here to read more about West Monroe Partners’ Mobile Application Solutions.