Archive for October 29, 2025

Wednesday, October 29, 2025

Swift 6.2: NotificationCenter Messages

Holly Borla:

In Swift 6.2, the Foundation library includes a modern NotificationCenter 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.

Apple:

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

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

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.

You can post a message with the post(_:subject:) method, passing a message instance and optionally providing a subject. To receive messages, add an observer with the addObserver(of:for:using:) 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:) or after an explicit call to removeObserver(_:).

You can also receive messages as an AsyncSequence with the messages(of:for:bufferSize:) methods.

SF-0011:

The optional lookup type, NotificationCenter.MessageIdentifier, provides an SE-0299-style ergonomic experience for finding notification types when registering observers.

[…]

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

[…]

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

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

See also: Fatbobman.

Previously:

Swift 6.2

Holly Borla:

InlineArray is a new fixed-size array with inline storage for elements, which can be stored on the stack or directly within other types without additional heap allocation.

[…]

The new Span type offers safe, direct access to contiguous memory. Span maintains memory safety by ensuring the memory remains valid while you’re using it.

[…]

Swift 6.2 introduces opt-in strict memory safety, which flags uses of unsafe constructs, so you can replace them with safe alternatives or explicitly acknowledge them in source code.

[…]

Swift 6.2 significantly improves clean build times for projects that use macro-based APIs.

Most of these proposals have been previously discussed here. Strict memory safety is in SE-0458:

This proposal introduces an opt-in strict memory safety checking mode that identifies all uses of unsafe behavior within the given module. There are several parts to this change:

  • A compiler flag -strict-memory-safety that enables warnings for all uses of unsafe constructs within a given module. All warnings will be in the diagnostic group StrictMemorySafety, enabling precise control over memory-safety-related warnings per SE-0443. When strict memory safety is enabled, the StrictMemorySafety feature will be set: #if hasFeature(StrictMemorySafety) can be used to detect when Swift code is being compiled in this mode.
  • An attribute @unsafe that indicates that a declaration is unsafe to use. Such declarations may use unsafe constructs within their signatures.
  • A corresponding attribute @safe that indicates that a declaration whose signature contains unsafe constructs is actually safe to use. For example, the withUnsafeBufferPointer method on Array has an unsafe type in its signature (self), but is actually safe to use because it handles safety for the unsafe buffer pointer it vends to its closure argument. The closure itself will need to handle the unsafety when using that unsafe buffer pointer.
  • An unsafe expression that marks any use of unsafe constructs in an expression, much like try and await.
  • Standard library annotations to identify unsafe declarations.

SE-0477:

A new string interpolation syntax for providing a default string when interpolating an optional value.

Keith Harrison:

One issue is that I’ve been unable to get this to work with localization. The problem seems to be that LocalizedStringKey doesn't’t support the default value parameter.

Paul Hudson (Mastodon, Hacker News):

SE-0451 dramatically expands the range of characters we can use to create identifiers – the names of variables, functions, enum cases and similar – so we can name them pretty much however we want when placed inside backticks.

[…]

SE-0459 makes the type returned by enumerated() conform to Collection.

[…]

SE-0479 extends Swift’s key paths to support methods alongside the existing support for properties and subscripts, which, along with SE-0438 introduced in Swift 6.1, promises to round out what key paths can do.

[…]

SE-0419 introduces a new Backtrace struct, which is capable of capturing data about the call stack of our app at any given moment – the exact sequence of function calls leading up to the current point.

[…]

SE-0448 expands Swift’s regular expression support to include lookbehind assertions, which allow us to check if a specific pattern appears immediately before the current position in the string, without including it in the matched text.

[…]

It’s SE-0476, which introduces a new @abi attribute that makes it easier for ABI-stable library authors to make changes to their libraries without breaking things.

Matt Gallagher (CwlDemangle):

It looks like Swift 6.2 will finally let us access the built-in Swift demangling so we can turn runtime mangled names into something human readable without resorting to half-assed third party libraries (like my own CwlDemangle).

Technically, the demangling is part of the new Backtrace API but it offers SymbolicatedBacktrace.Symbol with a lazily evaluated name that performs demangling on the rawName.

It doesn’t expose DemangleOptions but it’s a huge improvement.

Swift 6.2 also includes some other big features, which I’m going to write separate posts about:

Previously:

Imgur Blocks UK Users Over Age Verification

Imgur TOS Update (2021, via Hacker News):

No nudity or sexually explicit content.

Provocative, inflammatory, unsettling, or suggestive content should be marked as Mature.

No hate speech, abuse or harassment.

No content that condones illegal or violent activity.

Connor Jones (Hacker News):

The UK’s data watchdog has described Imgur’s move to block UK users as “a commercial decision” after signaling plans to fine parent company MediaLab.

It opened an investigation into various companies, including TikTok and Reddit, in March, focused on how these major platforms handle children’s data and verify their ages, which led to issuing a notice of intent to fine MediaLab in September.

[…]

Capel also hinted that even if Imgur continues to block UK users, the ICO may still seek to penalize its parent company.

[…]

The ICO said the investigation was instead related to its Children's code strategy, which it first published in 2021 [rather than the Online Safety Act].

Previously: