Why is the issue of mobile app performance pushed aside by their creators? Why is the short path most frequently chosen with regard to developing a mobile application? Why does this path lead to enormous costs and, in consequence, hinder the software development process?
The topic might seem very extensive. It’s probably difficult to master it and pinpoint the most important aspects while planning mobile application programming processes. Over the last few years, I’ve worked on both large and small start-up projects. As a programmer with several years of experience under my belt, I would like to discuss a few problems related to the effectiveness of mobile applications and propose some solutions.
Table of contents:
Mobile App Performance – Black box
Let’s assume that an application is a black box. For now, let’s ignore the question of its category (games, business, education, lifestyle), as it’s not really important at this point. Moreover, let’s assume our application is written natively for a given mobile platform (e.g. iOS – Swift, Objective-C, Android – Java, Kotlin) with the use of the best software practices and project templates. I believe that if you’re considering software efficiency it’s pointless to go into the details of cross-platform solutions as e.g. Xamarin or hybrid ones using HTML5. That’s even if, in the case of simple software, we can assume that the efficiency of a solution based on Xamarin will be comparative to the native language.
I’m aware of the fact that I won’t be able to discuss all aspects of the efficiency of mobile applications and the factors shaping it. However, I’d like to focus on the most important ones.
Devices
The first and probably the most frequently forgotten factor concerns the devices themselves. Depending on the platform and version of available software, it’s useful to put together a list of devices on which the software will ultimately be installed.
Those devices not only determine the user interface and later ways of showing data, but mainly how particular software layers will operate on older mobile devices. These can include devices with worse units (weaker processor, less RAM). You should also consider the availability of the devices, especially those older ones. Most frequently, programmers use simulators, additionally one or two mobile devices. This should be a warning signal for testers to start their tests with the oldest devices.
Negligence can lead to an expensive rewriting of functionalities which operate incorrectly on particular devices due to efficiency reasons. In any case, this doesn’t justify the programmers, who often copy the wrong project templates out of laziness, and start the applications only on the newest devices – ones that deal with processing complicated operations without any problems. In such cases, we usually learn about efficiency-related inconveniencies from the final user.
Networking
Another point comprises networking and, in particular, when and how often the application uses the Internet connection. The most frequent errors directly affecting performance result from the app asking the server for data too often, or a bad structure of storing the data in cache. Here, the best solution turns out to be planning to generate data well, whenever it is necessary, and caching server answers.
Data-generating operations should be executed asynchronously – by not blocking the main thread, which is responsible for rendering the user interface. While downloading images, one should remember two things: to save them on the hard disk and about proper compression.
Moreover, it’s also worth ensuring that the application operates well offline, unless it’s not required in the specification included in the documentation. From my experience, problems sometimes occur due to a lack of explicit information that the application is to operate offline. Sometimes, re-developing an already complex application can be very risky, as this can generate additional errors (which are difficult to solve). I think that this problem concerns developing the layer of communication with the server in business more so than in games, which, as can be assumed, should operate offline. By ‘offline’ I also mean a poor Internet connection, such as 3G or EDGE, which isn’t always 100% sufficient.
We should also consider the effectiveness of the server’s communicative layer.
It’s particularly important when our application generates high traffic of questions regarding the server part. The problem can be further complicated due to e.g. audio or video streaming. Unfortunately, in this case, we don’t always have a direct impact through ongoing development. Nevertheless, I think it’s good to have this in mind as well.
Third parties
The third point involves the use of libraries of external companies. This has become very popular recently. Anyone who’s dealt with a large project that involved libraries which weren’t updated on an ongoing basis (especially the open source ones!) will know what I am talking about. They facilitate the development process and accelerate it, especially if they’re complex. They provide functionalities that would usually take a lot of time to be written by a programmer from scratch.
The development itself can be supported with additional devices. These can enable proper monitoring – of the efficiency of application, occurrences of breakdowns and an app’s sudden closing, or additional logging of application’s events. Such devices include e.g.: Fabric, Crashlytics, Flurry, HockeyApp, AppDynamics, New Relic. They should be added and used from the beginning of the project.
Summary
To sum up, we should remember that all elements listed herein make a whole and ultimately determine how the application is seen by the final user. The efficiency influences the user interface as well as their general feelings related to using the application. Therefore, we should not let them feel the need to immediately uninstall our newly developed software or, even worse, feel that they have an old phone and they should replace it.
What to know more about tools that can help you improve the effectiveness of your mobile apps. Read this post Time is Money – Web Application Performance for Business Success
