@Published: 概要、動作原理、適用方法

@Publishedとは？

@Published はCombineモジュールで定義されたproperty wrapperで、クラスのプロパティの変更についてサブスクライバーに自動的に通知する機能を追加します。これはクラス内でのみ（構造体では不可）、ObservableObject プロトコルに準拠するクラスのプロパティにのみ使用できます。

@Published プロパティの値が変更されると、Combine はドル記号プレフィックスを介してアクセス可能な組み込み publisher を通じてイベントを生成します: $propertyName。この publisher は ObservableObjectPublisher であり、ObservableObject 自体に属します。SwiftUI は、ビューが @ObservedObject または @StateObject を使用するときに自動的にこれにサブスクライブし、オブジェクト内の @Published プロパティが変更されるたびにビューを再描画します。

Matt Neuburg の著書 “IOS 18 Programming Fundamentals with Swift” (2025) によると、@Published は willSet パターンの便利なラッパーであり、自動的に objectWillChange.send() を呼び出します。実際には、コンパイラは @Published を willSet オブザーバー付きの computed property に展開するため、手動実装と比較してランタイムオーバーヘッドがゼロになります。

変更がインターフェースに反映される必要があるすべての ObservableObject プロパティに @Published を使用してください。UI に影響しないプロパティについては、@Published のない通常の stored property を使用すると、不要な再描画が減ります。

@Publishedの動作原理

@Published はコンパイル時に 2 つの主要な要素を生成します。1つ目は、新しい値を書き込む前に objectWillChange.send() を呼び出す willSet オブザーバー付きの stored property です。2つ目は、Published.Publisher を返すプロジェクション $propertyName で、Combine パイプラインで直接使用できます。

3 つのプロパティを持つ Settings クラスを考えてみましょう: 2 つの @Published と 1 つの通常のプロパティ:

class Settings: ObservableObject {
    @Published var username: String = "Guest"
    @Published var isDarkMode = false
    var lastLogin: Date = Date()  // without @Published
}

username または isDarkMode が変更されると、SwiftUI は Settings インスタンスにサブスクライブしているすべてのビューを再描画します。lastLogin の変更は再描画をトリガーしません。通常のプロパティの変更についてサブスクライバーに手動で通知する必要がある場合は、willSet オブザーバーで objectWillChange.send() を呼び出すことができます。

重要な詳細: @Published は、プロパティが直接代入された場合にのみ変更を公開します。プロパティが参照型（クラス）であり、参照を置き換えずに内部状態が変更された場合、@Published はそれを検出しません。そのような場合は、手動イベント送信または値型（構造体）への切り替えが必要です。

@PublishedとCombine

@Published は Combine と緊密に統合されています — 各 @Published プロパティは、プロジェクション $propertyName を介してアクセス可能な publisher を自動的に提供します。これにより、フィルタリング、変換、結合、遅延値処理に Combine オペレーターを使用できます。

典型的なシナリオは、デバウンスを使った検索です。入力フィールドは @Published プロパティ searchText にバインドされていますが、サーバーリクエストは 300 ミリ秒の一時停止後にのみ送信する必要があります。$searchText.debounce を使用した Combine は、これを 1 行で解決します:

class SearchViewModel: ObservableObject {
    @Published var searchText = ""
    @Published var results: [String] = []
    private var cancellables = Set<AnyCancellable>()

    init() {
        setupSearchSubscription()
    }

    private func setupSearchSubscription() {
        $searchText
            .debounce(for: .milliseconds(300), scheduler: RunLoop.main)
            .removeDuplicates()
            .sink { [weak self] text in
                self?.performSearch(text)
            }
            .store(in: &cancellables)
    }

    private func performSearch(_ text: String) { }
}

John Sundell の記事 (Swift by Sundell, 2024) によると、@Published と Combine の組み合わせは、SwiftUI アプリケーションにおけるリアクティブパイプラインの標準パターンです: バリデーション、debounce、throttle、combineLatest、他の publisher とのマージ。@Published は命令型 UI コードとリアクティブな Combine の間の橋渡し役として機能します。

