When to use Delegation, Notification, or Observation in iOS

Aasim Naseem 18

Refresh your concepts about Delegation, Notification, or Observation in iOS

A common problem that we often experience when developing iOS applications, is how to allow communication between our controllers, without the need to have excessive coupling. Three common patterns that appear time and time again throughout iOS applications include:

  1. Delegation
  2. Notifications through Notification Center, and
  3. Key value observing

So why do we need these patterns and when should and shouldn’t they be used?

The following discussion of the three patterns are purely from my own experiences of developing iOS applications. I’d like to discuss why I feel a particular pattern is better than another and why I believe certain patterns are better in certain circumstances. The reasons I give are not gospel, and are just my personal opinions. Please feel free to argue and provide me with reasons and experiences you’ve had.

What is it about these three patterns?

The three patterns chosen are all ways for one object to communicate events to other objects without requiring them to be coupled. They are ways for objects to “inform” the occurrence of certain events, or more accurately, ways to allow certain events to be heard by others. This is quite a common task for objects to have to do, as without communication, controllers cannot integrate into the application. Another goal of a controller however, is to be as self contained as possible. We want our controllers to be able to exist on their own, without coupling them to any other controllers above them in our controller hierarchy. Controllers can create other controllers and communicate freely with them, but what we don’t want is controllers being tied back up to their creator. If we do couple them, then we lose their ability to be reused and lose their ability to completely control an isolated component of our application.

The three patterns all provide ways for controllers (or other objects) to communicate and be useful within an application, without the need to couple them and lose their self-containment. Whilst I’ll be describing the patterns and their use in an iOS application context, it is important to note that they do exist and are used elsewhere. The comments I make may or may not apply to their use in other contexts.


When you first start out programming iOS application, you’ll most likely notice the continued use of “delegates” throughout the SDK. The delegation pattern is not a pattern specific to iOS, but depending on what programming background you’ve had, it might not be immediately obvious as to what advantages this pattern provides, and why it seems to be used so often.

The basic idea of delegation, is that a controller defines a protocol (a set of method definitions) that describe what a delegate object must do in order to be allowed to respond to a controller’s events. The protocol is a contract where the delegator says “If you want to be my delegate, then you must implement these methods”. What this does is allows the controller to call methods on it’s delegate with the knowledge that the delegate will respond to the method calls. The delegate can be of any object type, so the controller is not coupled to a particular Object, but it can still be sure that the delegate will respond when it tries to tell it things.


  • Very strict syntax. All events to be heard are clearly defined in the delegate protocol.
  • Compile time Warnings / Errors if a method is not implemented as it should be by a delegate.
  • Protocol defined within the scope of the controller only.
  • Very traceable, and easy to identify flow of control within an application.
  • Ability to have multiple protocols defined by one controller, each with different delegates.
  • No third party object required to maintain / monitor the communication process.
  • Ability to receive a returned value from a called protocol method. This means that a delegate can help provide information back to a controller.


  • Many lines of code required to define: 1. the protocol definition, 2. the delegate property in the controller, and 3. the implementation of the delegate method definitions within the delegate itself.
  • Need to be careful to correctly set delegates to nil on object deallocation, failure to do so can cause memory crashes by calling methods on deallocated objects.
  • Although possible, it can be difficult and the pattern does not really lend itself to have multiple delegates of the same protocol in a controller (telling multiple objects about the same event)


In iOS applications there is a concept of a “Notification Center”. It is a singleton object that allows for objects to be notified of events occurring. It allows us to satisfy the goal of communicating between a controller and an arbitrary object with a low level of coupling. The basic concept of this pattern is that a controller uses a key (notification name) in order to allow other objects to hear about special events occurring within the controller. Then unbeknown to the controller, other objects (observers) can react to the notification events by registering for notifications with the same key.


  • Easy to implement, with not many lines of code.
  • Can easily have multiple objects reacting to the same notification being posted.
  • Controller can pass in a context (dictionary) object with custom information (userInfo) related to the notification being posted.


  • No compile time to checks to ensure that notifications are correctly handled by observers.
  • Required to un-register with the notification center if your previously registered object is deallocated.
  • Not very traceable. Attempting to debug issues related to application flow and control can be very difficult.
  • Third party object required to manage the link between controllers and observer objects.
  • Notification Names, and UserInfo dictionary keys need to be known by both the observers and the controllers. If these are not defined in a common place, they can very easily become out of sync.
  • No ability for the controller to get any information back from an observer after a notification is posted.


Key value observing (KVO) is a pattern in which one object can observe the value of another object’s properties to find out about changes. Where the previous two patterns (delegation and notifications) are more suited to a controller communicating with arbitrary objects, KVO is more suited to objects of any type listening for changes of another arbitrary object (not necessarily, and most often not a controller). It is a way in which we can keep our objects in sync with one another; a way in which we can make one object react when another object’s state changes. It is only used for properties and cannot be used to respond to methods or other actions.


  • Can provide an easy way to sync information between two objects. For example, a model and a view.
  • Allows us to respond to state changes inside objects that we did not create, and don’t have access to alter the implementations of (SKD objects).
  • Can provide us with the new value and previous value of the property we are observing.
  • Can use key paths to observe properties, thus nested objects can be observed.
  • Complete abstraction of the object being observed, as it does not need any extra code to allow it to be observed.


  • The properties we wish to observe, must be defined using strings. Thus no compile time warnings or checking occurs.
  • Re-factoring of properties can leave our observation code no longer working.
  • Complex “IF” statements required if an object is observing multiple values. This is because all observation code is directed through a single method.
  • Need to remove the observer when it is deallocated.

