Story of Eight Years Without Updates

For me, this story began when I met the app owner - a vibrant young individual who passionately and proudly shared about their venture. Their brainchild, an educational game for kids, has become popular, with over 15,000 young users playing it daily. Over the course of eight years, they have fostered a large customer base, which now fuels a parallel endeavor - a toy store chain where parents can purchase the beloved game characters for their kids.

He approached our company seeking a developer to assume app maintenance responsibilities after their specialist's departure. They also brought up some minor technical issues and outlined their vision for the game's future development. The discussion left me with a sense of positivity and optimism, and I was completely unprepared for what I would encounter once I delved into the project.

It became evident that the app, which hadn't received a single update, had become so obsolete that even the slightest of existing issues appeared overwhelming. This article revolves around the reflections that occupied my mind while preparing for the next client meeting. Here, I describe what an outdated app looks like from the inside, despite its outward appearance of stability, and outline the possible measures developers can undertake to address this situation.

Compatibility Issues With New Devices

Even during the preparatory stage, an unforeseen surprise awaited me when attempting to set up the developers' coding tools, known as the development environment. Much to my astonishment, some of the necessary tools were so outdated that they were nowhere to be found online. What a twist of fate - I couldn't even start working! Thankfully, after investing time in studying the project's past, I managed to find replacements for the missing tools.

The first issue I dealt with was a minor bug that caused a black border to appear around the edges on devices with bigger screens. This happened because the application couldn't enlarge the image to the necessary dimensions.

The origin of the problem was identified as an outdated main tool used to create the game. This tool, known as a library in developer terms, is essentially a collection of pre-build interactive images intended for integration into web pages. These images are commonly found in browser games, representing playable characters and objects that users can control within their web browsers. Eight years ago, this library couldn't scale images to fit the screen size of a particular mobile phone, and it hasn't been updated in the app since then, posing significant application modernization challenges. Replacing it with a new version eight years later is akin to adding an eighth floor to a one-story building. In fact, it would require reworking nearly all of the code.

But why wasn't the application updated? After all, the client had a dedicated specialist to maintain it. It is currently a puzzle, so let's delve further.

App Architecture Issues

Alright, the border on some devices may be a minor detail. There are more important matters to address, such as monetization. The application has been offered for free, but the owner now intends to introduce a paid subscription model. As I analyzed the code, I discovered previous developers' unsuccessful attempts to implement this feature. It soon became apparent that I wouldn't be able to achieve it either.

The reason behind this is the unconventional architecture that resembles a mobile application designed for browsing websites. Instead of storing the game locally on the mobile device, it is stored remotely in cloud storage. What is installed on the phone is essentially a specialized browser that can run web pages within the mobile application. Upon each launch, the game, akin to web content, is loaded into this browser from the cloud storage.

Therefore, the game has no connection to the user's mobile device and cannot receive any information from it, making essential tasks like saving game progress unattainable. As a result, meeting the client's desire for game progress saving becomes impossible, leaving children with no choice but to initiate the game anew with each play session. Integrating monetization mechanisms within the application is impossible for the same reason.

Another mystery arises - why did the application creator choose such a peculiar architecture? I would speculate that their background resided in web development, rather than mobile games. Therefore, they designed the game to mirror a website, essentially creating a browser game.

App Extending Issues

How about the client's remaining requests? They have extensive plans to improve the game. And once again, the code reveals evidence that my predecessors have made repeated attempts to fulfill these objectives, albeit with minimal success.

The application is quite simple. Within it, a child encounters a rabbit who presents them with three mini-games to choose from. Clearly, the owner had envisioned this as just the starting point. The intention was to gradually introduce new games over time, creating a gaming world for the child to explore, and allowing progress to be saved. Multiple such gaming worlds were planned. However, the only modifications made to the app since its release have been the inclusion of a few additional characters alongside the rabbit, who offer the child the same three mini-games with slight design variations.

It is now quite evident how this came to be. The library used to develop the game simply lacks the required functionalities. After all, browser games tend to be quite basic. In fact, even creating the original version of the game with the rabbit character was beyond the capabilities of this library. The reason behind the lack of app updates throughout this time becomes clear.

