What are the 3 principles of Mobile architecture
- DRY principle
- Separation of concerns principle
- SOLID Principle
What is DRY?
Don’t Repeat Yourself
Explain Separation of concerns
It improves readability, facilitates testing, and enables teams to evolve features independently.
What are the SOLID principles?
Five core ideas that guide design of flexible and maintainable object-oriented systems.
What are the five SOLID principles?
How is a layered architecture in mobile?
What characteristics has the Domain Layer?
This layer is the most isolated and platform-independent part of the architecture.
Not includes:
- Doesn’t know where the data comes from (local database or remote server)
The responsibilities include:
- Encapsulating business logic in use cases or interactors.
- Defining domain models.
- Coordinating flows and outcomes between UI and data layers.
What are the benefits of layered design? (5 benefits)
Testability: Each layer is testable in isolation without deep mocks or side effects.
Modularity: Features evolve independently with well-defined ownership.
Scalability: Teams work in parallel on layers without stepping on each other’s code.
Maintainability: UI and logic changes remain isolated, reducing regression risks.
Flexibility: Logic written in the domain layer can be reused across iOS, Android, and desktop.
What techniques can your team use to enforce boundaries across teams?
What mobile architecture patterns do?
Mobile architectural patterns are structured design approaches that help manage the complexity of building scalable and maintainable mobile apps.
Most commonly used patterns include:
MVC (Model-View-Controller)
MVP (Model-View-Presenter)
MVVM (Model-View-ViewModel)
MVI (Model-View-Intent)
VIPER (View, Interactor, Presenter, Entity, Router)
Who fetches data on the MVC architecture?
The model.
This is all about our app’s data and business logic. It knows how to fetch data from the server, for example, a list of restaurants from an API.
What does the controller in MVC?
This is the middleman that coordinates everything. It triggers the data fetch, listens for results, and passes data to the View.
When MVC shines?
- Very simple screens with low interaction.
- Prototypes where speed matters more than maintainability.
- Developers are working solo or in small teams.
What does MVP (Model - View - Presenter) does differently?
The Presenter takes over most of the logic. It talks to the Model to get data, transforms it into a format the View can use, and keeps the View as simple as possible. The View no longer thinks (how to display); it just displays.
What is the difference between the presenter in MVP and the controller in MVC?
The presenter is platform independent and we can reuse presenters across Views or platforms.
example:
class RestaurantPresenter(val view: RestaurantView, val service: RestaurantService) {
fun onSearchQuery(query: String) {
view.showLoading()
service.searchRestaurants(query) { result ->
when (result) {
is Success -> view.showRestaurants(result.data)
is Error -> view.showError("Could not load results")
}
}
}
}Pros and Cons of MVP
Pros: Great choice for medium-complexity screens with much interaction, like our search-enabled restaurant list. We can even reuse Presenters across Views or platforms.
Cons: One downside of MVP is that the Presenter can get big
What are the responsibilities of MVVM?
MVVM is different because the View and ViewModel are connected through reactive bindings. The ViewModel changes the data, and the View just watches and reacts. No back-and-forth or manual syncing is needed.
Model: Manages data and business logic (same as before).
View: Displays the UI and observes state changes.
ViewModel: A middle layer that holds the UI data and exposes it in a form that the View can easily use, often using observable data streams like LiveData or StateFlow.
MVVM advantages?
Reactive by design: Great for live data like order tracking or real-time updates.
Cleaner separation: ViewModel contains all presentation logic, View only shows data.
Testable: ViewModels are easy to test without dependency on Android or iOS UI classes.
Resilient: Survives configuration changes like rotation, because the ViewModel is life cycle-aware.
MVVM Cons?
The ViewModel can become bloated if overloaded with multiple responsibilities: UI logic, state mapping, user interactions, and API coordination.
While it’s better than the MVP, it still doesn’t give us clear state machine-like control over the app.
What is MVI?
Model View Intent.
MVI is centered around one big state object that holds everything our screen needs. Instead of updating different parts independently, the entire UI reflects this immutable state. When something changes, a new state version is created and sent back through the system.
Key Roles
Intent: These are user actions, like tapping a button, typing text, or pulling to refresh.
Model: Holds the logic for taking an Intent and producing a new state. It knows how to respond to an Intent; it fetches data, handles errors, and returns results.
View: Displays the current state, and nothing else.
State: A snapshot of everything the View needs now (e.g., loading = true, list = empty, error = null).
Benefits of MVI?
Predictability: Every change is intentional and traceable, with no hidden side effects.
Debugging: We can replay a history of states to see what happened.
Testability: The reducer is a pure function, super easy to write unit tests for.
Fit for reactive UIs: Works brilliantly with Jetpack Compose, Flutter, React Native, etc.
Cons of MVI?
writing a lot of sealed classes, reducers, and state definitions, even for a simple screen. The immutable objects are more memory-heavy, and MVI feels abstract to a team new to data flow or patterns.
-
[25] Swift Fundamentals70
-
[25] Swift Memory31
-
[25] GCD43
-
[25] async / await42
-
[25] SwiftUI Fundamentals65
-
[25] UIKit Fundamentals50
-
[25] Xcode Instruments - Fundamentals52
-
[25] System Design - Chapter 124
-
[25] Systems Design - Chapter 214
-
[25] Systems Design - Chapter 348
-
[25] Systems Design - Chapter 449
-
[25] Systems Design - Chapter 558
-
[25] Systems Design - Chapter 616
-
[25] Systems Design - Chapter 745
-
[25] Systems Design - Chapter 814
-
[25] Systems Design - Chapter 929
-
[25] iOS Systems Design - Part 107
-
[25] Systems Design Chapter 119
-
[25] Amazon 16 leadership principles16
-
[25] Swift Novice30
-
[25] iOS Network62
-
[25] Design patterns44
-
[25] Runloops20
-
[25] Core animations - Part 154
-
[25] Core animations - Part 254
-
Swift89
-
iOS Apprentice36
-
iOS Animations33
-
Design Patterns by Tutorials108
-
Core Data36
-
Push Notifications22
-
Advanced iOS App Architecture46
-
DI42
-
MVVM36
-
Concurrency53
-
TDD40
-
Git87
-
General55
-
Data Structures & Algorithms47
