Articles related to this project
- Clean Architecture for SwiftUI
- Programmatic navigation in SwiftUI project
- Separation of Concerns in Software Design
Clean Architecture for SwiftUI + Combine
A demo project showcasing the setup of the SwiftUI app with Clean Architecture.
The app uses the restcountries.eu REST API to show the list of countries and details about them.
Check out mvvm branch for the MVVM revision of the same app.
- Vanilla SwiftUI + Combine implementation
- Decoupled Presentation, Business Logic, and Data Access layers
- Full test coverage, including the UI (thanks to the ViewInspector)
- Redux-like centralized
AppStateas the single source of truth
- Data persistence with CoreData
- Native SwiftUI dependency injection
- Programmatic navigation. Push notifications with deep link
- Simple yet flexible networking layer built on Generics
- Handling of the system events (such as
- Built with SOLID, DRY, KISS, YAGNI in mind
- Designed for scalability. It can be used as a reference for building large production apps
SwiftUI views that contain no business logic and are a function of the state.
Side effects are triggered by the user's actions (such as a tap
on a button) or view lifecycle event
onAppear and are
forwarded to the
State and business logic layer (
Interactors) are navitely injected into the view
Business Logic Layer
Business Logic Layer is represented by
Interactors receive requests to perform work, such as obtaining data from an external source or making computations, but they never return data back directly.
Instead, they forward the result to the
Binding. The latter is used when the result of
work (the data) is used locally by one View and does not belong to
Previously, this app did not use CoreData for
persistence, and all loaded data were stored in the
With the persistence layer in place we have a choice - either to
load the DB content onto the
AppState, or serve the
Interactors on an on-demand basis through
The first option suits best when you don't have a lot of data,
for example, when you just store the last used login email in the
UserDefaults. Then, the corresponding string value can
just be loaded onto the
AppState at launch and updated
Interactor when the user changes the input.
The second option is better when you have massive amounts of data and introduce a fully-fledged database for storing it locally.
Data Access Layer
Data Access Layer is represented by
Repositories provide asynchronous API (
from Combine) for making CRUD operations on the backend or a local
database. They don't contain business logic, neither do they mutate
AppState. Repositories are accessible and used
only by the Interactors.