Summing up the options

With these three patterns providing both pros and cons, how do we aggregate and sum these up in order to influence which pattern to use in which situation. There is no right or wrong pattern to use. Each pattern provides a way for objects to inform other objects of events, without the need for the informer to know about the listener. Of these three patterns I think Key Value Observing has the clearest use case, and has a clear suitability to a specific requirement. The other two patterns however have very similar uses, and are often used to provide communication between controllers. So which of these two should be use when?

In my personal experience of making iOS applications, I have often seen an excessive use of the Notification pattern. I personally very much dislike using the notification center. I find it is just too hard to follow the flow of your application. Keys for the UserInfo dictionaries passed around become out of sync, and too many constants need to be defined and placed in a common place. It is very hard for developers who start work on an existing project to understand the flow of an application when the notification center is used excessively.

I believe that communication between controllers should be made very clear through the use of well named protocols and well named protocol method definitions. Making the effort to define these protocol methods will yield much easier code to read, and provide much more traceability within your app. Changes to delegate protocols and implementations will be picked up by the compiler, and if not (EG if you are using selectors) your app will at least crash during development, rather than just having things not working properly. Even in scenarios where multiple controllers need to be informed of the same event, as long as your application is well structured in a controller hierarchy, messages can be passed up the hierarchy where they can be passed back down to all controllers that need to know of the events.

Of course there are exceptions where the delegation pattern just does not fit and notifications make more sense. An example might be an event that every controller in your application needs to know of. However these types of scenarios are very rare. Another example might be in scenarios whereby you are building a framework that needs to announce events to the application it is running in.

As a rule of thumb I will only use observation, for property level events within objects that I did not code, or for property level events within model objects that are tightly bound to a view object. For all other events, I will always try to use a delegate pattern, if for some reason I can’t do that, I will first assess whether I have something critically wrong with my app’s structure, and if not, only then will I use notifications.

Comments 18

  1. My spouse and i were absolutely cheerful Emmanuel managed to deal with his analysis from
    your ideas he grabbed out of the weblog. It’s not at all
    simplistic just to continually be giving away information and facts
    which usually other folks could have been trying to sell.
    We acknowledge we have the blog owner to appreciate for this.
    The type of illustrations you’ve made, the easy web site menu, the relationships
    you help to create – it’s most wonderful, and it’s really aiding our son and our family reckon that that content is amusing, which is exceptionally pressing.
    Thanks for the whole lot!

    my blog Viag Rx Male Enhancement

  2. I leave a response each time I appreciate a post on a website or I have something to contribute
    to the conversation. Usually it is triggered by the passion displayed in the article I
    read. And after this post When to use Delegation, Notification, or Observation in iOS – Aasim's Web
    Corner. I was actually excited enough to drop a thought 🙂 I do have
    2 questions for you if you usually do not mind. Is it just me or do
    some of the responses look like coming from brain dead folks?
    😛 And, if you are writing at additional
    online sites, I’d like to keep up with you. Could you make
    a list every one of all your public sites like your Facebook page, twitter feed, or linkedin profile?

    my blog post – Oracle Leaf CBD

  3. I absolutely love your blog.. Very nice colors & theme. Did
    you create this amazing site yourself? Please reply
    back as I’m wanting to create my own blog and would love to find out where you got this from or what the theme is named.
    Many thanks!

    My webpage pf-mold.com

  4. Hi I am so delighted I found your web site, I really found you
    by error, while I was browsing on Digg for something else, Anyhow I am here now and would just like to
    say thanks a lot for a remarkable post and a all round exciting blog (I also love the theme/design), I don?t have time to look over
    it all at the minute but I have saved it and also included your
    RSS feeds, so when I have time I will be back to read much
    more, Please do keep up the awesome work.

    my website … Rapid Keto Cut Reviews

  5. I wanted to follow along and let you know how , very much I liked discovering your site today.
    I would consider it a real honor to work at my workplace and be able to make real use of the
    tips contributed on your site and also engage in visitors’ opinions like this.
    Should a position associated with guest publisher become offered at your end, please let me know.

    Feel free to surf to my blog post … Nitro Strive Nitric Oxide

  6. Someone essentially lend a hand to make critically articles I might state.
    That is the first time I frequented your website page and
    up to now? I amazed with the analysis you made to create this particular put up incredible.
    Great task!

    Have a look at my web site Libido Boost

  7. I blog quite often and I seriously appreciate your content.
    This great article has really peaked my interest.
    I’m going to book mark your blog and keep checking for new details about once a week.
    I opted in for your Feed as well.

    my web blog: DFine8 Review

  8. You’re so cool! I do not believe I have read
    through anything like that before. So wonderful to find another person with genuine thoughts on this subject.
    Seriously.. many thanks for starting this up. This website
    is one thing that is required on the internet, someone with some originality!

    Review my web-site Ann

Leave a Reply

Your email address will not be published.