When a mobile app ceases to be the focus of development

Over the past few decades, software engineering has changed far more significantly than is generally noticed.

Most of these changes were not linked to the emergence of new programming languages or more powerful computing systems. Something else proved far more significant. The very object of engineering work has gradually changed. The history of engineering is the history of the changing object of development.

Once upon a time, developers managed memory manually; then higher-level compilers appeared. Later, operating systems freed engineers from the need to constantly work directly with hardware. Then virtualisation and cloud infrastructure made it unnecessary to set up a dedicated server environment for virtually every new project.

In all these cases, the same thing happened. Engineering gradually ceased to have to recreate the same foundation over and over again. What was considered an essential part of every new project yesterday eventually became a separate layer of engineering, existing independently of any specific product.

As I observed the development of mobile development, I found myself asking more and more often why this pattern is hardly evident here.

Today, virtually every new mobile platform for Android and iOS still begins as a separate engineering project. Despite differences in objectives, industries and users, a significant portion of its architecture is built from scratch. Interfaces, business logic and functionality may change, but the fundamental mechanisms of the mobile infrastructure are largely recreated from scratch.

But does the engineering foundation upon which they are built continue to emerge independently across thousands of projects?

At first, this question seemed to be a peculiarity specific to mobile development. However, the longer I reflected on it, the clearer it became that it concerns the very formulation of the engineering problem.

Perhaps we have for too long viewed the mobile application as the primary object of development, failing to notice that a significant part of the system we are creating relates not to the application at all, but to the infrastructure within which it exists.

If this assumption is correct, the following question arises: what would happen if the focus of engineering work were not on every new mobile app, but on the infrastructure itself within which these apps can emerge? It was precisely this question that became the starting point for my further research.

The longer I thought about this question, the less it seemed to relate solely to mobile development. It gradually became clear that mobile platforms are merely a special case of a more general engineering pattern.

Virtually every mature technology follows the same path. At first, engineers carry out similar tasks over and over again. Then tools emerge that allow them to do it more quickly. But the real shift in engineering capability comes later — when repetitive work ceases to be an essential part of every new project.

Therefore, progress cannot be measured solely by development speed, cost or the number of features. These metrics describe the consequences. The deeper change lies elsewhere.

Engineering systematically eliminates repetition

Compilers have eliminated the need to solve a multitude of low-level tasks from scratch each time. Operating systems have created a stable layer between the program and the hardware. Virtualization has made it possible to separate the computing environment from a specific server. Containerization has made deployment reproducible.

In all these cases, engineers have not simply learnt to do their previous work more quickly. They have changed the very structure of the task. What used to be repeated within each project has been moved to a separate engineering layer.

If we look at mobile development from this perspective, a contradiction arises. Thousands of teams are creating different products, yet a significant proportion of their efforts is directed towards replicating similar architectural mechanisms. Authorization, user management, content publishing, notifications, server communication, data storage, administration, and the building and support of mobile clients reappear in every new project.

Of course, the specific implementations differ. Requirements, security, load and business logic all vary. But the mere fact that there are differences does not mean that the entire infrastructure has to be built from scratch.

At this point, the question of mobile applications became something else for me: which part of the engineering work is truly unique, and which part is repeated simply because we have become accustomed to treating an application as a standalone development project? This question is important not only because of time or cost. Engineering ingenuity remains the technology sector’s primary limited resource.

Development time can be measured. The number of specialists can be increased. Computing power can be acquired. But the ability to devise new architectural solutions does not scale simply by increasing the size of the team.

And if a significant proportion of this intellectual resource is spent on independently reproducing already known designs, the problem extends beyond the efficiency of individual projects. It concerns how the industry allocates engineering intellect. Perhaps mobile platforms take so long to develop not because their development is poorly organized. Perhaps a significant proportion of this work should not be done from scratch at all.

Hypothesis

Any engineering observation sooner or later leads to a hypothesis. Mine turned out to be surprisingly simple. What if the mobile app had never been the main focus of development? At first glance, such a question seems strange. The user installs the app, works with it and evaluates it. It is therefore natural to regard the app as the end result of all the engineering work.

