How to Bring an App Back to Life After Failed Development in Just a Month

It is a complete disaster: to invest much time and effort into an application that does not work properly in the end. So that is a rather common situation when we are asked to work on a software that needs to be “saved” — it crashes or does not start at all, registration does not work, or the database fails.

Once we were “rescuing” a mobile audio guide for traveling offline. The application consists of an offline map, built-in routes and excursions, a catalog of sights, an audio phrase book and contacts of touristic centers. Initially, the app was unstable — it “crashes” and the map did not even work offline, despite the fact that this was one of the main ideas of the whole application!

There is a rule in mobile app development: every application should be beneficial. That’s why we have developed an application rescue system. Let’s take a look into it from the example above.

Audit the app

The most important thing now is to quickly figure out what is wrong and what processes need to be fixed, first of all. To do this, we analyze the documentation, mockups and design and compare the results with the app code.

According to the results we create the test documentation, which takes into account all the functional requirements of the technical specifications. Test cases of usability and non-functional requirements to the mobile application are also added here. We tested the performance of the application and functionality with the new documentation.

Audit Results

The app came to us when the recently released version of iOS did not get it and “spit it out” on every occasion and fixing of some bugs led to the appearance of others:

1. Slow loading of images on the main screen. The photos were large, and the server did not have the functionality to resize them, so the loading was very slow. The slider worked only in automatic mode; if a user wanted to see the photo manually, some of the photos disappeared.
2. Memory problem. The application did not “clean” RAM: the user interacted with the app, loaded new screens, and the information about them was stored in the RAM of the gadget. As a result, each page weighed tens of megabytes, which led to an overload and shutdown of the app. This is one of the most complex and implicit bugs that often slips into release.
3. Offline maps problem. Buying a tour, a user gets the route and the audio recordings, which begin to play when a tourist approaches the sights. If a user has reloaded the application after loading the tour without the Internet connection, the map was not cached, showing just a black screen.
4. Slow operation of the map. Any map consists of several superimposed images, whose number depends on the scale of the map. Initially, the map could have been scaled to 12 times, but the developer has downloaded maps only for 5 of them and that slowed down the scaling.
5. Problem with the TestFairy library. TestFairy helped developers to track the “crashes”. That’s strange, but the library led to “crashes” itself. As a result, we replaced this library with Crashlytics. It helps to collect logs in case of irregular application drops in order to fix them.

The Salvation

When we found out the main reasons of the unstable operation of the app, we set to work.

Data Storage

The application had already been added to the AppStore, so the previously loaded user data should not have disappeared after our update at any cost. The storage structure was not bad, but when it was necessary to add new fields, it had to be changed. All problems with data storage were solved during the process of its changing — that helped us to prevent users from losing previously loaded data: locations, images, links in the database, etc.

Another issue that arose during the development process was the question of mandatory fields to fill in the databases. The structure was configured in such a way that all the fields were optional (the Swift development language was used), so we had to add a large number of checks for the presence of certain data.

Geolocation

The application needed an algorithm that would calculate the boundaries of the loaded area basing on the excursion places (markers on the map). We could have used data from ready-made services, for example, Google Maps, but if sightseeing places were only in the city center, then it was necessary to upload more data (see memory problem). Instead, we created an algorithm to calculate the most suitable loadable square on the map. This helped us to reduce the number of loaded tiles (tile is an information unit that is needed to draw a raster map with the vector data) to 5,000. For comparison: the number of tiles for the entire Rome is 12,000. The same algorithm limits the movement and scaling of the map within the loaded square.

Download Issue

In the previous version the data was loading progressively and as a result: when a user sent a request to the system, the download could be stopped by any error and you had to start all over again. We changed the download process beyond recognition to fix this issue:

1. All requests were executed progressively, but were independent of each other.
2. We added a check of the correctly downloaded data.
3. We fixed the full data load function. The user should not upload those excursions that he did not buy. He saw the information of unpurchased excursions without loading the route and the audio files.

All this allowed us to make the download faster and with fewer resources. We remembered that the user is abroad when using the application.

Random Crashes

The app used the TestFairy library to collecting statistics on critical errors. Strange as it may sound, it was one of the reasons why the application “crashed”. So we had to remove it. Then the question emerged: what service do we have to use now? We have chosen Crashlytics. It showed us the true cause of the problems — data storage issue. Having studied the problem in detail, we rewrote its logic and fixed the random app drops.

Result & About Us

The release of the updated application took place after a month of the restoration work. We continued to support the application and released several updates with new client ideas. The design of the app is presented on our Behance profile.

SimbirSoft is a modern IT-company, specialising in the implementation of end-to-end software & mobile development projects. Within 19 years, we have developed more than 620 IT solutions: enterprise automation systems, highly loaded systems, mobile applications, Machine Learning & Data Science solutions, embedded software.

Many international companies entrusted the complete development process to us. Today we collaborate with companies such as ABBYY, Burger King, Intland Software.

What do you know about UX and UI? We wrote a really simple article describing these two terms: What is UI/UX and What is the Difference

That’s why your foodtech business needs an app more than anything more & guide how to design in: Foodtech Secret Weapon: How to Develop a Useful Mobile App

Follow us on Medium! Never miss an article!