The debate between web and mobile apps continues, and the right choice will vary for different organisations.
However, many organisations will want to have both in some measure. Unfortunately, there are more differences between these two types of app than many are aware when trying to convert from one to the other. CBR rounds up some key tips for managing the leap from web app to mobile.
1. Permissions and data
One of the key things that the mobile platform brings to applications is the vast amount of data available. When an app is downloaded, the user is presented with a range of requests for permissions, which can include access to the user’s location, camera, microphone and contact book.
Since web apps have less information available, the amount of personalisation they can achieve is reduced. A successful app for a phone will use the features of the device to serve up services specific to the user.
When building the native app the developer should assess what metadata can be used to enhance the functionality of the app. The mobile app also offers the possibility to introduce an offline mode, so that the user can make changes and work in the app even when not connected to the internet. These changes are stored until the user can reconnect.
2. Security
Native mobile applications are able to store data on the mobile device, rather than just in the cloud. However, this adds an additional security weakness into the mix: that data is vulnerable to the device being lost or stolen.
Particularly when it comes to corporate apps that handle and store sensitive data, it is important to ensure that the app’s data is protected on the device. This could involve sandboxing the data.
It might also involve using encryption to ensure that any data created can only be accessed from the app in question.
3. User experience
Building a mobile app means more than simply porting a desktop experience onto a smaller screen. Mobile devices are generally viewed as much more personal than a desktop, due to the fact that people don’t generally share them and they are kept close to the person.
This makes people somewhat more protective of what they put onto their mobile device. This means that user experience is much more important to the users, who are likely to respond to a shoddy app by removing it from the device altogether. As Paul Swaddle, CEO of Pocket Apps, noted in a CBR interview, people are more put off by poor design than poor functionality with mobile apps.
When moving a web app onto a device, this consideration should be paramount. A sleek, visually appealing and uncomplicated app which takes into account the parameters of the device will be far more likely to be successful.
4. Deployment
At some point the mobile app will have to actually be downloaded onto the device. If this is a consumer-facing app this is a relatively simple decision: put the app onto the App Store or Play Store for download.
With an internal enterprise app, designed for employees there are several options for how the app can be installed onto the employees’ device.
One possibility is manual provision, which is particularly suitable when the organisation is distributing devices to employees to use (corporate owned, personally enabled). The IT department can simply directly load the app onto all necessary devices.
In a bring your own device situation, some businesses are opting for an enterprise app store, which provides employees with a direct channel for downloading corporate-approved apps. Employees get more choice this way and don’t need to relinquish their device to the IT department.
Managed applications with remote installations can be effective as no user action is required. By using an enterprise mobility management solution, necessary apps can be remotely installed and updates can be managed on the user’s device.
There is no right answer and a different method will suit different situations, but how the application will be deployed is a key consideration when moving from web app to mobile.
5. Streamlined features
Realising that a mobile version of the app will not be able to do everything is key when managing this transition. The trick is to strip the app down to the core things that it needs to be able to do, and then reproduce these rather than try to simply build a mobile replica of the web app.
It is better to have a mobile app that does a few things well and leave the more complex and heavy duty functionality for when the user is able to access the full web app.
Otherwise, if they find obstacles between themselves and the most important functions they may end up simply not using the mobile app at all.
