My objection is to RootElement and QuickDialogController. What happens if you have to present a screen from multiple places? Or if you need to modify it at a later date, to, say, add another field?

For example: Say you have a login screen. And now you want to add a field to ask the user for another bit of information. With your design, you have to know everywhere that you can possibly log in from. Or, you have to add a method somewhere to set up the login view and then push it. And at that point, you might as well just make a separate controller to control everything. Which brings us back to tableView:cellForRowAtIndexPath:.

What you're saying though is not really related to adding/removing cells. I'm not saying you shouldn't create UIViewControllers for specific things, actually its quite the oposite, I think you should have as many controllers as possible, so that they're really small. Funny your example is a login screen, bcse that's the example in my samples on the project. Take a look at the code: it's very simple, and it mostly has to do with the actions that will happen as a result of the form, instead of cell creation: https://github.com/escoz/QuickDialog/blob/master/sample/Logi...

I see this as a much cleaner approach to do exactly the same thing, with the benefit that a lot of the code can be reusable. As a developer, you can spend a lot less time implementing plumbing code to get the cells and fields displayed, and instead focus on how they're used.