Here is the most helpful explanation I found so far.
My favorite way to explain how delegates work involves animals.
Let’s say you are going to create a particular bird. You start with a predefined class definition of a bird (provided in the existing framework as, say, CFBird). The existing framework class assumes all birds have certain things in common — they hatch and grow the same, poop the same, fly the same, and lay eggs the same way, etc. (tee hee, I said poop. 
) But different birds look different, are different sizes, chirp differently, eat different things, and may mate differently.
So let’s say Apple provided you with the basic bird class (with hatching, growing, pooping, flying and egg-laying behavior already built in).
Here now in this more advanced age of object-oriented design, there’s a concept (design pattern) called “delegation” and it’s a cool way to easily implement custom classes, assuming ahead of time that you’ll likely never need to worry about anything else about creating birds other than specifying how they differ from each other — how they look (size and color) and how they chirp, eat and mate.
So, the people who designed the CFBird class have set up a “protocol” which specifies the “delegate methods” (kinda like “callbacks” in C) which is all your new class will need to implement to create your custom bird, and you’re done! Basically the class is going to call into your code when your particular bird is drawn, when it chirps, eats and mates. These tasks are “delegated” to you in your subclass of CFBird.
Everything else is handled for you, and you only need to concern yourself with what is different about your bird, and forget about what is the same amongst all birds, simplifying your life and making things more consistent.
In your code, when you specify your new class of bird, in the @implementation you’ll make reference to a <protocol>, and by doing so you are telling the system that you agree to implement the methods specified in that protocol which will detail exactly how your particular bird is going to look, chirp, eat, and mate. Done and done.
The subclassing comes first, and the possible delegate methods follow if you specify a protocol to follow.
——
Now, for instance, say you want to implement a particular bird, say a “mockingbird.” You subclass CFBird, and agree to implement the <CFBirdDelegate> protocol, and your class implements the predefined methods you just agreed to, called draw, chirp, eat and mate. In the “delegate” methods you write, you’ll draw a medium sized bird with grey and white wings, and when the message comes and your object is asked to chirp your class will chirp mostly at night and change it’s song constantly and be annoyingly loud, it will eat bugs, and when it goes to mate it will flap its wings and dance in a particular way.
Now let’s say you want to implement a “yellowBelliedSapSucker.” In a separate file in Xcode you’ll subclass CFbird, and in your “delegate” methods in that .m file, you’ll draw a medium sized bird with a yellow belly, and when it’s asked to chirp your class will chirp briefly and only at sunrise, it will eat sap, and when it goes to mate it will do nothing in particular and you just let the default behavior stand.
Are you getting it?