Kotlin/Androidから学ぶSwiftUIでのスケーラブルなiOSアプリ設計

InfoQ Homepage Articles Borrowing from Kotlin/Android to Architect Scalable iOS Apps in SwiftUI

Borrowing from Kotlin/Android to Architect Scalable iOS Apps in SwiftUI

Feb 26, 2026 16 min read

Sergio De Simone

Write for InfoQ

Listen to this article - 0:00 Audio ready to play Your browser does not support the audio element. 0:00 0:00 Normal1.25x1.5x Like Reading list

Good architecture is platform agnostic.The principles that make Android apps maintainable work equally well on iOS.

Action-based ViewModels create a clear contract: routing all mutations through a single method gives you centralized logging, easier testing, and a documented "API" of what your ViewModel actually does.

Explicit state eliminates impossible states at the outset: Loadable<T>

The Screen/Content separation clarifies responsibilities: splitting the "owns the ViewModel" concern (Screen) from "renders the UI" concern (Content) makes views more reusable and easier to preview in isolation.

Reactive repositories enable automatic UI synchronization: when the repository owns the data and exposes it via publishers, any update propagates to all observing ViewModels automatically.

For us iOS developers, it’s often hard to create scalable architecture out of simple one-page example apps from Apple. Sure it works for a simple app, but I have always struggled with what to do next when you want to build something scalable.

After looking around, I discovered the Android world. I was surprised by what Google provides for developers compared to Apple. Android developers have clear guides and patterns, and most importantly, real-world examples that show how to structure production apps and not just toy projects.

The Android community benefits from:

Official Architecture Components with clear documentation

Sample apps like Now in Android that demonstrate best practices at scale

Consistent patterns across the ecosystem (Repository, ViewModel)

Related Sponsors

Scalable Enterprise Java for the Cloud - Download the eBook

Related Sponsor

Move from complexity to control. Run and scale your Jakarta EE, Spring, and Quarkus applications on a unified platform that replaces infrastructure chaos with deployment simplicity and total autonomy. Learn More.

In comparison, iOS developers are often left piecing together solutions from blog posts and Apple’s sample apps. These solutions are useful in isolation, but rarely represent how a real-world app’s architecture evolves, leaving us hoping our architecture doesn’t collapse as the app grows.

But here is the encouraging thing: Good architecture is platform agnostic. The principles that make Android apps maintainable work just as well on iOS.

This article explores how iOS apps can be built using architecture patterns inspired by modern Kotlin and Android development. It demonstrates how these patterns translate to Swift and SwiftUI.

We will start with a fundamental problem: managing state inside a view. This problem includes enforcing a single entry point for mutations and enabling cross-cutting concerns such as logging and debugging.

Next, we will move one layer up and separate the view from its view model to improve reusability, testability, and previewability.

Finally, we will introduce an active repository layer to bring the concept of a single source of truth to life and show how data can automatically propagate across the app.

The Problem with Traditional iOS ViewModels

If you’ve built iOS apps with SwiftUI, you’ve probably written something like this:

class DashboardViewModel: ObservableObject { @Published var workouts: [Workout] = [] @Published var isLoading = false @Published var error: Error? func loadWorkouts() { isLoading = true error = nil Task { do { workouts = try await api.fetchWorkouts() isLoading = false } catch { self.error = error isLoading = false } } } }

This code works for a simple screen, but consider what happens as the ViewModel grows.

The State Problem

Multiple properties that can contradict each other. Nothing stops this:

viewModel.isLoading = true viewModel.workouts = cachedWorkouts // Now we're "loading" with data viewModel.error = NetworkError.timeout // And also errored?

Which state should the UI show? The compiler doesn’t help you here. Developers make different choices and bugs are created.

The mutation problem

You will add more methods such as loadMore()

deleteWorkout()

filterWorkout()

selectWorkout()

Imagine you are working on a feature. It touches a ViewModel you haven’t seen in six months, or a new one that you have never seen. You open the file and it has six hundred lines and twenty methods. What does the thing do? Which methods are called from the view and which ones are internal helpers? You will have to read the whole class to understand it. There is no summary, no contract, no list of "here’s what this ViewModel can do". Now multiply that by 100 other ViewModels.

Solving the State Problem: Explicit State

In Kotlin, the state problem is solved at the type level:

sealed interface UiState<out T> { data object Loading : UiState<Nothing>() data class Success<T>(val data: T) : UiState<T>() data class Error(val message: String) : UiState<Nothing>() } val workouts: StateFlow<UiState<List<Workout>>> = ...

The state is defined by a single source of truth. Its type makes the possible states mutually exclusive, and the compiler enforces this. Being in both Loading

The Swift equivalent is straightforward:

enum Loadable<T, U> { case loading case finished(T) case error(U) } class DashboardViewModel: ObservableObject { @Published var workouts: Loadable<[Workout]> = .loading }

Solving the Mutation Problem: Single Entry Point

Explicit state prevents contradictory states, but what about the problem of multiple mutating methods? Kotlin’s answer is to funnel everything through a single entry point:

