Misconceptions About Developing Mobile Applications For Enterprise
By Nic Grange, CTO, Retriever Communications
In part one of this series, I looked at six misconceptions IT managers come across when running enterprise mobility projects. This article focuses on misconceptions about developing mobile applications for Enterprise.
1. It’s just like building a web application.
Simply because some mobile application development tools leverage skills such as HTML, CSS, and JavaScript doesn’t mean it will be as easy as building a web application. While web developers have had more focus on the mobile experience of their websites, there are additional constraints with mobile application development. These include:
- handling restrictions imposed by the Operating System
- being occasionally offline
- different application lifecycle
- running in the background
- having to interact with device peripherals
- dealing with different inputs types
- the rotation of the device.
2. Employees will naturally adopt the application.
Once you’ve finished building an application, you’ll want people to start using it straight away, and developers sometimes naively think this will be the easy part. The reality is, adopting a new application is like any change in the workplace — employees will need time to adapt to it and will need to see the benefits of using it before they embrace it. New applications often introduce new processes, which can be challenging for employees. The application needs to be at least as fast and easy to use as what they had before, otherwise the user is going to be tempted to revert back to what they had before.
3. We can build all apps in-house and save money.
In a few cases, building an application in-house is the right choice. But this is more often the exception rather than the rule. If you already have experienced mobile developers, testers, and user experience designers at your disposal — and the application needs to be a key differentiator to your competitors — then building in-house can be the right choice.
In most cases, it may not be the right choice or, at the very least, it will be part of the solution, not the entire solution. For most enterprises, the IT department will not be able to build enough applications quickly enough to meet all the needs of the business. Enterprises are likely to need a mixed approach of both in-house development and off-the-shelf applications.
4. We can make it just like the Facebook app.
Many people don’t realize the amount of effort, skill, and number people involved in developing some of the popular consumer applications. Companies like Facebook have large teams of developers, user experience designers, testers, and product managers continually updating their applications. Getting your application to have even a remotely similar user experience takes a lot of effort. It doesn’t mean you shouldn’t try, but you also need to be realistic based on your resources and experience.
5. Users will always have a good internet connection.
Even in this day and age, there are still many places with poor or no mobile internet coverage. As a consequence, there are a number of things you need to consider if you want your application to keep functioning during those times. Does your application need to cache data? Does it need to automatically retry if it doesn’t get a response from the server? What if it retries and the server got the original message, are you left with duplicate data? All of these need to be considered.
6. We can secure the application later on.
Once a solution is deployed, it is usually quite difficult to retroactively add security controls without major rework. It is better to consider how sensitive your data is and what security controls you will need to implement before the first version of your application is developed. How will your application authenticate and authorize your users? How will your application securely communicate with the server? Do you need to encrypt the data at rest? Do you need to do any auditing? Even if you don’t implement all these from the start, you’ll need to have a good idea of what you’ll do about them.
7. Having a BYOD policy means you don’t have to worry about which devices users bring.
Having a completely unrestricted BYOD can be a nightmare. Even if you have all the right tools — including a Mobile Device Management software and a development platform that supports almost all devices — some users are bound to bring in old phones which either are really slow or don’t have enough storage. Different devices may have different operating systems and different versions of those. Users may upgrade at different rates. You should consider having a core set of supported devices which have a minimum hardware specification and operating system version that you regularly test against.
8. Once we release it, we won’t need to update it often.
New operation system versions and new devices come out every few months. Just because your application works today doesn’t mean it will still work in a month’s time when your users automatically upgrade their operation system or buy the latest device.
You’ll need to plan in testing with beta releases of new operating systems and ensure any updates required are deployed before the official releases come out. Just testing it on Emulators isn’t enough, you need to have real devices and be testing it under realistic scenarios in order to have any confidence it will work.