Web vs Native Applications

We are looking into replacing some operations tool and we have been questioning whether this should be a web application (as it is now) or a native application. For this I did some investigation and made a clear comparison between the advantages and disadvantages of each solution. The application we have could actually be split up in two parts, one for the operations and a more advanced for diagnostics. This was key in my investigation as both serve a different audience.

My analysis is of course focused on this purpose and on the situation in which this application has to run. This may not be applicable for your situation, but I hope that my explanation and arguments are clear enough so you can filter out which ones are relevant for you.

First part of the analysis was an objective comparison of a web application with a native application. This will also include completely irrelevant advantages of disadvantages for the application, but those can be stressed or removed later.

Web Application:

+ Is accessible from every location by using a simple web browser.
– Requires a web server.
– Requires Web (HTTP) API.

Native Application:

– Requires the application to be installed.
+ Can use different types of API.
+ Does not need a web browser.
+ Does not need a web server.

Another difference is the used technology. This is important as using a new technology will have a learning curve and you will need new skilled employees, or train your existing ones.

In my case we had some hard constraints, as we are dealing with machines that have limited CPU and memory. The operations tool has to be running on these devices, whereas the diagnostics tool is more for maintenance and investigation of problems. There is no need that this should be running on the device itself and having it on a laptop is good enough. This made splitting the application a viable option, and this allowed for a more detailed analysis, especially because limitations or requirements for one are not there for the other. Whether or not this application will really be split up has yet to be determined (and is also not the point of this analysis), but it is important to be open to the possibility.

Diagnostics Tool:

Web Native
+ Is accessible from every location by using a web browser. – Required an application to be installed.
– Requires a web server running on the device. + Does not require a web server running on the device.
– Can not use the existing API. + Can use the existing API.

In my opinion the native application has a big win here, as it is not ideal to have a web server running on the device, nor is it to create a whole new API. The fact that the tool needs to be installed on your laptop is only a minor problem and once it is installed you never really have to think about it again. What could be a problem is when you want to debug it remotely with VPN and other things. The application should be tested to verify whether all of these special access works.

Operations:

Web Native
– Requires a web browser on the device. + Does not require a web browser on the device.
+ Does not require any changes, because a browser is installed by default. – Requires the application to be installed on the device.
– Requires a web server running on the device. + Does not require a web server on the device.
– Can’t use the existing API. + Can use the existing API.

Again the native application gets the win, mainly because of the possible much lower memory and CPU requirements. This is however not guaranteed and should be taken into account when creating the application. But I doubt it will be worse then having a web browser (which often requires 400MB of memory) to simply show a single menu.

Switching to the native application will however mean that you need to create a new install procedure as this application needs to become part of each new device. This is a small, but important change. If you have to manually install this application on each device it will be a huge cost as the production scales up.

My recommendation in this case is to have both of them as a native application. This is the complete opposite of what we have now, but it will decrease the load on the device a lot. It will involve a bit more work, but in the long term it will be worth it.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s