To make the rabbit appear realistic, it needs to move as if it is governed by the laws of physics. Typically, mobile game developers rely on pre-built sets of algorithms, known as game engines, that offer various character movement functionalities. However, the library used by the game's creator lacks these capabilities. Consequently, they made the decision to develop their own makeshift game engine.

This endeavor is unlikely to be deemed successful. It undoubtedly consumed a significant amount of time. The development of the application took 2 years, while such mobile games are typically developed within 4-5 months. Moreover, the capabilities of the custom game engine were inevitably quite limited. Specifically, it was tailored for a certain version of that foundational library. If the library were to be updated, the game engine would simply stop working.

Furthermore, this game engine lacked any description that future developers could refer to understand its workings. What could they do in such circumstances? Any alteration in the code would demand extraordinary efforts and could potentially break down the entire structure. For example, adding a butterfly to the rabbit would necessitate clairvoyant skills to determine the precise location in the code to replace the rabbit's jumping algorithm with the butterfly's fluttering algorithm. Moreover, they would have to develop the fluttering algorithm themselves, essentially attaching another patch to the already existing workaround.

So, What Are the Options?

As expected, the conversation with the client was not easy. I presented two options to address this situation.

1. The first one is to allocate all efforts to rescue the project. This would involve comprehending the functioning of the custom game engine and proceeding with cautious app modernization. This would require a team and an indefinite amount of time. Even with a favorable outcome (which cannot be guaranteed), the functionality of the application would remain severely limited. Enhancements such as saving game progress would still be impossible.
2. The second option is to provide minimal maintenance for the application by resolving critical bugs, while simultaneously starting the development of a new version based on a full-fledged game engine. This would necessitate a team and 4 months of time. Subsequently, we would have an identical copy of the current application but in an ideal technical state and with limitless potential for development. The team would then be able to fulfill any future owner's requests.

The client has given consent to proceed with the second option. I must give them credit for their ability to confront the situation, as it is not easy to transition from perceiving the issues as minor to realizing that everything is on the verge of collapse. It is also challenging to let go of an application that has required a significant investment of time and resources. However, this entrepreneur chose not to ignore reality and made the difficult but necessary choice. It is worth mentioning that such cases are quite rare. Often, owners insist on continued maintenance, regardless of how outdated the application has become.

However, this is not the end of the story. Before the team could fully engage in their work, something unexpected happened.

Compliance and Confidentiality Issues

In April 2023, Google released an update to its privacy policy, leading to the removal of the application from the Play Store due to non-compliance with the new requirements. Google's primary concern was the application's practice of loading unknown content from cloud storage, which was subsequently accessed by children. It raises suspicion, wouldn't you say? Moreover, Google discovered numerous deficiencies in the application, to the extent that it would have taken me an entire day just to read through the list of recommended changes. It was clear that I was unable to address these issues.

That is exactly what I meant when I was explaining to the client that, given the current state of the application, there was a potential for losing it at any moment. It was a severe blow. The client's most precious asset, the customer base that had been nurtured over the years, was now in jeopardy. A significant portion of the 15,000 children who played the game daily would inevitably be lost as users during the 4-month period it would take to develop the new game.

Conclusions

As a developer, I can state that the unfavorable fate of this application was predestined when its creator decided to base it on an unsuitable technology. It became increasingly difficult to prevent the ensuing chain of events that further deteriorated the situation.

Yet, there is something else that I would like to say. The most astonishing aspect of this story is the sharp contrast between the app's dire condition and the owner's optimism. The long-standing problems failed to alert him or prompt him to take a more serious approach when choosing the people he entrusts with the technical side of his business.

The analogy with an airplane comes to mind. Picture a plane soaring high in the sky, passengers inside with smiles on their faces. Can you imagine that the pilot has no clue what to do and is attempting to invent something on the fly? And the navigator always has a roll of duct tape and a parachute ready? Fortunately, no lives or physical well-being were put at risk in this project. But what about the owner's future prospects and the established customer relationships?

An airplane won't take off until every screw in its engine is checked and the entire staff goes through a rigorous selection process. What I think is needed to make such stories impossible is having an equal concern for the technical condition of an application and people on whom it depends.