The problem of messages sent to deallocated objects isn't unique to NSNotifications, the same thing can happen with calls to delegates[1]. This problem can easi

The problem of messages sent to deallocated objects isn't unique to NSNotifications, the same thing can happen with calls to delegates[1]. This problem can easily be solved by (a) using weak references, or (b) by searching your code for "addObserver" and making sure there is a matching "removeObserver" for every call. While I agree with the author that often delegates are a nicer pattern, I wouldn't go as far as calling NSNotificationCenter an anti-pattern. I also think that limiting its use to global notifications is not good advise. My advise for using NSNotifications is whenever you want loose coupling between objects. For example, I have an app that displays an iTunes-like status view at the top of the window. I don't want all the query objects and the status view tightly coupled. Instead, my query objects post notifications when the status changes, and the status view observes them. Using notifications lets me separate concerns, and avoid coupling between model and view layers. Also, another powerful feature of NSNotifications is that an observer can decide on its own when it is no longer interested in notifications. When you have block-based completion handlers, there's usually no way to unregister a completion handler. This can lead to crashes as well, when a long-running request times out after the user has already closed the window. [1]: There was a pretty severe bug in OS X 10.10 that caused views to be retained after their window was closed, so that many apps all of the sudden crashed when the views sent messages to their delegates which were deallocated. A workaround was to make sure to make sure that controllers call setDelegate:nil on their views in the dealloc method -- just like with NSNotificationCenter.