@Published vs @Observable マクロ

iOS 17 のリリースに伴い、Apple は @Observable マクロを導入しました。これは ObservableObject と @Published を使わないリアクティビティの代替アプローチを提供します。@Observable は書き込みレベルではなく読み取りレベルでプロパティへのアクセスを自動的に追跡し、より正確な再描画を提供します — 特定の変更されたプロパティを読み取るビューのみが更新されます。

しかし、これは @Published が廃止されたことを意味するわけではありません。@Published は Combine パイプラインの統合が必要な場合に引き続き必要です — プロジェクション $propertyName は @Observable にはない publisher を提供します。さらに、iOS 16 以下との後方互換性のために、@Published+ObservableObject が唯一のオプションです。Apple WWDC 2023 セッション “Discover Observation in SwiftUI” によると、Apple は新しいプロジェクトには @Observable を推奨していますが、既存のコードと Combine シナリオについては @Published のサポートを明示的に維持しています。

実際には、多くのプロジェクトはハイブリッドアプローチを使用しています: 新しいデータモデルは @Observable を使用し、@Published を持つ既存の ObservableObject はリファクタリングせずに残します。@Published は、公開の細かい制御が必要な場合にも不可欠です — たとえば、複数のプロパティのバッチ更新が完了するまで通知を遅延させる場合などです。

@Publishedのよくある間違い

最初の間違いは 構造体で @Published を使用する ことです。コンパイラはエラーを発行します: “Property wrapper cannot be applied to a computed property” または “‘@Published’ is only available on members of a class.” ObservableObjectPublisher は各インスタンスで一意でなければならないクラスであるため、@Published には参照セマンティクスが必要です。

2 番目の間違いは、参照を置き換えずに参照プロパティの内容を変更する ことです。@Published プロパティが配列型 [String] で、array.append("new") を呼び出した場合、配列への参照が変更されていないため、@Published は変更を検出しません。解決策: プロパティに新しい値を代入する array = array + ["new"] か、手動で objectWillChange.send() を使用します。

3 番目の間違いは @Published プロパティの過剰な数 です。各 @Published プロパティは、そのプロパティを読み取るビューだけでなく、ObservableObject にサブスクライブしているすべてのビューの再描画をトリガーします。Point-Free (2025) によると、1 つの大きな ObservableObject を @StateObject と @EnvironmentObject を持つ複数の小さな ObservableObject に分割すると、不要な再描画が減り、パフォーマンスが向上します。

コード例

最初の例は、バリデーション付きの 登録フォーム ViewModel です。@Published プロパティ email と password は、Combine パイプラインを介してバリデーションエラーの表示をトリガーします:

class RegistrationViewModel: ObservableObject {
    @Published var email = ""
    @Published var password = ""
    @Published var emailError: String?
    @Published var isFormValid = false
    private var cancellables = Set<AnyCancellable>()

    init() {
        $email
            .map { $0.contains("@") ? nil : "Invalid email" }
            .assign(to: &$emailError)
            .store(in: &cancellables)

        $email.combineLatest($password)
            .map { !$0.isEmpty && !$1.isEmpty }
            .assign(to: &$isFormValid)
            .store(in: &cancellables)
    }
}

2 番目の例は、参照要素のコレクションに対する 手動公開 です。要素内の変更のたびに配列全体を置き換える代わりに、objectWillChange.send() が使用されます:

class TodoItem {
    var title: String
    var isDone = false
    init(title: String) { self.title = title }
}

class TodoListViewModel: ObservableObject {
    @Published var items: [TodoItem] = []

    func toggle(item: TodoItem) {
        item.isDone.toggle()
        self.objectWillChange.send()  // manual notification
    }
}

3 番目の例は、Combine を介した @Published プロパティへの Assign です。Swift 5.9 の新しい構文を使用すると、Optional ラッパーなしでプロジェクション assign(to: &$property) を介して直接代入できます。これは、サブスクリプションを作成せずに publisher を @Published プロパティに接続する最も短い方法です。