Why did we change our iOS rule to allow using Storyboard?
Our UI creation rule was creating a UI programmatically. But recently, we changed it.
Now our iOS team can create UI depending on their preferred approaches.
The reason is that there are really good things if you use Storyboard
- Less Code
- Compile Time
- Preview
- Layout warnings
Among them, the main reason for making a decision is Compile time.
Compile Time: Swift vs Storyboard
Imagine if you need to change the spacing in UIStackView.
The left one is programmatic UI. If you change just one line of code then the swift compiler detects source file changes and will compile it. It may take more time if the source file dependent on other source files.
The right one is used Storyboard. If you change the spacing in StackView on Storyboard then ibtool compile a storyboard into the multiple nibs(stands for NextStep Interface Build file) at compile time.
Results: Storyboard compile-time 6.5x faster than Swift
- Swift: 46.8 seconds
- Storyboard: 7.2 seconds
As you can see from the results, compile-time when using the storyboard is much faster than swift file changes.
If you want to know ibtool’s compile options then check man ibtool in /Applications/Xcode.app/Contents/Developer/usr/bin.
Although there were pros we’ve had some concerns about using Storyboard like below
- PR Review
- Conflicts Storyboard/Xib files
To address these concerns, we need to know about the xib(stands for XML Interface Builder) format.
xib format
Storyboard/Xib is a XML format. It means that Human Readable format. I sometimes heard that from iOS Engineers Storyboard/Xib files are hard to review. It’s true compared to reviewing swift code.
But once familiar with that format You may feel It is easy to review it. Because It looks like HTML format.
The numbers above the image mean like below
- toolVersion
It means Interface builder tool’s version. It may be changed when you update Xcode. I highly recommend all team members use the latest Xcode version to avoid merge conflicts.
2. initialViewController
It indicates the initial view controller’s object id in Storyboard. So If you called an instantiateInitialViewController() then It returns that viewController.
3. device
You can use it to preview the layout on Storyboard. Anyone can change it but after checking the layout then I recommend resetting it as your team’s default device (e.g. iPhone X) to avoid merge conflicts.
4. scenes
A storyboard can have multiple scenes. A Scene has a ViewController.
5. segue
segue is a connection between ViewControllers. It has an id and a destination’s id. If the destination’s id has changed then we need to review it carefully. If there is no ViewController that has the destination’s id then It might be caused a crash at runtime.
PR review
I’ll show two examples.
- Minor changes
- Major changes (e.g. Layout, objectId, segue, etc)
Minor Changes
These changes normally don’t affect your UI. So You can easily review and approve it. It should be fine.
- toolsVersion / plugin version can be changed automatically when you use a different Xcode version and edited the Interface Builder.
- rect can be changed when you change the device or move a subview. These small changes should be fine because It uses autolayout.
- propertyAccessControl(Locking View) is controlled by the developer. I’ll explain it next section.
Major Changes
Major Changes will affect layout issues. I’ll show you some examples below.
If you embedded labels in UIStackView then you have to double-check label’s id is in stackView or not.
An ambiguous=”YES” indicates us there is Layout Issue! So It should be fixed.
Pull Request Template
I highly recommend adding a screenshot of the layout in PR. To encourage your teammate to add a screenshot, set a Pull Request Template.
It is our team’s template.
Description
===
Screens
---
Links (JIRA / Confluence)
---
Related PR
---
Check Lists
---
- [x] multiple devices
- [x] confirmed by developer
How to avoid merge conflicts?
File changes cause merge conflicts. You can avoid it by dealing with file changes carefully.
By following this rule, merge conflicts are avoided as much as possible.
- use the latest Xcode.
- don’t commit the changes if you are not working on that View
- locking Views in Storyboard and XIB Files you are working on
If your team is working on the same Storyboard, I highly recommend locking views to prevent unwanted changes.
You can set a lock on any UI Components(Whole Storyboard, UIViewController, UIView, Segue, any UI-related objects like a Constraint) you will be working on. As I mentioned above, propertyAccessControl will be added to the storyboard/xib file when you set a lock.
Lock Image will be shown when you try to change on Locking View.
Conclusion
There are cons and pros to using Storyboard/Xib. Productivity is also different depending on the iOS developer's preferred UI creation approach. But We made a decision to use both. Because we can save compile-time and found a good solution to resolve concerns for using it.
Also, It is a first-party tool. Apple has developed the IB tool over 34 years. And It is being actively updated come with Xcode.
- 34 Years Ago In 1988, Interface Builder was released by Apple
- 15 Years Ago In 2007, XML Interface Builder was released by Apple
- 11 Years Ago In 2011, Storyboard was introduced at WWDC 2011
I hope our decision helps you decide to use Storyboard/Xib in your team!
References
Locking Views in Storyboard and XIB Files
Implementing UI Designs in Interface Builder
