The development of a business app poses many challenges for companies. In a volatile market such as that for mobile applications, it is essential to make the right, forward-looking decisions regarding the support of operating systems and development tools, while not losing sight of the target group. The following eight aspects should be considered by companies in any case.
1. mobile platforms supported
The first and most important decision that companies should make before developing a mobile business app is which platforms the application should run on. This decision has an immediate impact on all further decisions regarding the user experience of the application, the development platforms, speed and cost, and future deployment scenarios. If the application is to run on only one or a maximum of two target platforms and the application itself covers a limited or fixed range of functions, native development per platform is a sensible option. Development costs and speed are usually better in this case.
In addition, the UI can be tailored specifically to the platform, hardware-related functions are easier to integrate and performance issues are easier to solve. The more variable or larger the range of functions is or should be, e.g. to implement different individual customer scenarios or a large number of functions over time, the more worthwhile it is to rely on platform-independent development.
Of course, this also applies if the application must be made available on many platforms. Here, the initial costs are usually higher than for purely native development, but this changes over time, since new functions should ideally only be developed once for all platforms. Since business applications, in contrast to consumer apps, usually have a significantly longer runtime, platform-independent development is also advantageous here. It offers investment security, both for the developer and for the customer, since porting to new platforms is usually faster and more cost-effective.
2. hybrid versus web-based app
There are essentially two options available for platform-independent development: On the one hand, there are hybrid systems in which the actual application runs in a native container that provides access to operating system functions. These have to be written for each platform, while the actual application is created in a platform-independent language.
Here Cordova/PhoneGap takes a leading position with JavaScript as development language and HTML for the UI. Meanwhile, there is a very promising new approach with React Native from Facebook, where the UI is rendered natively, but nevertheless large parts (including the UI) can be implemented in JavaScript. This approach offers the best of both worlds. On the other side are the pure web apps, which run without a native container in the browser and use its limited functions to access the operating system.
This is a good choice for simple applications without much offline capability. There are no problems with the deployment and update of applications. Today’s modern browsers, even on mobile devices, are powerful enough to display even more complex UIs with high performance. Meanwhile it is also possible to access important operating system related functions via browser, such as camera or geo-coordinates. Limited possibilities for caching data for offline cases are also no longer a problem. In addition to these two variants, platforms are also available where development is done in a programming language and the executable code is compiled by the platform for the respective target operating system.
Xamarin, which was purchased by Microsoft at the beginning of 2016, is one of the most prominent representatives here. Although this form of platform-independent development has many advantages, it has not yet become as widely accepted as Cordova. In most cases, the possibilities to write the UI platform-independently are limited. Furthermore, one is strongly dependent on the provider. This can lead to a lack of support, especially when new platforms emerge.
3. future security of the development systems
When developing native apps, the question of sustainability does not really arise, since development systems of the manufacturers are used. However, companies must have developers with the appropriate know-how for each individual platform (Objective C for iOS, Java for Android and C# for Windows). Development systems in the area of web and hybrid development are manifold. Large parts of (basic) libraries are available open source. This means both a curse and a blessing at the same time, since on the one hand the selection is difficult to keep track of, but on the other hand it allows to find the optimal tool and adapt it to one’s own needs.
JavaScript and HTML5 as a standard on the web offer high sustainability and investment security in development. Knowledge can easily be shared for classic web applications as well as mobile. Development artifacts can be reused across applications. Currently, however, there is still a high dynamic in the entire development infrastructure according to the motto: “Yesterday Angular was the framework of choice, today it is React and tomorrow there will be something new again”. Tools and libraries are therefore in part not yet mature and stable. It is therefore advisable to adopt a rather conservative strategy when developing business apps and wait until the hype cycle moves in the direction of the path to enlightenment. Otherwise, there is the danger of becoming dependent on manufacturers if you rely on integrated environments and frameworks.
4. development costs
With purely native development, companies can expect the lowest costs initially and immediately achieve high productivity. However, the more platforms are supported, the higher the cost of resources in terms of the number of developers and their recruitment and training. With a cross-platform approach, this effort for the development of different platforms can be reduced, but this also depends very much on the complexity of the application and the requirements for reuse. If they are correspondingly high, the effort and costs increase with a JavaScript/HTML5 approach.
Especially the initial research effort should not be underestimated by companies with complex requirements. The big showstopper at Xamarin in the past was the high costs per developer and year. Now that Microsoft is making the framework available free of charge after the takeover, it is likely to become much more popular in the future. In all cases, companies should try to go productive quickly with a small range of functions in order to incorporate feedback from the target group into further development as early as possible.
5. security
The protection of sensitive data on mobile devices outside a corporate network should play an important role in the development of business apps. The mobile device itself and the data transfer between the device and the server must be secured accordingly. The data transfer between the end device and the server should be encrypted.
Authentication with the server should be carried out using appropriate methods, such as a token-based procedure, so that it is not necessary to store passwords on the mobile client. In this context, the usability of the security concept should also be taken into account. If each data comparison with the server requires several minutes of authentication by the user, the application will meet with little acceptance. MDM solutions can also help here, which usually bring their own security containers and also offer the possibility of separating the business application and data from the user’s personal data.
During development, it is therefore advisable to check early on whether the application can be made available via MDM solutions, especially with regard to the security aspect. Since there are many providers on the market, it should be ensured that operation in such an environment is basically possible.
If a purely local protection of the application is necessary, it should ideally be done by means of the respective operating system, for example a biometric fingerprint comparison. Even if these do not represent one hundred percent security, they allow a high level of protection in combination with ease of use.
6. offline capability
In many customer scenarios, the offline capability of business apps is still essential. In industries such as the mobile deployment of service technicians, apps must also work in places without a mobile network, e.g. in the basement or elevator shaft. The amount of data that can be stored in a web browser is usually limited to a few megabytes and is therefore not suitable if large amounts of data have to be kept offline.
However, the offline capability of the application significantly increases its complexity, as it requires suitable interfaces and protocols for data exchange and access. However, a large proportion of (standard) libraries are designed for online data exchange only. Therefore, when developing offline-capable apps, companies should consider the additional effort involved in synchronization and data storage.
7. user orientation
The success of a business app stands and falls with user acceptance. An appealing, intuitive user interface plays a major role in this. Therefore, companies should involve end users as early as possible in the development process. Tests with end users on the basis of (click) prototypes are a suitable means of verifying and refining UI and UX concepts at an early stage.
To measure and improve the acceptance of the app directly with the users, it is worth considering the use of user feedback tools such as Helpshift or Apptentive. Live messaging with end users, automated surveys, tracking of specific functions, FAQs and dashboards can help to increase the quality of the app and thus user satisfaction in the long term.
Applications in the business environment are often essential tools for the end user. Regulations, such as those governing work at the computer workstation, must often be observed and the diversity of user groups must be taken into account. A classic example is the use of different “UI themes” (light/dark) or the possibility for the user to change font sizes himself. Integration or support of such functions via the standard means of the respective operating system should be the preferred way.
If the target group is very heterogeneous, it is also advisable to provide different UI workflows that can be adjusted by the end user. For power users, for example, wiping gestures for actions can be provided, while occasional users require a workflow that is more strongly guided by the application. Feedback tools can be used to automatically evaluate how such different concepts are used.
8. deployment and updates
The provision of the business app is primarily oriented towards the target group for which companies can provide unlimited or limited public access or only internal access. Public distribution via Apple’s App Store, Google Play Store or Windows Store requires a certification process that can take up to two weeks. This makes it difficult for companies to quickly provide updates for bug fixes or new features.
A
pplications based on JavaScript/HTML5, however, allow updates to bypass the app store and thus also allow individualized updates, for example for key users to test new functions and simplifies the development and rollout of customized versions. In the case of hybrid apps, the rollout and updates of the native part (container) to the end devices in the company itself must be performed either manually or via an MDM system. The actual application in the form of JavaScript code can then be automatically updated via hot code push. In order to use a business app on iOS, a company also requires an Apple Enterprise Certificate.
Conclusion
The successful development of a business app requires a precise analysis of the target group and requirements in advance, in order to then make the right decisions regarding development technologies and UI concepts. In addition to sufficient time to evaluate and test different concepts during development, continuous integration of end users is a key to success. Via prototypes, (automated) feedback channels and key user versions, a high level of user acceptance can be achieved and thus also indirectly contribute to customer satisfaction, e.g. in the service process.