However, if we look at the process of creating the platform, a different picture emerges. Most of the developers’ efforts are focused not on creating a unique digital product, but on building the environment that makes the existence of that product possible. User roles, authorization mechanisms, data exchange, interaction between the mobile client and the server, admin panels, publishing systems, multimedia content management, notifications, and building apps for various platforms — all of this relates more to the infrastructure than to the app itself.

The application itself becomes merely one of the implementations of this infrastructure. If this is indeed the case, then the familiar logic of development is turned on its head. We believe we are creating a new mobile application, whereas in fact we spend a significant portion of our time building the infrastructure, which then remains hidden behind the user interface.

This led to a hypothesis. Perhaps the focus of engineering work should not be on each individual mobile platform, but on the infrastructure itself, within which such platforms can emerge independently of one another. If such an infrastructure is indeed capable of existing as a standalone engineering system, then creating a new app no longer means creating a new architecture. It becomes a process of deploying a new digital platform within an existing engineering environment.

It was at that very moment that I realised it was theoretically impossible to test this hypothesis. Neither architectural schematics, nor diagrams, nor patents are capable of confirming or refuting such an assumption. The only criterion could be practical application. Either the same infrastructure would prove capable of repeatedly giving rise to independent mobile platforms for various purposes, or the hypothesis would prove to be incorrect.

Practical Application

Any engineering hypothesis exists only until it is first put to the test in practice. It is practical application that distinguishes an architectural concept from an engineering principle. Therefore, the aim of my work was not to create yet another mobile platform. It was necessary to answer a much simpler question.

Is the same engineering infrastructure capable of repeatedly serving as the basis for independent mobile systems, whilst keeping its own architecture unchanged? The answer could not be obtained by creating a single successful application. It required repeated experimentation.

New mobile platforms were created for different industries, different models of user interaction and different application tasks. Use cases, interfaces, feature sets and subject areas changed. But the main focus of observation was by no means the application itself.

Infrastructure remained the primary focus of attention. Each new deployment answered just one question: does the engineering foundation remain a standalone system, regardless of the application that emerges within it?

Testing this hypothesis in practice, whilst deploying hundreds of independent mobile ecosystems, yielded an unexpected result. New mobile platforms were no longer perceived as standalone engineering projects. They increasingly resembled different implementations of the same infrastructure. This did not mean that the need to design the user experience, the domain or the business logic had disappeared. It was precisely these elements that continued to determine the value of each new product.

It was a different level that had changed. The architecture, which had previously been rebuilt from scratch with every application, was no longer part of a separate project. It came to exist independently. It was then that I realised that the initial hypothesis had not been formulated quite accurately. In fact, it was never about speeding up the development of mobile applications. It was about shifting the focus of engineering work to a different level.

When infrastructure becomes an independent engineering system, a new mobile app no longer simply means creating a new architecture. It becomes the creation of a new digital platform within an existing engineering environment. It is at this very moment that the engineering challenge begins to look completely different. It is no longer a question of «how to develop the next app more quickly». But « which part of this work actually needs to be repeated?»

Consequence

Any engineering hypothesis is valuable not in itself, but for the questions it prompts us to ask. If the focus of development is truly on infrastructure, rather than on each individual mobile application, it is not just the technology of software development that changes. The very logic of engineering work changes. A significant proportion of intellectual effort is no longer spent on repeatedly replicating the same architecture. Engineers are able to focus on what truly distinguishes one digital product from another: the subject area, user experience, algorithms, data and new models of interaction.

It is precisely these elements that determine an application’s value. Infrastructure merely creates the conditions for their emergence. The history of engineering shows that such changes are not unprecedented. At every stage of its development, engineering has shifted repetitive work to a higher level of organisation. This is precisely how compilers, operating systems, virtualisation and cloud platforms came into being. The tools changed each time, but one principle remained constant: engineering freed people from having to recreate what had already been created.

Mobile development may be approaching a similar turning point. If so, the main outcome will not be simply faster app development. The main outcome will be a shift in how we answer the question of exactly what we are developing.

Perhaps, in the future, a new mobile app will be viewed not as just another engineering project, but as a new digital system deployed within existing infrastructure. If this moment does indeed arrive, it will not be the speed of development that changes. What will change is the very object of development. And then the question « How do we create yet another mobile app?» will gradually give way to another: « Do we need to build it from scratch?»