Introduction

@Published does not create “computed published properties” automatically, but Combine gives you the pieces to build the same effect. The basic choice is whether the derived value should be a normal computed property or a stored property updated by a publisher pipeline.

Use a Plain Computed Property for Synchronous Derived State

If the derived value can be calculated instantly from current stored properties, a normal computed property is often enough.

1import Foundation
2import Combine
3
4final class LoginViewModel: ObservableObject {
5    @Published var username = ""
6    @Published var password = ""
7
8    var isLoginValid: Bool {
9        !username.isEmpty && password.count >= 8
10    }
11}

This is simple and correct when the UI reads the value after either source property changes.

Use a Combine Pipeline When You Need a Published Output

If other code needs the derived value to be emitted reactively, store it and update it from publishers.

1import Foundation
2import Combine
3
4final class LoginViewModel: ObservableObject {
5    @Published var username = ""
6    @Published var password = ""
7    @Published private(set) var isLoginValid = false
8
9    private var cancellables = Set<AnyCancellable>()
10
11    init() {
12        Publishers.CombineLatest($username, $password)
13            .map { !$0.isEmpty && $1.count >= 8 }
14            .assign(to: &$isLoginValid)
15    }
16}

That is the closest Combine equivalent to a reactive computed property.

Choose Based on Who Consumes the Value

A useful rule is:

• if the value is only read synchronously by SwiftUI or local code, a normal computed property is enough
• if the value itself must participate in a publisher chain, make it stored and drive it with Combine

This distinction keeps view models simpler and avoids overbuilding reactive state that does not need to be independently observed.

Derived Publishers Without Stored State

Sometimes you do not want an extra stored property at all. In that case, expose a derived publisher directly.

1import Foundation
2import Combine
3
4final class LoginViewModel: ObservableObject {
5    @Published var username = ""
6    @Published var password = ""
7
8    var isLoginValidPublisher: AnyPublisher<Bool, Never> {
9        Publishers.CombineLatest($username, $password)
10            .map { !$0.isEmpty && $1.count >= 8 }
11            .eraseToAnyPublisher()
12    }
13}

This is useful when a downstream subscriber wants the stream but you do not need to store the latest value explicitly.

Avoid Circular State Updates

A derived @Published property should usually be output-only. That is why private(set) is a good default. If outside code can write to the derived property directly, it becomes easy to create inconsistent state.

The source values should drive the derived value, not the other way around.

Keep the Source of Truth Clear

A useful mental model is that only a small set of properties should be true sources of state. Derived values should flow from those sources, not compete with them. The moment a derived field starts being manually assigned in several places, the view model usually becomes harder to reason about.

Combine helps most when it keeps that one-way flow explicit.

Common Pitfalls

The biggest mistake is using a Combine pipeline for simple synchronous logic that a computed property already handles cleanly.

Another issue is making the derived property writable from outside the type, which breaks the data flow.

A third problem is forgetting to store cancellables when using older Combine patterns that require explicit retention.

Summary

• '@Published does not have a built-in computed-property variant.'
• Use a normal computed property for simple synchronous derived state.
• Use CombineLatest plus map plus assignment when the derived value must be published reactively.
• Expose a derived publisher directly when you need the stream but not stored state.
• Keep derived published values output-only so state flow stays consistent.