{"id":49833,"date":"2025-10-29T14:16:24","date_gmt":"2025-10-29T18:16:24","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49833"},"modified":"2025-10-29T14:16:24","modified_gmt":"2025-10-29T18:16:24","slug":"swift-6-2-notificationcenter-messages","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/10\/29\/swift-6-2-notificationcenter-messages\/","title":{"rendered":"Swift 6.2: NotificationCenter Messages"},"content":{"rendered":"

Holly Borla<\/a>:<\/p>\n

\n

In Swift 6.2, the Foundation library includes a modern NotificationCenter<\/code> API that uses concrete notification types instead of relying on strings and untyped dictionaries for notification names and payloads. This means you can define a notification struct with stored properties, and observers can use the type without error-prone indexing and dynamic casting.<\/p><\/blockquote>\n\n

Apple<\/a>:<\/p>\n

In Swift, the Notification<\/code><\/a> type is nonisolated<\/code>, even in cases where it’s posted on a known isolation. To provide specific isolation information and better support Swift concurrency, NotificationCenter<\/code> defines two message types. A NotificationCenter.MainActorMessage<\/code><\/a> binds to the main actor, whereas a NotificationCenter.AsyncMessage<\/code><\/a> uses an arbitrary isolation. Frameworks extend these types to define distinct messages, typically corresponding to an existing Notification.Name<\/code><\/a>, that declare instance properties for their values instead of using a userInfo<\/code> dictionary. As a result, messages can conform to Sendable<\/code><\/a> when they either don’t use properties or contain only sendable properties.<\/p>

If your project only needs to support Swift, you can just use the Message<\/code> types. For projects with both Objective-C and Swift code, define a Notification<\/code><\/a> as well as a corresponding Message<\/code> type.<\/p><\/blockquote>\n

However, the new API is part of Foundation, not Swift 6.2, so even in a pure-Swift app you can only use it on macOS 26 and later. This is a bummer because notifications aren’t a new feature that you can make available in your app only on the latest OS. Rather, they’re central to the design of the app itself. You can’t even begin migrating your code to the new API until you drop support for all the previous OS versions.<\/p>\n\n

You can post a message with the post(_:subject:)<\/code> method, passing a message instance and optionally providing a subject. To receive messages, add an observer with the addObserver(of:for:using:)<\/code> method. The overloads of this method allow you to observe either messages from a single object or from any object of a given type. Observation ends when you discard the token returned from addObserver(of:for:using:)<\/code> or after an explicit call to removeObserver(_:)<\/code><\/a>.<\/p>

You can also receive messages as an AsyncSequence<\/code><\/a> with the messages(of:for:bufferSize:)<\/code> methods.<\/p><\/blockquote>\n\n

SF-0011<\/a>:<\/p>\n

The optional lookup type, NotificationCenter.MessageIdentifier<\/code>, provides an SE-0299<\/a>-style ergonomic experience for finding notification types when registering observers.<\/p>

[…]<\/p>

Optional bi-directional interoperability with the existing Notification<\/code> type is available by using the Notification.Name<\/code> property and two optional methods, makeMessage(:Notification)<\/code> and makeNotification(:Self)<\/code>[…]<\/p>

[…]<\/p>

Observers called via the existing, pre-Swift Concurrency .post()<\/code> methods are either called on the same thread as the poster, or called in an explicitly passed OperationQueue<\/code>.<\/p>

However, users can still adopt Message<\/code>-style types with pre-Swift Concurrency .post()<\/code> calls by providing a Message<\/code>-style type with the proper Notification.Name<\/code> value and picking the correct type between MainActorMessage<\/code> and AsyncMessage<\/code>.<\/p><\/blockquote>\n\n

See also: Fatbobman<\/a>.<\/p>\n\n

Previously:<\/p>\n