iOS View Layer Architecture: Guidelines, Layout Strategies, and Best Practices

The author introduces the second part of a series on iOS application architecture, focusing on the view layer, which becomes hard to change after release and therefore must be designed carefully to avoid slowing down iteration cycles.

Five typical problems that degrade view‑layer architecture are listed: messy code, excessive inheritance, low modularity, horizontal dependencies, and loss of design inheritance, all of which increase the workload for business engineers.

To improve maintainability, the article proposes a strict code‑structure guideline: place all getters and setters at the end, organize methods in the order of life‑cycle, delegate implementations, event responses, and then getters/setters, and keep delegate methods grouped with clear #pragma mark sections.

Example view controller code is provided, showing how to add subviews in viewDidLoad, perform layout in viewWillAppear, and keep property initialization inside getters. A contrasting bad example demonstrates why initializing views directly in viewDidLoad is discouraged.

#pragma mark - life cycle
- (void)viewDidLoad {
    [super viewDidLoad];
    self.view.backgroundColor = [UIColor whiteColor];
    [self.view addSubview:self.firstTableView];
    // ... other subviews
}
- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    CGFloat width = (self.view.width - 30) / 2.0f;
    self.originImageView.size = CGSizeMake(width, width);
    // layout code continues
}

The article also recommends using layout helpers such as Masonry, UIView+LayoutMethods, and UIView+AEBHandyAutoLayout to replace raw CGRectMake or verbose Auto Layout constraints, improving readability.

When deciding between Storyboard, NIB, or programmatic UI, the author argues that large teams (10+ developers) benefit from code‑based UI to reduce merge conflicts and simplify frequent requirement changes; Storyboards are prone to difficult‑to‑resolve conflicts.

Regarding the practice of having business teams subclass a common TMViewController, the author contends that inheritance raises integration, onboarding, and maintenance costs, and suggests using AOP techniques such as method swizzling (or libraries like Aspects) to inject shared behavior without forcing subclassing.

In summary, a well‑structured, code‑first view layer with clear conventions, reusable layout utilities, and minimal inheritance leads to faster iteration, better maintainability, and smoother collaboration among iOS development teams.