How to subclass custom UIViewController in Swift?

So, you have your base class:

class UsersViewControllerBase: UIViewController, UITableViewDelegate, UITableViewDataSource {
    @IBOutlet weak var segmentedControl: UISegmentedControl!
    @IBOutlet weak var tableView: UITableView!
    //implementation of delegates
}

[A] And your subclass: class UsersViewController: UsersViewControllerBase { var text = "Hello!" }

[B] A protocol that your subclass will be extending:

protocol SomeProtocol {
    var text: String? { get set }
}

[C] And some class to handle your data. For example, a singleton class:

class MyDataManager {

    static let shared = MyDataManager()
    var text: String?

    private init() {}

    func cleanup() {
        text = nil
    }
}

[D] And your subclass:

class UsersViewController: UsersViewControllerBase {

    deinit {
        // Revert
        object_setClass(self, UsersViewControllerBase.self)
        MyDataManager.shared.cleanup()
    }
}

extension UsersViewController: SomeProtocol {
    var text: String? {
        get {
            return MyDataManager.shared.text
        }
        set {
            MyDataManager.shared.text = newValue
        }
    }
}

To properly use the subclass, you need to do (something like) this:

class TestViewController: UIViewController {
    ...
    func doSomething() {
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        //Instantiate as base
        let usersViewController = storyboard.instantiateViewControllerWithIdentifier("UsersViewControllerBase") as! UsersViewControllerBase
        //Replace the class with the desired subclass
        object_setClass(usersViewController, UsersViewController.self)
        //But you also need to access the property 'text', so:
        let subclassObject = usersViewController as! UsersViewController
        subclassObject.text = "Hello! World."
        //Use UsersViewController object as desired. For example:
        navigationController?.pushViewController(subclassObject, animated: true)
    }
}

EDIT:

As pointed out by @VyachaslavGerchicov, the original answer doesn't work all the time so the section marked as [A] was crossed out. As explained by an answer here:

object_setClass in Swift

... setClass cannot add instance variables to an object that has already been created.

[B], [C], and [D] were added as a work around. Another option to [C] is to make it a private inner class of UsersViewController so that only it has access to that singleton.

When you instantiate a view controller via instantiateViewControllerWithIdentifier, the process is essentially as follows:

• it finds a scene with that identifier;
• it determines the base class for that scene; and
• it returns an instance of that class.

And then, when you first access the view, it will:

• create the view hierarchy as outlined in that storyboard scene; and
• hook up the outlets.

(The process is actually more complicated than that, but I'm trying to reduce it to the key elements in this workflow.)

The implication of this workflow is that the outlets and the base class are determined by the unique storyboard identifier you pass to instantiateViewControllerWithIdentifier. So for every subclass of your base class, you need a separate storyboard scene and have hooked up the outlets to that particular subclass.

There is an approach that will accomplish what you've requested, though. Rather than using storyboard scene for the view controller, you can instead have the view controller implement loadView (not to be confused with viewDidLoad) and have it programmatically create the view hierarchy needed by the view controller class. Apple used to have a nice introduction to this process in their View Controller Programming Guide for iOS, but have since retired that discussion, but it can still be found in their legacy documentation.

Having said that, I personally would not be compelled to go back to the old world of programmatically created views unless there was a very compelling case for that. I might be more inclined to abandon the view controller subclass approach, and adopt something like a single class (which means I'm back in the world of storyboards) and then pass it some identifier that dictates the behavior I want from that particular instance of that scene. If you want to keep some OO elegance about this, you might instantiate custom classes for the data source and delegate based upon some property that you set in this view controller class.

I'd be more inclined to go down this road if you needed truly dynamic view controller behavior, rather than programmatically created view hierarchies. Or, even simpler, go ahead and adopt your original view controller subclassing approach and just accept that you'll need separate scenes in the storyboard for each subclass.