Storyboards

Pros

  • Good for beginners in trying to figure out application flow
  • Can be easier to layout UI elements in terms of constraints compared to typing a bunch of code to achieve the same results.

Cons

  • Hard to navigate storyboards when you are operating in a small screen like a mac book air or mac book pro 13’’
  • -Have to deal with the menu system and makes sure you are editing the correct view controller. This might sound a bid picky, but imagine you are working on a project that has 10 view controllers, then things can get a little convoluted and run the risk of modifying incorrect view controllers
  • When it comes to cells or segues you have to make sure they have the correct identifiers or else your application won’t even work when those un-identified cells and segues get referenced, and currently XCode (10) does not give you appropriate runtime errors for you to address these issued immediately. You have to go through and manually check that each of your cells and segues have the appropriate identifiers.
  • As your project gets larger, the load time of the storyboard is going to increase which can slow down your development time. Pro tip: you can modularize your storyboards. i.e have a storyboard for each ViewController or use XIB for cells or smaller views
  • In the event that there is a merge conflict when two people are working on the same storyboard, then you would have to look at xml-the underlying code used for storyboards- which could become difficult as oppose to dealing with the merge conflict with programmatic UI.  
  • If your views, have sub views, which can be highly probable as your app grows in complexity, adjusting these sub view on the storyboard can become tedious .
  • Be aware of changing the names of the IB outlets in your app. Once you change the names in the code, you have to go back to the storyboard and make sure you update UI elements that are reference by those updated IB outlets. Otherwise, you will get run time errors that are unfamiliar which can be annoying especially for beginners.
  • Again, as your app gets more complex, having a large storyboard file can increase the compile time of your app compared to having programmatically created views

Strictly programmatic

Pros

  • You know what attributes of a certain UI element have been set upon initial creation. Whereas storyboards for any UI element you would have to go through the attributes inspector to check what properties where change and the same could be said about the size inspector
  • You have a deeper understanding of what goes on behind the scenes of a UI element as oppose to simply dragging and dropping and having your application “magically” work

Cons

  • Can require more code to layout UI elements
  • Not good for beginners as it can be overwhelming

Which one should I use?

Understand if you are a beginner or an intermediate to advance developer. If you come into iOS development with already experience as a developer and you like to know the ins and outs of things, then yeah, go ahead and use programmatic views. However, if you are a novice, then you might want to use storyboards so that you get a hang of fundamentals and get rolling with iOS development because programmatically creating UIs can be a lot of code; thus, it can be intimidating to beginners.

What kind of app are you building?

If it is a simple app with static views, then storyboards might be the way to go.

Are you creating a complex app with reusable views?

Then you might want to consider using programmatically UI for optimal customizable views.

Are you working with a team that primarily uses storyboards?

Then you might want to use storyboards in order to ensure that the team as a whole is performing and the same could be said about teams that code UI elements programmatically.

Why not both?

Sean Allen mentions that it could be beneficial to utilize both methodologies. In this YouTube video, he brings up the notion of building a framework for your app. In the sense that you create the back bone of your app using storyboard and any sugar on top (i.e additional views) can be done programmatically.

Sean Allen mentions also to do all styling and animation in code. Similar to web dev, where the html is the backbone of your web page and you introduce CSS to add styling and JavaScript to add animation.

Sorry this was not a definite answer, but like a lot of things in life, the answer to this question is: it depends. Are you a beginner? What type of team are you working on? What type of app do you want to build? What method of development works best for you? The take home message here is be aware of the pros and cons of each. Additionally, be objective and employ critical thinking to determine whether or not you should programmatically create elements or simply use storyboards. Additionally, some of the cons of these methodologies can be avoided by proper planning of you app and having a good understanding of the iOS framework and OOP (Object-Oriented-Programming) principles. For example you can avoid clunky storyboards by modularizing your storyboards, creating skeleton views ( Xcode 10 – Interface Builder / Code Hybrid Approach for User Interface ) with programmatic styling to increase build time on large applications, or use generic classes to lessen the code on programmatic views and increase your development time.

Resources:

Storyboard vs Code SpeedRun – Which is Faster? (iOS Swift 4)

Storyboard vs Code – Why I use Storyboards

10 Reasons Why I Abandoned Storyboards and Interface Builder

Storyboard vs. Code – iOS Development – Swift

Xcode 10 – Interface Builder / Code Hybrid Approach for User Interface