Repository files navigation

• Clean Architecture for SwiftUI
• Programmatic navigation in SwiftUI project
• Separation of Concerns in Software Design

A demo project showcasing the setup of the SwiftUI app with MVVM Architecture.

The app uses therestcountries.com REST API to show the list of countries and details about them.

Check outmaster branch for the Clean Architecture revision of the same app.

For the example of handling theauthentication state in the app, you can refer to myother tiny project that harnesses the locks and keys principle for solving this problem.

• VanillaSwiftUI +Combine implementation
• DecoupledPresentation,Business Logic, andData Access layers
• Full test coverage, including the UI (thanks to theViewInspector)
• Redux-like centralizedAppState as the single source of truth
• Data persistence withCoreData
• 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 asdidBecomeActive,willResignActive)
• 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 eventonAppear and are forwarded to theViewModel.

ViewModel also serves as the data source for the View.ViewModel is injected into the view as a constructor parameter.

Business Logic Layer is represented byViewModels andServices.

Services 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 theAppState or to aBinding. The latter is used when the result of work (the data) is used locally by oneViewModel and does not belong to theAppState.

ViewModel works as an intermediary betweenView andServices, encapsulating business logic local to the view. It is observing changes in theAppState, providing up-to-date data to theView throughBindings.

Previously, this app did not use CoreData for persistence, and all loaded data were stored in theAppState.

With the persistence layer in place we have a choice - either to load the DB content onto theAppState, or serve the data fromServices on an on-demand basis throughBinding.

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 theUserDefaults. Then, the corresponding string value can just be loaded onto theAppState at launch and updated by theService 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 is represented byRepositories.

Repositories provide asynchronous API (Publisher from Combine) for makingCRUD operations on the backend or a local database. They don't contain business logic, neither do they mutate theAppState. Repositories are accessible and used only by the Services.