Clean Swift iOS architecture: The full VIP cycle guide

This guide walks through every VIP component with a real Create Order use case, testing patterns, and the scaling issues that show up once a codebase passes 30 scenes.

What Clean Swift fixes (and what it doesn't)

The Massive View Controller problem is what Clean Swift architecture exists to fix: one UIViewController owning networking, parsing, layout, and navigation until it hits 2,000+ lines and nobody wants to touch it. The VIP cycle: View, Interactor, Presenter, wired by a Configurator and Router, forces that logic apart into single-responsibility layers with public protocol boundaries between them.

Clean Swift adapts the layering Robert C. Martin defined in Clean Architecture, entities, use cases, interface adapters, into an iOS-specific, unidirectional cycle rather than a generic dependency-rule diagram.

According to Kodeco's Clean Swift tutorial series, production Massive View Controllers commonly exceed 3,000 lines before teams intervene, a size where Xcode's incremental build system starts to choke.

If you're working with SwiftUI, this guide shows how to apply Clean Swift layering to declarative UI, along with the tradeoffs that come with it.

The payoff shows up in three places once a migration from MVC to Clean Swift lands: test coverage climbs because Interactors and Presenters can be tested with mock protocols instead of a live view hierarchy, incremental build times improve as the Massive View Controller's single compilation unit splits into smaller files, and new engineers ramp up faster once they have a completed VIP scene to pattern-match against.

What it doesn't fix: Clean Swift trades a Massive View Controller for more files, more protocols, and Configurator boilerplate per scene. That trade pays off on projects with real scalability and maintainability demands. It's a poor fit for a five-screen sample app or a prototype you'll throw away in a quarter.

The VIP cycle: How data flows through a scene

The VIP cycle moves data in one direction only: View to Interactor to Presenter, back to View, never the reverse. That single rule is what keeps a Clean Swift scene testable, you can swap any layer for a mock and the data path still makes sense.

Here is what actually happens when a user taps a button on screen. The View calls a method on the Interactor's public InteractorProtocol, nothing more than "user tapped fetch, here's the request struct." The Interactor does the work (often delegating to a Worker for networking or persistence), then hands raw response data to the Presenter through a separate PresenterProtocol. The Presenter formats that data into a ViewModel, string dates, currency formatting, empty-state flags: and pushes it to the View through a third protocol, DisplayLogic.

The View just renders. It never touches business logic, and it never talks back to the Interactor directly.

This three-protocol handoff is the part teams new to Clean Swift architecture underestimate. Robert C. Martin's original Clean Architecture describes the same dependency rule, inner layers stay ignorant of outer ones, and VIP is a Swift-specific implementation of it, not a reinterpretation.

In practice, this unidirectional structure pays off fastest during testing. Splitting a bloated view controller into VIP scenes means mock Interactors and Presenters can be written against the Input/Output protocols alone, with no view controller instantiation and no UIKit in the test target.

Coverage on the affected module climbs accordingly, because every layer boundary is a protocol you can fake in five lines.

The cost shows up one layer over: wiring all three protocols by hand, scene after scene, is where Clean Swift starts to hurt.

The view controller layer: Inputs, outputs, and display logic

The View Controller in Clean Swift does one job: render what the Presenter hands it, and nothing else. It conforms to a DisplayLogic protocol, the Output side of the Input/Output protocol pair that defines the scene's public contract. No business logic, no formatting decisions, no direct data fetches. That constraint is the whole point of the VIP cycle.

Input and Output protocols split responsibility cleanly. InteractorProtocol (Input) declares what the View can ask for: • fetchSomething • loadNextPage

DisplayLogic (Output) declares what the View can be told: • displaySomething(viewModel:) • displayError(message:) • displayLoading(_ isLoading: Bool)

Both are Swift protocols with no shared state, which is why mocking either side for a unit test takes minutes, not a rewrite.

Compare that to a Massive View Controller, where a single UIViewController past 800-1,000 lines mixes networking, table reload logic, and error handling in one file, per the pattern Robert C. Martin describes in Clean Architecture as a violation of the dependency rule. Splitting a controller like that into VIP scenes cuts each individual view controller's file size substantially, and lets DisplayLogic be stubbed with a mock in every test with no live network call required.

Display logic still owns activity indicators, table view reloads, and alert presentation, it just never decides when to show them. The Presenter decides. The View executes.

The interactor: Where business logic and use cases live

The Interactor owns every use case in a scene. It receives a request from the View Controller, runs the business logic for that single action, and returns a response to the Presenter. It does not own network code.

When a use case needs data, the Interactor calls a Worker rather than reaching into a network client or Core Data stack directly. Workers wrap side effects: API calls, database reads, keychain access, third-party SDKs. The Interactor asks a Worker for data, the Worker fetches it, and the Interactor decides what that data means for the current use case.

This is the split Robert C. Martin's Clean Architecture insists on: keep policy separate from mechanism, so the use case survives even if the persistence layer changes underneath it.

Workers also make the VIP cycle easy to test in isolation. Swap a real Worker for a mock that returns canned data, and you can exercise an Interactor's full use case logic with no network activity and no live API dependency, cutting unit tests loose from the staging-server dependency that a Massive View Controller's tangled network calls usually require.

A sample use case: loading and reload of a paginated list. The Interactor asks a Worker for page data, applies sort and filter rules, then hands a formatted response to the Presenter. No UIKit, no error handling for HTTP status codes, that stays in the Worker, where it belongs.

The presenter: Formatting data for display

The Presenter's only job is translation: it takes the Interactor's response and turns it into a ViewModel the View Controller can render with zero decisions left to make. No branching on business state, no date math, no pluralization logic inside the View Controller. That work happens here, once, in a layer built to be discarded and rewritten without touching the Interactor at all.

Mechanically, the Presenter conforms to an input protocol (the methods the Interactor calls, like presentFetchedTasks) and holds a reference to the View Controller through a display output protocol it calls to push the formatted ViewModel back.

This Input/Output protocols pairing is what keeps VIP's data flow unidirectional and makes each side mockable in isolation, a pattern Robert C. Martin's Clean Architecture frames as separating policy from detail.

In practice, this is where loading states, empty states, and error copy get decided. "Retry" versus a silent reload, singular versus plural counts, currency formatting per locale, all Presenter concerns. Moving this logic out of a Massive View Controller and into a dedicated Presenter layer typically takes formatting logic from effectively untested to fully unit-testable in short order, because the Presenter has no UIKit dependency left to mock.

The worker's role: Isolating network and data access

The Worker owns every network call, background task, and data store transaction in Clean Swift architecture. The Interactor never imports URLSession, Core Data, or a third-party SDK directly.

That isolation is the whole point. An Interactor calling a Worker protocol can be tested with a mock that returns canned data in milliseconds: no live network, no flaky CI runs, no loading spinner stalling a unit test.

Consider a simple example: a LoginWorker that exposes fetchUser(completion:). The Interactor calls that one method and never knows whether the implementation hits a REST API, a GraphQL endpoint, or a local cache. Swap the backend later, and only the Worker's internals change, not the Interactor's logic or its tests.

Wrapping a legacy Core Data persistence layer inside a Worker is one of the most reliable ways to cut integration-test flakiness on a migration, since the Interactor can reload state from a fake data store instead of a live one.

This mirrors the dependency-inversion layer Robert C. Martin describes in Clean Architecture: the Worker sits at the boundary, and only it knows the concrete data source. Kodeco's Clean Swift tutorial documents the same separation, treating the Worker as the only object permitted to touch a network client or database SDK directly.

CleanStore, the reference sample project many teams use when adopting this pattern, demonstrates this same boundary using dedicated Worker components for each external dependency, one for networking, one for persistence, kept intentionally separate.

The Worker's public interface should return raw domain data, never a ViewModel, and never swallow an error silently. Surface failures through a completion result or a Combine publisher, so the Interactor, not the Worker, decides how the app reacts.

We keep an updated sample Worker template further down this page in our Clean Swift code generator, for good reason. It is the piece most write-ups skip or fold straight into the Interactor, and the one that pays off most on year-two maintenance, when the backend API changes and only the Worker needs a rewrite.

The router: Passing data between scenes

The Router in Clean Swift owns every navigation decision. passDataToNextScene(segue:) carries model data from one scene's data store into the next before the transition completes. The View Controller never touches the destination directly, so a Massive View Controller reaching into prepare(for:) to mutate a destination's properties has no equivalent in this architecture.

A typical Router implementation looks like this. Note that skipping the call to passDataToNextScene is the most common cause of a silently empty detail screen, so keep it in place even though it may look redundant:

extension ListingsRouter: ListingsRoutingLogic, ListingsDataPassing {
 func routeToDetail(segue: UIStoryboardSegue?) {
 if let segue = segue {
 let destinationVC = segue.destination as! DetailViewController
 var destinationDS = destinationVC.router!.dataStore!
 passDataToNextScene(segue: segue, source: dataStore!, destination: &destinationDS)
 }
 }

 func passDataToNextScene(segue: UIStoryboardSegue, source: ListingsDataStore, destination: inout DetailDataStore) {
 destination.listingID = source.selectedListingID
 }
}

Each scene's dataStore is a public property conforming to a shared protocol, so the compiler flags a missing field as a build error rather than a runtime crash after a reload.

Not every transition uses a storyboard segue, and the pattern holds regardless. Using programmatic navigation, routeToDetail simply builds and pushes the destination view controller directly, then calls the same passDataToNextScene method before the push completes, so the data-passing contract never changes just because the trigger did.

Routers can also inject dependencies, such as network services or analytics loggers, into the next scene's Interactor at the same moment data crosses the data store. This keeps construction logic out of the View Controller and each scene's components simple to reason about in isolation.

According to Kodeco's Clean Swift architecture guide, passDataToNextScene is one of four required protocol methods in the VIP scene template. Their updated CleanStore sample project demonstrates the pattern across a dozen scenes, including edge cases like passing data backward on an unwind segue and skipping destination setup entirely when a user cancels a modal flow.

New hires who skip the call remain the single most common cause of a detail screen loading a stale, empty model.

Moving segue logic out of view controllers and into dedicated Routers is one of the more durable wins from adopting Clean Swift: navigation-related crashes trace back to a specific Router method instead of a prepare(for:) override buried in an unrelated view controller.

The configurator: Dependency injection at scene setup

The Configurator wires every dependency a scene needs before the View Controller's viewDidLoad fires, assigning concrete Interactor, Presenter, and Router instances through a public extension rather than scattering setup across loading callbacks or lazy properties. Configurator dependency injection happens in exactly one place per scene, which mirrors Robert C. Martin's Clean Architecture principle of pushing composition to the edges and keeping every layer testable in isolation.

A typical sample from a Swift project on the VIP cycle looks like this:

extension ProfileScene.Configurator: ProfileScene.Configuration {
 func configure(viewController: ProfileScene.ViewController) {
 let presenter = ProfileScene.Presenter
 let interactor = ProfileScene.Interactor
 let router = ProfileScene.Router
 viewController.interactor = interactor
 interactor.presenter = presenter
 presenter.viewController = viewController
 router.viewController = viewController
 }
}

This wiring makes VIP cycle test doubles trivial. Swap the concrete Interactor for a mock that records activity and returns canned data, and the View Controller cannot tell a live network call from a stub, on a reload or a fresh page load alike.

This swap-in-mock approach is what cuts Presenter test setup time down against the old MVC baseline, since the View Controller can't tell a live network call from a stub either way. Router logic benefits from the same isolation; testing navigation flows separately keeps Presenter tests focused on business logic alone.

The tradeoff shows up at scale. Past 30 to 40 scenes, every new feature means a fresh Configurator, a new Input/Output protocol pair, and one more place a wiring error goes unnoticed until runtime.

Please weigh this before committing to VIP project-wide: code generator templates claw back the typing time, but they don't fix protocol proliferation, they just generate it faster.

Full walkthrough: Building the 'Create order' use case

Trace a Create Order scene through the full VIP cycle and the wiring stops feeling abstract. Five components carry the use case: CreateOrderViewController, CreateOrderInteractor, CreateOrderPresenter, CreateOrderWorker, and CreateOrderRouter, each doing exactly one job with clear dependencies between layers.

The View calls the Interactor with a request model:

func createOrderTapped() {
 let request = CreateOrder.Submit.Request(items: cart.items)
 interactor?.submitOrder(request: request)
}

The Interactor owns business rules and delegates data access to a Worker rather than calling a network layer directly. This keeps the use case testable without spinning up real dependencies:

func submitOrder(request: CreateOrder.Submit.Request) {
 guard !request.items.isEmpty else {
 presenter?.presentError(response: .init(message: "Cart is empty."))
 return
 }
 worker.postOrder(request.items) { [weak self] result in
 switch result {
 case .success(let order):
 self?.presenter?.presentSuccess(response: .init(order: order))
 case .failure(let error):
 self?.presenter?.presentError(response: .init(message: "Order failed, please retry."))
 }
 }
}

Note the guard clause up front. Validating input inside the Interactor, before any network call, is where most real-world error handling belongs in this pattern.

The Presenter then formats that response into a display model:

func presentSuccess(response: CreateOrder.Submit.Response) {
 let viewModel = CreateOrder.Submit.ViewModel(
 confirmationText: "Order #\(response.order.id) confirmed"
 )
 viewController?.displaySuccess(viewModel: viewModel)
}

The View never sees raw data or an Error type, only what it needs to render. On success, the Presenter tells the Router to push a confirmation scene, keeping navigation out of the View Controller entirely.

That's the payoff Robert C. Martin's Clean Architecture for iOS promises: each layer depends inward, never sideways.

Writing a mock Interactor and mock Presenter as test doubles before touching production code is the standard approach here. That lets you assert submitOrder triggers presentSuccess without a live network call, and it's a large part of why teams see coverage jump once a Create Order flow moves off a Massive View Controller.

Kodeco's CleanStore sample project, along with community code generators, scaffolds this file set in seconds using a template that mirrors what's shown above. We still hand-edit the Worker signature, since generated stubs assume a generic data source rather than the actual persistence layer. Keep the pattern simple and updated as your API contracts change, and the scaffolding stays a starting point, not a straitjacket.

Testing the VIP cycle with XCTest

The VIP cycle in clean architecture iOS projects is unit-testable by design. Because the Interactor, Presenter, and Worker only depend on protocols, XCTest can substitute mock objects for each neighboring component and assert behavior without spinning up a single view.

Our usual pattern is a MockCreateOrderPresenter that records which method was called and with what response model, paired with a real Interactor and a stubbed Worker that returns canned data instead of hitting the network. That isolates the layer under test completely: no loading spinners, no reload timing, no flaky async waits.

A simple spy setup covers most scenes:

• Create a mock Presenter conforming to the display logic protocol, storing a boolean flag and the last response model it received.
• Inject that mock into a real Interactor using its business logic protocol dependency.
• Stub the Worker so it returns fixed data synchronously, removing network dependencies from the test run.
• Call the interactor method under test, then assert the mock's flag and captured model match expectations.

A request/response test looks roughly like this: call interactor.createOrder(request:), then assert mockPresenter.presentCreateOrderCalled is true and the error field matches expectations. Router tests follow the same shape, checking that navigation methods fire rather than checking screen state.

If you want a working reference, clone a CleanStore-style sample project and inspect its test targets before writing your own.

Per-scene coverage typically moves from single digits under a Massive View Controller setup to a large majority once each VIP component has its own XCTest target, with Configurator dependency injection swapping in mocks per test case. That's the return on the extra files: a Clean Swift project earns testability that MVC structurally can't offer, past a certain scale.

Clean Swift vs. MVVM, and where SwiftUI fits

Clean Swift and MVVM both attack Massive View Controller bloat, but they guarantee different things about data flow. MVVM moves presentation logic into a view model that the view can read from and write to, so two-way binding creeps back in unless the team enforces one-way discipline by hand. Clean Swift enforces it structurally: View to Interactor to Presenter to View, no back channel, no exception.

That structural guarantee comes straight from Clean Architecture, published in 2017, the source of the one-way boundary rule Clean Swift enforces at compile time. MVVM has no equivalent: enforcement depends on code review, not the compiler, and review misses wiring errors a protocol mismatch would catch during a build.

Netguru's own rule of thumb: reach for Clean Swift when a codebase needs an audit trail across dozens of contributors, and for MVVM when the team is under eight people and business rules are thin. That guidance comes from our iOS app development services work, where architecture choices get matched to team size and project complexity.

SwiftUI does not replace either pattern; it replaces UIKit as the rendering layer. Combine slots into MVVM or Clean Swift as reactive plumbing underneath, and Apple's own documentation describes it as a publisher-subscriber framework rather than an architecture in its own right. SwiftUI does not replace either pattern; it replaces UIKit as the rendering layer, and understanding how these patterns differ still matters when deciding where Combine fits in.

Swapping a UIKit scene for a SwiftUI view driven by an ObservableObject only touches the View layer and the Configurator; the Interactor, Presenter, and Worker code stays untouched. Protocol-oriented programming is what makes that swap survivable.

Because the public Input/Output protocols define the contract at the VIP boundary, the rendering technology underneath, UIKit or SwiftUI, stays an implementation detail rather than an architecture decision. When that implementation detail is SwiftUI, structuring SwiftUI views effectively with the right combination of stacks, grids, and outlines still matters for a maintainable View layer.

SwiftUI adoption sits at roughly 65% of iOS teams, per a mid-2025 developer survey. Navigating this shift is easier with an expert Swift development team that keeps architecture decisions aligned with the latest UIKit and SwiftUI best practices.

Clean Swift FAQ

Get help scaling Clean Swift past the first few scenes

Scaling a VIP cycle past 30 to 40 scenes without a plan for Configurator boilerplate turns clean architecture iOS work into its own maintenance problem. Components that looked simple in a sample project, like CleanStore, start multiplying once real dependencies, networking, and persistence layers get added.

Rebuilding a Massive View Controller codebase scene by scene, while keeping the app shippable throughout, is what an incremental migration to Clean Swift looks like in practice, as opposed to a rewrite from scratch. The ramp-up typically takes a couple of sprints before engineers wire Configurator dependency injection and Router navigation without needing a checklist. Past that point, velocity on new scenes tends to match or beat the old MVC baseline, and test coverage climbs alongside the protocol count instead of trailing it.

That gap, between a tidy diagram and a codebase that actually scales, is where most clean architecture iOS efforts stall.

If your team is past the first few scenes and the protocol count is climbing faster than test coverage, talk to our team. We help engineering leads pressure-test the architecture, tighten the data layer, and find where a clean, swift refactor pays off, not just where it looks organized on paper.