fun onAction(action: DashboardAction) { when (action) { is DashboardAction.Refresh -> loadWorkouts() is DashboardAction.SelectWorkout -> selectWorkout(action.id) is DashboardAction.Delete -> deleteWorkout(action.id) } }

Every mutation flows through onAction()

Look at the DashboardAction

sealed class DashboardAction { object Refresh : DashboardAction() data class SelectWorkout(val id: String) : DashboardAction() data class Delete(val id: String) : DashboardAction() data class FilterBy(val type: WorkoutType) : DashboardAction() }

This is a complete list of every action in the ViewModel. A new engineer can open this file, read the class and immediately understand the ViewModel’s capabilities. No scrolling through six hundred lines of code, no guessing which methods are public, no wondering if this is called from the View or if it is internal only.

The sealed class is the contract. If an action isn’t declared there, the ViewModel can’t execute it. This policy also forces you to think about your ViewModel’s responsibilities. When you add a new action, you add it to the sealed class first. It’s a conscious decision and not a method that just quietly appears somewhere in the file.

But what exactly goes in DashboardAction? If the View can trigger an action, it should be declared as an action. Does the user tap to delete an item? Does the user select an item? What stays out? Internal helpers, such as loadWorkouts()

enum Action { case refresh case selectWorkout(String) case delete(String) } // Not actions — internal implementation private func loadWorkouts() async { ... } private func updateCache(_ workouts: [Workout]) { ... }

If you have been writing iOS apps for some years, this pattern feels unnecessary. Why funnel everything through one method when you can just call that method directly. Well, the answer is that it doesn’t matter when the team is small and you have just three to five screens. It does matter, however, when the team and the codebase grow. Traditional iOS patterns optimize for the simple case, such as using @StateObject

But when scaling up, those direct method calls are problematic. Every method is a potential entry point. Every entry point is a place where state can change. The more entry points, the harder it is to reason about your ViewModel.

Centralizing actions enables things that are genuinely hard to manage otherwise when the codebase grows, including logging, debugging, testing, and analytics.

One line in the base class, and you see every action across every ViewModel. It is not necessary to add print statements to multiple methods.

func perform(_ action: Action) { print("[\(Self.self)] Action: \(action)") // handle action…… }

If the state is wrong, then you need to set just one breakpoint in perform()

Tests become readable. Because every action goes through the same path, you are testing the same code path the real app uses.

viewModel.perform(.refresh) viewModel.perform(.selectWorkout("123")) viewModel.perform(.delete("123")) XCTAssertEqual(viewModel.state.workouts, .finished([]))

Every user interaction is captured automatically.

func perform(_ action: Action) { analytics.track(action) // handle action... }

This function isn't something new. It is a standard practice in Android development and is recommended in Google's official architecture guide. Android developers call it unidirectional data flow Events flow downward (View &rarr; ViewModel &rarr; Repository) and state flows upward (Repository &rarr; ViewModel &rarr; View). The onAction()

Google's "Now in Android" sample app uses this pattern. So does most of the Kotlin community. When an Android developer joins a new project, they expect to find an Action enum and an onAction()

The Swift Implementation

Here's how to bring this pattern to iOS:

class ViewModel<State, Action>: ObservableObject { @Published private(set) var state: State init(state: State) { self.state = state } func perform(_ action: Action) { // Override in subclass } func updateState(changing keyPath: WritableKeyPath<State, some Any>, to value: some Any) { state[keyPath: keyPath] = value } }

The state is readable from anywhere, but only writable from inside the ViewModel. This approach enforces unidirectional data flow where Views can read state, but they can't mutate it directly. All changes go through perform()

You could define this approach as an extension, but a base class gives you a place to put shared logic such as logging, analytics, and common state update patterns. Every ViewModel inherits that behavior.

Subclasses override this base class method to handle their specific actions.

Here is a complete ViewModel using this pattern:

class DashboardViewModel: ViewModel<DashboardViewModel.State, DashboardViewModel.Action> { struct State { var workouts: Loadable<[Workout]> = .loading var selectedTab: Tab = .dashboard } enum Action { case refresh case selectTab(Tab) case deleteWorkout(String) } override func perform(_ action: Action) { switch action { case .refresh: Task { await loadWorkouts() } case .selectTab(let tab): updateState(\.selectedTab, to: tab) case .deleteWorkout(let id): Task { await deleteWorkout(id) } } } private func loadWorkouts() async { updateState(\.workouts, to: .loading) do { let workouts = try await repository.fetchWorkouts() updateState(\.workouts, to: .finished(workouts)) } catch { updateState(\.workouts, to: .error(error)) } } private func deleteWorkout(_ id: String) async { // implementation } }

Notice the structure:

State is a struct with all the ViewModel's data

Action is an enum with all possible user intents

Private methods do the actual work

The Action enum is the public contract. The private methods are implementation details. Looking at this file, you immediately know what it does.

Screen vs. View: The Missing Layer

We've solved state management and action routing, but there is another problem: tight coupling. Views own their ViewModels, which breaks Previews and limits reusability.

Look at this standard View:

struct DashboardView: View { @StateObject private var viewModel = DashboardViewModel() var body: some View