What's the difference between data source and delegate?

The datasource supplies the data, the delegate supplies the behavior.

In MVC, datasource is in the model layer and the delegate is in the control layer.

Actually, on second thought, the datasource is usually controller that is lower down, closer to the model. I don't think I've ever used a model object as my datasource.

The delegate and datasource patterns are largely independent, and orthogonal:

The delegate pattern is very common in Cocoa and allows a delegate (any instance implementing the informal delegate protocol prior to OS X 10.6, or the formal delegate @protocol in 10.6 and later) to modify the behavior of an object instance. This pattern is often used instead of subclassing: instead of subclassing a class to change its behavior, you supply a delegate that responds to the appropriate methods. Classes that use delegates send messages to their delegate at contracted events. The API between class and delegate is defined by the class and is different for each class that uses the pattern, but the API generally consists of messages asking the delegate how to handle a particular event. One advantage of the delegate pattern over subclassing is that a class may implement multiple delegate protocols, allowing its instances to act as delegate for multiple classes. Similarly, an object instance can be the delegate for multiple other objects (hence most delegate APIs pass the object as the first argument to each message in the API). The delegate pattern is not as common in other UI frameworks (though Qt does use the delegate pattern in its Model/View framework), and is not the same as .Net/CLR delegates which are essentially typed function pointers.

The data source pattern is often used by NSView sub-classes in Cocoa that have complex state data such as NSBrowser, NSTableView, NSOutlineView, etc. The data source protocol defines an API that instances of these (and other) classes may use to get the data to display in the view. Although the NSController and Cocoa Bindings architectures have replaced many uses of the data source pattern, it's still common and very powerful. Like the delegate pattern described above, part of its power comes from an object being able to act as the data source for multiple data-source-using instances (and possibly even instances of multiple classes that have different data source protocols). The data source pattern is used commonly in other UI frameworks, such as Qt (in the Model/View framework where the model is analogous to the data source) and WPF/Silverlight (where the data source might be more closely analogous to the view model).

To make it short:

Delegate relates to the UI and User actions against the cells and table.

common methods: willSelectRow, didSelectRow, willDisplay, heightForRow, willBeginEditingAt

Data Source deals with the editing, population and displaying of data on the tableview.

common methods canEditRowAt, commit, titleForHeaderInSection, cellForRowAt, numberOfSections, sectionIndexTitles

Both are Protocol, now the main intension of Protocol is to keep an universal coding practice, or same coding practice for all(to my understanding). Suppose I am creating a tableView without a UITableViewDataSource & UITableViewDelegate, I would create the tableView such a way that you woud not. Thats where Protocol comes, apple created some set of rule or protocol and everybody have to follow that. Now DataSource & Delegate are obviously Protocol, seeing the name you could understand DataSource deals with something like numberOfRowsInSection, cellForRowAtIndexPath, numberOfSections of tableView where some kind of data is being taken/processed, and Delegates are didSelectRow, willSelectRow, heightForRow etc of tableView where its related with some kind of UI change/action. So its just naming convention nothing hypothetical to keep the task separate. As @kubi said earlier: The datasource supplies the data, the delegate supplies the behaviour.