Coordinator模式：使用Storyboard替代Xib的相关技术疑问

Great questions—these are super common points of confusion when adopting the Coordinator pattern for iOS development. Let’s break them down one by one:

1. Why are Xibs preferred over single-storyboard-per-ViewController in the Coordinator pattern? #

The Coordinator pattern’s core goal is to decouple navigation logic from your view controllers, and Xibs align really well with this philosophy for a few key reasons:

• Lightweight and focused: Xibs are single-file per view controller, so you avoid the dreaded "massive storyboard" problem. Since coordinators handle all navigation, you don’t need segues cluttering up your layout files—Xibs only hold the UI for one VC, no extra navigation logic.
• Explicit initialization: Coordinators are responsible for creating and configuring VCs, and Xibs let you initialize VCs directly (e.g., MyViewController(nibName: nil, bundle: nil) if the Xib matches the VC class name). This makes dependency injection straightforward—you can pass required data or services right when you create the VC, instead of having to add post-instantiation setup steps like you would with storyboards.
• Faster performance: Large storyboards slow down Xcode compile times and app launch/VC load times. Xibs are smaller and more targeted, so they’re quicker to process. When using coordinators, you often instantiate VCs on demand, so loading a Xib feels snappier than pulling from a bloated storyboard.
• Easier collaboration: Git conflicts are far less common with Xibs compared to shared storyboards. Since each Xib is tied to one VC, multiple developers can work on different screens without stepping on each other’s layout code.

2. Do we have to use a single Storyboard per ViewController? Can we adjust the StoryboardInstantiable extension to use identifiers instead? #

No, you absolutely don’t need one storyboard per VC! The Coordinator pattern is flexible about how you load your view controllers—what matters is that the coordinator maintains control of navigation, not how the VC is initialized.

You can absolutely adjust your StoryboardInstantiable extension to use identifiers from a shared storyboard. Here’s how:

First, modify the protocol to include a storyboard identifier (with a sensible default):

protocol StoryboardInstantiable: AnyObject {
    static var storyboardName: String { get }
    static var storyboardIdentifier: String { get }
    static func instantiate() -> Self
}

extension StoryboardInstantiable where Self: UIViewController {
    // Default to using the VC's class name as the identifier (matches common Storyboard setup)
    static var storyboardIdentifier: String {
        return String(describing: self)
    }
    
    static func instantiate() -> Self {
        let storyboard = UIStoryboard(name: storyboardName, bundle: nil)
        return storyboard.instantiateViewController(withIdentifier: storyboardIdentifier) as! Self
    }
}

Then, conform your view controllers to the protocol, specifying the shared storyboard name:

class HomeViewController: UIViewController, StoryboardInstantiable {
    // Point to your shared storyboard (e.g., "Main")
    static var storyboardName: String = "Main"
}

In your coordinator, you’ll still instantiate the VC just like you would with Xibs or single storyboards, keeping the coordinator in full control:

// Create the VC via the protocol method
let homeVC = HomeViewController.instantiate()
// Pass dependencies explicitly (e.g., view models, services)
homeVC.viewModel = HomeViewModel(dataService: DataService.shared)
// Navigate via the coordinator
navigationController.pushViewController(homeVC, animated: true)

Key notes here:

• Keep segues out: Even with shared storyboards, avoid using segues—they reintroduce tight coupling between VCs, which the Coordinator pattern is designed to eliminate. Using identifiers lets you load VCs without relying on segues.
• Flexibility remains: You can even split your VCs across multiple storyboards (e.g., "Auth" for login screens, "Main" for app content) by having different VCs return different storyboardName values. No single-storyboard-per-VC requirement at all.

内容的提问来源于stack exchange，提问作者Nitish