How can you update the architecture of a mobile app over time?

It is very important to assess your current architecture. You should be able to answer why you want to update your architecture, what the shortcomings or problems you are facing with the current approach, and how the newer approach will help you in dealing with these limitations. The best way of starting this assessment is writing test cases for your application and let's suppose your current architecture is very coupled, then the first issue you will face is that you will not be able to write properly optimized unit test cases. During the assessment, you should be taking notes of all the challenges you are facing currently, but at the same time, you should also note the pros this approach has, and whether you are willing to give that up.

Always updating the architecture to the latest and up-to-date isn't necessary. First, you have to understand your current architecture. Why it is like this and does this offer any flexibility? Sometimes old architectures like mvp, mvc, and viper help old codebase to operate easily with some legacy features. So before updating it understand what will be the best for your codebase to upgrade and what not. List them out and talk about them with all the developers who currently working on the project as they can give you some helpful insights.

Except there is a serious issue with the current architecture, I will not advise this for a large project as it might lead to unexpected complications, rather, new modules can be built using a new architecture, a real-life case will be where SwiftUI with a different architecture needs to be implemented in an existing project that uses UIkit. if there is a need for it, i will advise it should be done in the following ways: Set clear and achievable goals. Evaluate Current Architecture. Make Incremental Changes using new Architecture Modularization Do extensive Testing. Create Documentations. Do Code Reviews.

To evolve a mobile app's architecture over time, employ continuous assessment, modular design, and version control. Implement CI/CD pipelines for automated testing and deployment, ensuring efficient updates. Maintain backward compatibility, prioritize user feedback, and conduct security audits regularly. Document the codebase comprehensively, optimize for performance, and adapt to platform changes promptly. These practices create a flexible, resilient architecture, allowing the app to meet evolving user expectations and industry standards seamlessly.

If you want to update the architecture of the existing app please keep in mind the SOLID principles. If you app is already following these principles there will be no problem. If you want to shift you architecture for example from MVC to MVVM or MVVM Clean architecture it is not recommended but still you can do it by carefully following the guidelines and adding ViewModel Layer and removing controllers.

We can say that “MVVM” is a framework, but not in a terms of software framework (like Android framework) MV(x) pattern is not architecture - it’s design patterns promoting separation of concerns between UI and rest of the code. Good starting point is clean architecture - you don’t need to introduce every layer at once, but it’s worth to separate business logic from software framework, database and UI.

MVVM (Model-View-ViewModel), MVC (Model-View-Controller), and similar acronyms are not frameworks themselves but architectural design patterns. These patterns provide a way to organize code and structure the relationships between components in an application. These patterns guide developers on how to organize code for better maintainability, scalability, and testability. While they are not frameworks themselves, developers often implement these patterns using various frameworks, libraries, and tools in different programming languages. Frameworks like Angular, React, or SwiftUI provide tools and utilities that align with these design patterns, making it easier for developers to implement them in their applications.

While choosing the framework try to understand the problems the current architecture has and then select the framework which solves it best. The team's opinion is also to be taken into account as selecting a very complex architecture which the whole team does not understand does more harm than good.

These are design patterns and not frameworks. Choosing a framework should not be based on what’s hot this week, but what can be easily understood, developed on, supported and hired for.

Framework is for implementation purpose. System Design should be compatible with any framework. Low level design should consider framework

While the primary goal of refactoring is to enhance the internal structure of the code, the ripple effect often extends to the user experience. Cleaner, more efficient code can lead to improved app responsiveness, faster loading times, and an overall smoother user interaction. As your mobile app evolves, scalability becomes a crucial factor. Refactoring allows you to anticipate future growth and scale your application without compromising performance or introducing technical debt.

Business layer refraction or Presentation layer refraction matters most. Generic solution should be adopted which supports both Android or iOS apps. UI component library should be developed and should be reused at enterprise level

Modularization is an option, not a must. Since in Kotlin we don't have package-level visibility for classes, we rely on Gradle modules to introduce stronger separations of concerns. There are very few cases where teams will benefit from supposed "reusability" of app modules. If you absolutely need to introduce modules, create :domain module where your core business logic will reside. Domain will include entities, use cases, interfaces for repositories and abstractions for other services. Domain of course should be framework-agnostic and contain little to none 3rd party dependencies.

This is one of the most trickiest thing to implement. You have to make sure the level of modularisation is chosen carefully otherwise this is a very good candidate of over-engineering.

Loose coupling and tight cohesion is the fundamental principle should be followed while defining modularization. SRP should be followed strictly

This should be the first step. And it’s not negotiable. Having test suite (even very simple) is a must if you’re doing any kind of refactor or rewrite. Also it’s worth to mention that CI/CD scripts are not dependent on architecture.

In a CI/CD system for mobile applications, Jenkins automates the build, test, and deployment process: It detects changes in the code repository, executes tests and quality analysis, and then deploys the app in test or production environments, all in an automated and continuous manner.

Use tools such as New Relic, Sentry, Firebase Performance Monitoring, or AppDynamics to monitor your application's performance in real time. These tools can help you identify bottlenecks, performance issues, and areas for optimization.

Don’t try to change everything all at once. Refactor only the parts you actually need to adapt to the new architecture as you update the features and requirements. Remember to add good tests that will help you check if things still work the way they did before the refactor.

You shouldn't update architecture for the sake of updating architecture. The first and most important question is: why you want to change something? Maybe... It's hard to onboard new team members? It's hard to introduce new features? It's hard to write tests? It's hard to debug? Changing mobile app architecture is not a first thing you should do when fighting legacy systems. Assess all of your development processes. Conduct event storming session. Brainstorm ideas with your team. Understand how mobile app impacts affects your business. DDD practices are not popular in mobile dev world, but they are damn useful.

Every time you have to make a shift in the current app architecture, you must address a phased plan that works with the current delivery of new features. Many businesses don't want to wait years to get a v2.0 of their application, so you have to be creative: work in a strong app foundation and start delivering substantial changes, without delaying the app feature delivery cadence. To achieve this, you must get strong support from your stakeholders by showing the organization the advantages of moving to a better app architecture: faster delivery rate, better feature delivery manager, less work per feature or a combination of all three. Getting the right people for this kind of complex projects is essential.

Integrate Emerging Technologies Stay abreast of new technologies and frameworks that can enhance your app's performance, security, and user experience. Integrate emerging technologies strategically, ensuring compatibility with your existing architecture. Examples include adopting blockchain for secure transactions or incorporating machine learning for personalized features.

Step '0' is to consider 'who' should do the work versus 'how' to do it. Determine scope of transformation/renovations and then figure out WHO will do the work. If it is a major renovation then go with an 'Architect'. If it is minor, then a Developer can handle. There are people who can do both and that is fine. However, it is not something that can be assumed. The steps listed here are fine. I would add to start though 1. Determine the 'who' 2. Consider if Update is part of a larger transformation or isolated update. 3. Ensure Graphical Designs are done by a Designer. Similar to above, don't try to make Developers do design work unless it is in their skill set. 3. Set both milestones and constraints 4. Proceed with steps listed here.