NSNotificationCenter
Object Passing
iOS Development
Swift Programming
Objective-C

How to pass object with NSNotificationCenter

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

NSNotificationCenter (modern NotificationCenter) lets you pass context using the object parameter and/or userInfo dictionary. The right choice depends on whether you need a single sender reference, multiple payload fields, or type-safe wrappers. Most bugs come from inconsistent naming, force-casting, and observer lifecycle issues.

Core Sections

1) Post notification with object

swift
1NotificationCenter.default.post(
2    name: Notification.Name("ProfileUpdated"),
3    object: profile
4)

Observer side:

swift
1NotificationCenter.default.addObserver(
2    forName: Notification.Name("ProfileUpdated"),
3    object: nil,
4    queue: .main
5) { note in
6    if let profile = note.object as? UserProfile {
7        print(profile.displayName)
8    }
9}

2) Pass structured payload with userInfo

swift
1NotificationCenter.default.post(
2    name: Notification.Name("ProfileUpdated"),
3    object: nil,
4    userInfo: ["userId": userId, "source": "settings"]
5)

Read payload safely:

swift
if let userId = note.userInfo?["userId"] as? String {
    // handle update
}

3) Best practice: typed notification wrappers

Create name constants to avoid stringly-typed errors.

swift
extension Notification.Name {
    static let profileUpdated = Notification.Name("profileUpdated")
}

Use these constants across post/observe calls.

4) Observer lifecycle and leaks

For block observers, store tokens and remove when appropriate.

swift
1var token: NSObjectProtocol?
2
3token = NotificationCenter.default.addObserver(...)
4
5if let t = token {
6    NotificationCenter.default.removeObserver(t)
7}

With selector observers, unregister in deinit when required.

Verification Workflow and Operational Hardening

After implementing the fix, validate with a repeatable workflow rather than ad hoc manual checks. A reliable approach is: reproduce baseline, apply one focused change, then verify both expected behavior and nearby edge cases. This keeps debugging causal and makes reviews easier because every observed improvement is traceable to a specific diff.

A simple validation loop:

bash
1# 1) capture baseline output
2./run_case.sh > before.txt
3
4# 2) apply targeted fix from this article
5# edit code/config only in relevant area
6
7# 3) verify after-state and compare
8./run_case.sh > after.txt
9diff -u before.txt after.txt

For codebases with automated tests, immediately translate the reproduced issue into a regression test. This is the fastest way to prevent recurrence after refactors, dependency upgrades, or runtime migrations.

bash
1# typical quality gate sequence
2./lint.sh
3./test.sh
4./smoke.sh

Edge-case validation is essential. Many failures appear only on boundary inputs such as empty collections, null values, unusual encodings, large payloads, or high concurrency. Build a compact table of edge scenarios with expected outcomes, then run it in local and CI environments. This catches hidden assumptions early and reduces production surprises.

Environment parity also matters. A fix that works locally can fail elsewhere due to version differences, OS behavior, architecture (x86 vs ARM), filesystem semantics, or network policy. Capture runtime metadata alongside results so troubleshooting stays grounded in facts.

bash
1python --version
2node --version
3java -version
4git rev-parse --short HEAD

Before rollout, define rollback criteria and observability signals. Decide in advance which metrics/logs indicate success or regression, and document the rollback command path for on-call responders. Teams recover faster when fallback steps are predefined instead of improvised during incidents.

Finally, isolate functional fixes from broad refactors. Small, focused commits are easier to review, bisect, and revert safely. If normalization, formatting, or dependency upgrades are required, ship them in separate commits to keep risk controlled and diagnosis straightforward.

Common Pitfalls

  • Force-casting object or userInfo values and crashing on mismatch.
  • Reusing raw string notification names inconsistently.
  • Passing large mutable objects without ownership/lifecycle clarity.
  • Forgetting to remove observers in long-lived components.
  • Mixing sender object semantics with payload semantics ambiguously.

Summary

To pass objects with NotificationCenter, use object for single sender/reference and userInfo for structured payloads. Standardize names and decode payloads safely to prevent runtime crashes. Correct observer lifecycle management keeps notification code stable and leak-free.

A practical way to keep this solution robust over time is to add one focused regression test and one edge-case test that represent your real production data shape. Re-run those checks whenever dependencies, runtime versions, or infrastructure settings change. This small maintenance habit catches compatibility drift early and prevents recurring incidents that otherwise look like random regressions.


Course illustration
Course illustration

All Rights Reserved.