I'll be honest, the whole delegation thing is confusing me a little, but I'm trying to get better.
Right now, I have a UITableView with a list of tasks, and I have a + button that brings up a modal view to add a new task. You can also tap on each task to change the name.
How would I implement this using delegation? Obviously the modal view results will change the root UITableView (add a new cell) so I assume delegation is the best option. And same for the editing.
Do I do two separate ones? One? Could someone conceptually show me how the delegation scheme would look?
I would phrase this a bit differently/more simplistically: delegation is one of several ways to allow classes to talk to each other. It is not unique to Objective-C, and it is not always the right tool for every job.
TL;DR: Don't worry about it - yet!
Don't worry about what delegation is yet; it's like asking how knives are made when you really just want to cut down a tree. In this case, you will learn more (and faster) by doing, and Apple's UITableView docs are great:
What you're trying to do is VERY structured and you won't need to invent any new code - in fact, you basically can't; Apple has already decided how UITableView works, so understanding the theory behind it won't help you (yet).
So for now, fear not and just hit the link above - maybe Google some UITableView tutorials - and when you encounter specific issues (and you DEFINITELY will), post about those here on SO. :)
For Later: A 1-minute Overview of Delegation
..and then one day a time will come that you need to start making your own classes & subclasses that need to talk to each other. THAT is when you need to know about Delegation!
Imagine you have an instance of a UIViewController class (which I'll just call 'You') that shows a UITableView ('Table'). In that case, Apple designed UITableView to use delegation so that Table can ask You a bunch of questions. Table might ask You: how many rows do I need to show? How tall should each row be? What should the cell in row 72 look like? You know this, but Table doesn't, so Table will ask you for the answer via Delegation/Data Source methods. Your code responds with the answer.
Even better: classes can be forced to tell You things! For example: 'the user just tapped a cell', or 'I'm about to dismiss myself', or 'the screen just rotated'. The beauty of these methods is that it allows You to react to and prepare for all manner of critical events. This is a HUUUUUUUGE part of iOS programming, and you will encounter it frequently.
That is Delegation in a nutshell, and there are even more awesome ways for classes to talk to each other - e.g. blocks, and even direct variable storage in some cases.
And if you really, truly want to know more, even though I wouldn't recommend it yet, you can check out another good Apple document, here: