Storyboards.
Love em or hate em, they definitely can be useful.
While I was beginning to learn iOS development, I did everything I possibly could on Main.storyboard. Drag/drop was fast and easy and allowed me to easily visualize what I was creating. Why would I ever do anything else?
Yet, even when creating my first simple app, my Main.storyboard got fairly cluttered.
Oh and by the way, check out another screenshot from my first app.
However, as I later found out working on my first app within a team, git and storyboards did not work well together. For those of you who haven’t experienced a storyboard merge conflict, don’t worry, you aren’t missing out.
A Mix of Old & New
After dipping my feet in iOS development, I still liked to use storyboards to quickly setup the flow of an app despite all the points I had seen. I gave my View Controllers StoryboardIDs and created segues between them with my mouse. I had transitioned into setting UI for my controllers in code and linking each one to a Storyboard object.
Yet, this can still be a bit messy.
Don’t think any of my personal examples were too bad so…
Cleaning up Storyboards Using References
Let’s learn how to refactor our project! I will be refactoring the project highlighted in the picture with the caption Programmatic UI.
As this project uses a tab bar controller, I’ve decided to use a separate storyboard for each set of screens corresponding to each tab.
First, I hold cmd while clicking on a set of screens, making their borders blue. Then, in the top menu bar, I go to Editor --> Refactor To Storyboard.
Click it and you will be given to the option to give your new storyboard a name.
After I do this for each set of screens, I now have 6 storyboards in my project, excluding the LaunchScreen one.
To manually create a Storyboard reference to a new storyboard file, you can just drag/drop from the bottom right corner.
After you select the reference, make sure you give it an identity by linking it to a Storyboard and choosing an ID in the upper right corner.
To present a View Controller programmatically, first, give it a StoryboardID.
Then, instantiate it using its StoryboardID and present.
Establishing a Workflow
It’s important to remember that the approach highlighted above is not the only approach nor the best one. Everyone’s needs are different and teams should discuss how they want to structure the workflow of their projects.
Maybe, you could just stick to one giant storyboard and have one person manage it all. (not recommended)
There’s also the approach of having every single view controller on its own storyboard file or using something I haven’t mentioned yet called nibs.
It’s up to you and your team.
Last tips
- Figure out a workflow.
- Don’t be afraid to use storyboards in teams.
- Merge often.
Good luck developing!