We’ve built the core business layer of our app as a Swift package following Clean Architecture principles, so what does it look like to actually use it to build an iOS app?
In today’s post we will look at exactly that, and how our use cases are utilized by client code to build a functional iOS app.
 What’s Covered:
Separation of Concerns: See how Clean Architecture’s layered approach keeps our core business logic independent of platform-specific details.
The Persistence Layer: Learn how we implement the EmployeeRepository protocol with a local JSON file for data storage—and how easily this can switch to a network-based implementation.
The UI Layer with SwiftUI: Discover how SwiftUI interacts seamlessly with our business logic via use cases like FetchEmployeeListUseCase, empowering a clean and modular design.
Tying It All Together: Watch as we assemble the persistence, business, and UI layers into a cohesive app, highlighting how each layer remains independent yet integrated.
What You’ll Gain:
A practical example of Clean Architecture principles in action.
Insights into creating modular, future-proof code that supports growth and changing requirements.
The power of decoupling business logic, persistence, and UI for maintainability and scalability.
In case you haven’t already, head over to our previous article to learn the basics of Clean Architecture and to see how we use it to build a Swift Package containing our app’s business logic.
Subscribers can find the code for the entire app we build in this post at the very end.
The Persistence Layer of our iOS App
If you’ll recall from our previous blog post, when developing our use cases, we had to abstract where the Employee data came from. To accomplish this we defined an EmployeeRepository protocol which our use cases depended on for retrieving Employee data.
This abstraction along with the use cases allowed us to build our core business layer code as a separate Swift Package and solely focus on the business rules, not having to worry about details such as whether data comes from a local file or the network.
However, now that we are building an iOS app, it does matter where this data is coming from. Our use cases still don’t care, but since we are now developing the outer layers, namely the persistence/db layer in this case, this detail does matter.
We are now at the outer layers of clean architecture which are responsible for data persistence, so they must know how data is retrieved and saved. This is where we will create a concrete implementation of the EmployeeRepository protocol.
Below is our implementation. We use a local json file as our persistent storage. It is where we will retrieve employee data and store new data.
With our concrete implementation of the EmployeesRepository protocol, we are ready to move on to the next step.