Should every native mobile platform be a separate engineering project?

Over the past five years, whilst working on an international non-profit project, a particular engineering question has gradually come to the fore.

Almost every new native mobile platform for iOS and Android is still created as a standalone engineering project, even though a significant portion of its architecture is replicated time and time again with virtually no changes.

This got me thinking: are we trying to optimise the wrong problem? Instead of constantly speeding up the development of each new platform, perhaps we should make the engineering architecture itself reusable.

This question was not the original objective. It arose gradually as I tackled practical challenges. Whilst developing various mobile platforms, I noticed the same pattern time and time again: the product’s purpose, business logic and user base would change, but a significant part of the architecture remained unchanged. Over time, it became clear that it was not individual technical solutions that were repeating themselves, but the architectural model itself.

We weren’t trying to create a new technology. We were simply solving practical problems. It was only several years later that it became clear that this work had resulted in a new engineering approach. An engineering architecture emerged that enables the deployment of independent, native, ready-to-use mobile platforms and digital ecosystems for Android and iOS directly on the client’s server infrastructure within 24 hours.

Its fundamental distinction lies in the fact that, for the first time, the technology allows the engineering framework itself to be transferred, scaled and deployed an unlimited number of times without having to redevelop it from scratch. This approach was later named Rezvov Mobile Software.

The architecture is protected by international patents, an international PCT application is pending, and its practical feasibility has been confirmed by more than 250 native mobile apps, social networks and social business platforms published on the App Store and Google Play. Some examples of realized projects >>

It is important to clarify what this is not. It is not low-code, not no-code, not a cross-platform framework, not a mobile app builder and not Backend-as-a-Service. It does not automate code writing. Its purpose is to make the engineering architecture of an independent native mobile platform itself reproducible.

However, I believe that the main outcome of this work is not the technology itself. The main outcome was the question it raised.

If the architecture of an independent native mobile platform can be replicated, does this mean that the very nature of the engineering task is beginning to change?

Should we continue to develop each new mobile platform as a separate project, now that it is possible to replicate its architecture?