Должна ли каждая нативная мобильная платформа быть отдельным инженерным проектом?

За последние пять лет в ходе разработки международного некоммерческого проекта передо мной постепенно возник один инженерный вопрос.

Почти каждая новая нативная мобильная платформа для iOS и Android по-прежнему создаётся как самостоятельный инженерный проект, хотя значительная часть её архитектуры снова и снова воспроизводится практически без изменений.

Это заставило меня задуматься: не пытаемся ли мы оптимизировать не ту задачу? Вместо того, чтобы постоянно ускорять разработку каждой новой платформы, возможно, следует сделать воспроизводимой саму инженерную архитектуру.

Этот вопрос не был исходной целью. Он возник постепенно в процессе решения практических задач. Создавая разные мобильные платформы, я вновь и вновь замечал одну и ту же закономерность: менялись назначение продукта, бизнес-логика и пользовательская аудитория, но значительная часть архитектуры оставалась неизменной. Со временем стало ясно, что повторяются не отдельные технические решения, а сама архитектурная модель.

Мы не пытались создать новую технологию. Мы просто решали практические задачи. Лишь спустя несколько лет стало понятно, что результатом этой работы стал новый инженерный подход. Появилась инженерная архитектура, позволяющая развёртывать независимые нативные готовые к работе мобильные платформы и цифровые экосистемы для Android и iOS непосредственно на серверной инфраструктуре заказчика в течение 24 часов.

Её принципиальное отличие в том, что технология впервые позволяет неограниченное число раз передавать, масштабировать и развёртывать саму инженерную основу без её повторной разработки с нуля. Позднее этот подход получил название Rezvov Mobile Software.

Архитектура защищена международными патентами, действует международная заявка PCT, а её практическая реализуемость подтверждена более чем 250 опубликованными в App Store и Google Play нативными мобильными приложениями, социальными сетями и социальными бизнес платформами. Некоторые примеры реализованных проектов >>

Важно пояснить, чем это не является. Это не low-code, не no-code, не кроссплатформенный фреймворк, не конструктор мобильных приложений и не Backend-as-a-Service. Он не автоматизирует написание кода. Его задача — сделать воспроизводимой саму инженерную архитектуру независимой нативной мобильной платформы.

Однако главным результатом этой работы я считаю не саму технологию. Главным результатом стал вопрос, который она поставила.

Если архитектура независимой нативной мобильной платформы может быть воспроизводимой, означает ли это, что начинает меняться сам объект инженерной работы?

Должны ли мы и дальше создавать каждую новую мобильную платформу как отдельный проект, если появилась возможность тиражировать её архитектуру?

Технология уже существует. Поэтому главный вопрос заключается уже не в том, возможно ли это сделать, а в том, какие инженерные последствия будет иметь тот факт, что архитектура независимой нативной мобильной платформы впервые стала воспроизводимой.

Мне было бы искренне важно узнать, как на этот вопрос смотрят инженеры, занимающиеся мобильными платформами, архитектурой программных систем и инфраструктурными технологиями.