A common question new iOS developers ask is how to build their app’s user interface: code or storyboards. People adamant about building their interfaces in code inevitably join in to say that building interfaces in code is the right way, the way big companies make iOS apps. But it’s OK to use storyboards for your user interface, especially if you are new to iOS development.
What’s Wrong with Storyboards?
Storyboards have two main issues. The first issue involves version control. If multiple people make changes to a storyboard, commit the changes, and merge the changes, conflicts occur that are difficult to resolve.
Merge conflicts are a serious issue, but if you’re a new iOS developer, you probably are working alone. You’re the only one editing the storyboard so you don’t have to worry about merge conflicts.
The second issue with storyboards is that editing them can be slow if you jam 10 or more screens into a single storyboard. If you run into this issue, the solution is to use multiple storyboards. Select the view controller scenes you want to put in a new storyboard and choose Edit > Refactor to Storyboard.
Why Use Storyboards?
The point of this article isn’t to show that storyboards are better than code for building user interfaces, but the following list shows some reasons to use storyboards:
- UIKit is meant to work with storyboards. Xcode projects that use UIKit include a storyboard for a reason.
- Using storyboards is easier for new iOS developers than building a user interface entirely in code. Dragging a button or other control to a screen is easier than figuring out the code you have to write to create and place that control.
- Storyboards let you see how your interface looks before running the app. With code you have to build and run the project to see how the interface looks.
Build your user interface however you want. But it’s OK to use storyboards. You’re not doing it wrong if you use a storyboard for your app’s user interface, no matter what someone on Reddit or Slack tells you.