The Problem With Over-Engineering Swift Architectures

The Clean Code Trap

Every Swift developer knows the feeling. You crack open a fresh project, and something in you wants to build it right—like, really right. You remember a meetup where someone swore by VIPER, or maybe you’ve been reading about Redux-like unidirectional data flows and how they make state predictable. So you lay down protocols. You split concerns until each layer could pass a whiteboard interview. The first couple of screens feel great. A data layer you’d be proud to screenshot. Then the deadline breathes down your neck, and you’re jumping through seven files just to push a string into a label. The architecture that was supposed to keep you nimble turned into a hedge maze.

Over-engineering doesn’t come with a pop-up warning. It dresses up in “separation of concerns” and “scalability” and walks right in. Most of the time, it’s not ambition—it’s fear. Fear of messy code. But a three-field form doesn’t need a ViewModel, a Presenter, a Router, and a UseCase protocol plus a mock for testing. That’s not architecture. That’s ritual. And rituals burn time—time you could’ve spent polishing the user experience or squashing actual bugs.

When Flexibility Becomes Rigidity

The weird thing about over-engineered Swift architectures is that they promise flexibility and hand you the opposite. Take a real-world VIPER module: five or six files per screen, dependencies injected through protocol witnesses, a separate router that knows the whole module graph. On paper, you can swap views or backends like Lego bricks. In practice? Add one parameter to a screen, and you’re editing ViewInput, ViewOutput, InteractorInput, InteractorOutput, PresenterInterface—and then their concrete twins. A one-line tweak ripples into a dozen files. The architecture resists change because it was overbuilt to welcome it.

A healthier reflex: ask what will actually change around here? If the honest answer is “probably not much for a year,” a lightweight Model-View-Controller or a plain ObservableObject in SwiftUI might be the smarter opening move. You can pull out a protocol later, when the pain is real. Premature abstraction isn’t safety—it’s a bet that you can see around corners. And most of us can’t.

The Cost of Indirection

Indirection is a tool, not a trophy. Swift hands us generics, protocol-oriented programming, and a type system that can model almost anything. Those things are fun to use. But every new layer piles on cognitive weight. When a junior developer opens a codebase where tapping a button fires a ViewEvent enum, maps to a ViewAction in a reducer, kicks off a side-effect through middleware, and finally updates a Store that publishes fresh state—they’re going to drown. Not because they’re not sharp. Because the system asks them to juggle too many abstractions at once.

There’s a reason UIKit’s target-action and SwiftUI’s @State and @Binding feel quick for small-to-medium features: they shrink the gap between what you mean and what happens. Building a settings screen that flips a preference and writes to UserDefaults? You don’t need five layers. You need a Toggle wired to @AppStorage. Done. The code is readable, debuggable, and deletable—three traits that beat theoretical purity any day.

Testing Is Not an Excuse

The loudest defense of heavy architecture is testability. “We have to mock the network layer to unit-test the ViewModel.” I get it. But mocking doesn’t demand a protocol on every object. Swift lets you subclass, lean on default initializer values, or just test at a higher level. A UI test that launches the app, taps through a flow, and checks visible text will catch real-world regressions that a hundred mocked unit tests might miss. And it won’t shatter every time you refactor an internal boundary.

I’m not saying skip testing. I’m saying be honest about what you’re testing and why. If network error handling is what keeps you up at night, write focused integration tests against a local server. If layout on weird screen sizes scares you, use snapshot tests. Don’t wrap every class in a protocol just to obey a rule that says “everything must be testable in isolation.” That rule gives you green tests while the app crashes on launch because nobody tested the real assembly.

Signs You’re Over-Engineering

Spotting over-engineering in someone else’s repo is easy. In your own, it’s harder. Here are signals I’ve learned to watch for:

• File count races past feature count. If a single screen births six new Swift files, ask whether each one earns its keep.
• Protocols with one implementation. A protocol that exists only so a mock can exist is a hint. Ask if that mock actually prevents bugs or just warms your conscience.
• Generic types that bury intent. AnyPublisher<Result<User, APIError>, Never> is exact, but a plain closure (Result<User, APIError>) -> Void is often clearer and just as testable.
• Architecture jargon in stand-ups. When the team argues about “interactor boundaries” more than the actual product, the architecture has eaten the roadmap.
• Fear of deleting code. Over-engineered systems collect dead abstractions because nobody knows what depends on what. A codebase should feel safe to prune.

The fix isn’t to dump everything into one massive ViewController. That’s under-engineering, and it hurts in its own way. The aim is to find the line where the architecture works for the product, not the other direction. A rough test: can someone new to the codebase follow a single screen’s flow without opening more than three files? If not, the architecture is probably fighting you.

Practical Starting Points

These days, when I start a Swift project, I reach for the simplest thing that might actually work. In SwiftUI, that’s usually a View file with its own ObservableObject view model, a small service struct for network calls, and maybe a Coordinator if navigation gets tangled. No protocols until a second concrete type shows up. No generics until the third use case. No separate data model until the view’s needs drift from the API’s shape.

This isn’t laziness—it’s restraint. It means you’re making judgment calls about when to abstract, instead of filling in a template. It also admits that most features ship once and then evolve at a crawl. The architecture that lets you ship today is often the one that’s easier to change tomorrow, simply because there’s less of it to change.

FAQ

Isn’t VIPER necessary for large apps?

Not really. Large apps need clear boundaries, sure—but boundaries that match the domain, not a template. A modular setup with independent feature packages can scale better than a single-app VIPER monolith, and it dodges the per-screen tax VIPER demands. The win is isolating features so a change in one doesn’t ripple everywhere. Package boundaries enforce that more honestly than naming conventions do.

How do I convince my team to simplify?

Start with a concrete example. Pick a recent feature that dragged on because of architectural overhead, and sketch what a simpler version could’ve looked like. Put the code samples side by side. Keep the conversation on measurable stuff: build times, bug counts, how long a new hire takes to get productive. Abstract fights about “clean code” rarely move anyone. Visible friction in the daily workflow does.

What about SwiftUI? Does it solve over-engineering?

SwiftUI lowers the barrier to simple code, but it doesn’t block over-engineering. I’ve seen SwiftUI projects with elaborate Redux stores, custom property wrapper stacks, and view modifier factories that would make a UIKit veteran wince. The declarative style can tempt you to layer abstraction on abstraction. The same rule applies: hold off on generalizing until the pattern has proven itself in at least three real places.

When is a complex architecture actually justified?

Complexity earns its keep when the problem itself is tangled and the patterns grow from real needs, not from guesswork. An app that syncs offline data across device types with conflict resolution might genuinely need a thick state management layer. But extract that layer after the sync logic has been proven in a simpler shape. Let the code tell you where it hurts before you build scaffolding around it.