Apart from deciding whether an app should be customer-oriented or internal-facing, there are various development options that need to be looked at carefully, as requirements for integration with internal back-end systems vary from company to company.

The technical aspect of app development can be narrowed down into two main categories which are hybrid and native app development. Broadly speaking, hybrid app development offers the possibility to write one set of code which will make an app work on both iOS and Android phones, whereas native coding means coding individual sets of code for each operating system. Both methods can offer advantages, depending on the requirements for the app.

Most enterprises starting out on app development direct their main focus towards cost factors when deciding whether to develop hybrid or native, with hybrid often presenting the more cost-effective option at the build stage. Mubaloo previously posted blogs about considerations of hybrid vs native app development and different factors involved in the decision process. These are listed below. However, focusing too much on short-term cost savings when building an app is often a short-sighted decision which can incur higher maintenance costs and less product control further down the line. It’s therefore important to consider both hybrid and native development from the perspective of an app’s lifetime; from conception, to build and release, as well as future updates and maintenance.

Total Cost of Ownership

As mentioned, there are definite benefits to both hybrid and native app development. Which approach a business should take ultimately depends on whether the benefits are considered in the short or longer term and what the individual requirements for the app are, both from a design and a technical aspect.

With regards to development speed, short term benefits of hybrid apps include that these are often quicker to develop as essentially only one set of web-based code has to be written (in HTML/JavaScript and Apache Cordova) with some additional code to render the app in the desired OS systems. Enterprises might also have internal developer skills that they can tap into, thereby saving on some of the development cost. In the longer run this could also mean that maintenance for a hybrid app can be cheaper if the right in-house team is available—

though it is worth noting that developers need to have in-depth knowledge of app development, including native, to provide the necessary expertise. It is worth considering the overall time investment at this stage though, as in-house developers often work across various internal projects and won’t necessarily be able to provide the resource required to maintain an app.

There are now a number of cross-platform implementation options that allow developers to write in one language which is then compiled for each of the native devices, with options including Xamarin, Titanium and React Native. The advantage of using this approach can be that several coders can easily work on one set of code and only need to use one coding language. There are however restrictions that need to be considered. Whilst some of these platforms allow developers to use native API’s the UI and API integration will always be platform specific, meaning that for a future re-build, only the business logic can be re-used. Often, there can be a small delay in relevant new JavaScript plugins becoming available to make use of enhanced native features, which can again cause delays that would not occur with native development.

Native apps also offer great short-term benefits. With regards to functionality and UX, they generally develop into a better product as they can make use of more native device features and in turn provide a better user experience as well as more functionality from the start. For example, an app that requires access to a user’s camera will have to be developed natively, a feature that is very popular among app developers. User experience factors such as this can help secure adoption—which is key when considering long-term benefits. It’s worth remembering though that the more an app is adopted, the greater the need might be for future updates and improvements. After all, no one builds an app for it not to be downloaded, so future maintenance costs always have to be factored in from the start.

With regular software updates to both iOS and Android devices, it can be difficult to maintain optimal usability as requirements change. Considering that the code of a hybrid app requires updating across three layers, the HTML layer, the framework layer (e.g. Apache Cordova) and lastly the OS layer (Android & iOS), making changes and updates to a hybrid build after release can be a costly and time-consuming exercise, especially when testing and quality control are considered. It is also worth keeping in mind that most updates to operating systems include changes to the user interface (UI) which means that these have to be implemented across all platforms, irrespective of what an app might have originally been developed for, adding time back into the project. Given that the Android device world is very fragmented, all new releases will also need to be tested again across several devices, which again increases quality assurance costs.

When embarking on an app development project, it can be difficult to grasp the full scope of investment required to build, release and maintain an app. It’s therefore of utmost importance to consider all available options and focus on delivering a user-centric product that is functional and delivers, both for the user and the enterprise.

For more information on hybrid vs. native app development, read Mubaloo’s other blog posts on the subject:

Considerations for hybrid app development

Cordova vs Native apps