NotificationCenter delivery order for concurrent multi-threaded posts

Answer the exact question first

There is no documented Apple API that serialises delivery of notifications posted from different threads. The only guarantee is that the call to post is synchronous on the caller’s thread – the observers that were registered with a non‑nil queue are executed asynchronously on that queue, but the order in which post calls finish is still undefined when multiple threads are involved.

Why this matters

• No global order guarantee – the framework does not keep a global queue of posts, so the sequence in which notifications reach observers depends on the order in which post calls are executed by the OS scheduler.
• Observers on a queue – if you register an observer with a non‑nil queue, the callback runs asynchronously on that queue. That does not affect the ordering of the post calls themselves.
• Dead‑lock risk with sync – calling post synchronously on a serial queue from within an observer that is already executing on that same queue will deadlock. Using async to enqueue the post avoids this problem.

Recommended architectural pattern

The most straightforward way to obtain a deterministic sequence is to funnel every post through a single serial execution context (a DispatchQueue or an actor). Within that context you can optionally attach a monotonically increasing sequence number or timestamp to each notification before it is forwarded to NotificationCenter. Because the context is serial, the order in which the notifications leave that context is the order in which they will be delivered to observers.

Example using a serial DispatchQueue:

final class OrderedNotifier {
    private let queue = DispatchQueue(label: "com.example.ordered-notifier")
    private let center = NotificationCenter.default

    func post(name: Notification.Name, object: Any? = nil, userInfo: [AnyHashable: Any]? = nil) {
        // All callers dispatch to the same serial queue.
        queue.async {
            let info = userInfo ?? [:]
            // Optional: add a sequence number if you need to verify order.
            self.center.post(name: name, object: object, userInfo: info)
        }
    }
}

When an observer is registered with a non‑nil queue, it will still run asynchronously on that queue, but the order of notifications it receives will match the order in which OrderedNotifier enqueued them.

Alternatively, with Swift Concurrency you can use a single actor that serialises all posts:

actor OrderedNotifier {
    private let center = NotificationCenter.default

    func post(name: Notification.Name, object: Any? = nil, userInfo: [AnyHashable: Any]? = nil) async {
        // The actor guarantees that posts are executed in the order the method is called.
        let info = userInfo ?? [:]
        center.post(name: name, object: object, userInfo: info)
    }
}

Callers simply await the actor method; the actor’s single execution context enforces ordering without blocking the caller’s thread.

What this pattern does NOT guarantee

• It does not make the order of post calls deterministic across threads without an external sequence. If you need a strict order, you must attach a sequence number or timestamp yourself and sort before delivery.
• It does not prevent observers from performing heavy work on the same serial queue. Offload expensive work to a different queue (e.g., addObserver(forName:object:queue:using:) with a dedicated concurrent queue) to keep the serial path free.
• It does not replace NotificationCenter with a typed stream; for very high throughput you might consider AsyncStream or Combine’s PassthroughSubject as an alternative, but those also require a single producer to preserve order.

Verification steps (safe, scoped)

1. Spawn several background threads that each call OrderedNotifier.post with a unique sequence number in the userInfo dictionary.
2. Register a single observer on the main queue that records the received sequence numbers.
3. After all posts have been dispatched, sort the recorded sequence numbers and verify that they form a continuous increasing sequence.
4. To test dead‑lock safety, have an observer that, when triggered, calls OrderedNotifier.post again. The call should be enqueued asynchronously and not block the observer.
5. Profile the serial queue under expected load with Instruments Time Profiler to ensure it does not become a bottleneck.

One missing diagnostic detail

What is the expected peak number of post calls per second and the typical amount of work each observer performs? If the throughput is very high or observers do heavy processing, the serial queue may become a performance limiter and you might need to switch to a typed async sequence or Combine subject that can handle high‑rate producers while preserving ordering.