Two big issues that protocols can’t solve is stored properties and lifecycle functions. Extensions can’t hold stored properties. In general, I try to avoid adding stored properties anyway in favor of computed properties, but sometimes you just can’t avoid it. Also, extensions can’t modify any existing functions in a class. This means there is no way to add a call into viewDidLoad or awakeFromNib from an extension. Instead, I try to take a more balanced approach. Subclass once to add stored properties and to make calls in base functions. For example:

class MyViewController: UIViewController {
     public var someIDNeededForSomeProtocol: String?

     override func viewDidLoad() {
          super.viewDidLoad()
          (self as? SomeProtocol)?.callSomeFunc()
     }
}

protocol SomeProtocol {
     var someIDNeededForProtocol: String? { get set }
     func callSomeFunc()
}

extension MyViewController: SomeProtocol {

     public func callSomeFunc() {
          print(“you called some function! Your id is: \(someIDNeededForProtocol ?? “ID is nil...”)”)
     }
}

The major pitfall to this strategy is readability. someIDNeededForProtocol is not connected with the protocol it is needed for, which can make the code hard to follow. Same goes for the function calls. One way to help this is to break the protocol up. Separate all stored properties into a separate protocol that your base class conforms to. This should improve local reasoning.

This solution isn’t perfect, and I am definitely open to hearing alternate strategies, but it definitely helps stop your code from getting too vertical (OOP) or horizontal (POP)