Reddit mentions of iOS 5 Programming Pushing the Limits: Developing Extraordinary Mobile Apps for Apple iPhone, iPad, and iPod Touch

The argument is to treat your UITableViewCell as the "Controller" in this scenario. Understanding composition correctly is the key here.

In classical MVC, an object (controller or model or view) should not know about details of a contained (composited) object. For example,

if you have a model "Person" that has a

Person

• Name
  
• DOB
  
• Manager
  
  • Name
    
  • DOB
    
    Accessing something like self.person.manager.dob from any class is probably not a good idea.
    
    By making the "PersonList"ViewController access details of a single person shoving it into the cell, (in the cellForRowAtIndexPath method) you precisely do this.
    This also happens to bloat the "PersonList"ViewController because now this "PersonList"ViewController does the job of both a "Person"ViewController and a "PersonList"ViewController.
    
    By delegating this task to another object (in this case, it happens to be PersonTableViewCell), you help yourself by avoiding the dreaded massive view controller problem.
    "
    Most iOS developers often think of UIViewController as the "C" and UITableViewCell as the "V" in MVC. My heuristic is, generic table view cells (UITableViewCell used as is) should be treated as a view. But if you write a custom subclass of a UITableViewCell, it is probably a controller because you are not writing cell drawing/rendering code. This is precisely what we wrote in the iOS 5 Programming Pushing the Limits book (Page 95) https://www.amazon.com/dp/1119961327/