# Practical iOS Layout Patterns with MVVM and UIView Subclasses

DevFeed: [Practical iOS Layout Patterns with MVVM and UIView Subclasses](<https://devfeed.tech/articles/remind-ios-present-all-the-things-31930.md>)

Original publisher: [Read original article](<http://engineering.remind.com/ios-presentation/>)

Author: Remind

Published: 2019-05-28T00:00:00Z

Content type: tutorial

Language: en

Sources: [Remind](<https://devfeed.tech/sources/remind.md>)

Topics: [iOS](<https://devfeed.tech/topics/ios.md>), [ui](<https://devfeed.tech/topics/ui.md>), [MVVM](<https://devfeed.tech/topics/mvvm.md>), [Code review](<https://devfeed.tech/topics/code-review.md>)

Tags: [code-review](<https://devfeed.tech/tags/code-review.md>), [ios](<https://devfeed.tech/tags/ios.md>), [mvvm](<https://devfeed.tech/tags/mvvm.md>), [patterns](<https://devfeed.tech/tags/patterns.md>), [ui](<https://devfeed.tech/tags/ui.md>)

## AI overview

This article describes iOS layout practices developed at Remind, including programmatic layout with SnapKit, code-reviewable layouts, and UIView subclasses that encapsulate reusable UI components.

## Source excerpt

For the past couple years we've been implementing new features with an MVVM-driven approach. Over that time, we've settled into a couple of good (I think) patterns for implementing UIView subclasses, composing them in various view hierarchies, and handling the interactions between them. Ultimately, the goal of any iOS application is to get data presented onto the screen, so I thought I'd share what's been working well for us in that department. Layout In Code It's a debate where every team eventually has to pick a side: Do we use storyboards and xibs, or do we write all of our layout in code? To make a long story short, our team started with Interface Builder, but we abandoned xibs a few years ago and have gone to fully programmatic layout code using SnapKit as our DSL of choice. Every team's needs will be different, but we think it's important that we can effectively code-review each other's layout implementations and potentially have multiple people working on the same screen, neither of which are really practical with xibs. I'll leave it at that -- you do you. Use UIView Subclasses Liberally Nothing clutters the actual logic of a UIViewController like big blocks of view construction code. Whenever you have a logical grouping UI primitives (UILabel, UIImageView, UIButton, etc), make a UIView subclass that encapsulates all of the relative layout inside that view container. This allows you to build the view hierarchy for your view controller in simpler, larger, more logical chunks of UI. One of the more complex UI layouts we have in our application is the settings screen for a class the user owns. Let's look at the layout and focus on the CLASS SETTINGS section, which contains two items, each consisting of two labels and a switch. On our first iteration, our view controller maintained property accessors for each of those primitives: class ClassSettingsViewController: UIViewController { ... private let isPublicTitleLabel = UILabel() private let isPublicMessageLabel =