Storyboards vs Coded Views23rd January 2020
I joined the iOS world in early 2016, and I’ve got the opportunity to work with great developers. When creating user interfaces, many developers like to use Storyboards, but most of them like to generate coded views, but why? Let’s make a quick review of Storyboards and Coded Views.
First of all, both ways are great for developing iOS applications. But, both have pros and cons that you should know before starting a project from scratch or build new features for an existing project.
Example of a SplashScreen.storyboard.
Creating iOS projects with Storyboards is strongly recommended by Apple. The image above is a visual representation of the application design and a fast way to generate views, set constraints, setup layouts, and define application flow.
A basic coded view.
As the image shows, that is the old way to design iOS applications UI. Using Coded Views there is no way to visualize your application until you compile and run on an emulator/device. Even though all the things I mentioned before, this still the favorite way among more experienced iOS developers.
Why? Because all the things that can’t be done on Storyboards or Xibs you can do it programmatically.
When to use Storyboards?
You can use them for static flows and views with a static layout. Also, you can generate elements with dynamic content such as UITableViewCell or UICollectionViewCell. It’s a simple process to generate cells with a custom design using Storyboards. Additionally, it’s easier to generate a UICollectionView with a custom layout.
Storyboard generated with interface builder for UITableViewController and UICollectionViewController.
Since you can define the flow and design the views in a visual tool, you can use Storyboards for almost all cases, except when you already generated a coded view or are using Xib.
So, if you want to generate a very dynamic view and flow, maybe Storyboards are not the best choice.
Even though they introduced Storyboards since Xcode 4 (now Xcode 10), you can't do many things with it i.e., a dynamic design.
Also, it would be best if you take care of generating a storyboard for a specific flow. If you generate huge storyboards, it's going to be hard to work with them, because they end up being large XML files.
If you don’t take care of splitting your storyboards, at the time a merge conflict appears, it's tough to solve it since Xcode generates IDs to manipulate views, and also it is hard for developers to understand where those IDs belong.
Storyboard shown as source code (XML).
When to use Coded Views?
As I mentioned before in the article, this is the older way to generate UI interfaces in iOS. So, if something is not possible to do using Xibs or Storyboards, it may be possible using code.
You can always do views generated with code except when they were in Storyboards or Xibs.
By using Coded Views, it is possible to generate very custom animations or flows for your application, depending on the data or user interaction. You can take advantage of View Controllers lifecycle deeply. View Controllers lifecycle is available for Storyboards based view too, but you can add custom elements or rendering logic easier using Coded Views.
Which one is the best choice for my app?
Both are excellent choices. It just depends on what kind of application you are developing and what kind of views/flows you want to implement.
Even when Storyboards are limited in some cases, they’re a powerful tool that you can use when you want to save time and effort. Maybe in the future, these limitations will disappear, and the Storyboards are going to be the primary way to generate applications UI.
Is it possible to use both in the same application?
Yes! I strongly recommend doing this if possible. You can generate the basic flow and design using Storyboards and delegate the hardest flows and views to code. It would be best if you took care of creating a clear and simple flow to make your views easy to understand.
In conclusion, both are great ways to develop iOS applications. Apple generated storyboards to make developer life more comfortable in most cases, but you can use the one you like the most. For basic layouts, you can use Storyboards to save much time and avoid verbose views and delegate more complex flows and views for Coded Views.
Just remember: when using Storyboards, you should split them into related flows and remember to generate clear code by using proper naming conventions.