Storyboards fail at runtime, not at compile time:

You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time.

Storyboards get confusing fast:

As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where.

Storyboards make working in a team harder:

Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.

Storyboards make code reviews hard or nearly impossible:

Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.

Storyboards hinder code reuse:

In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.

Storyboards require constant context switches:

I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.

Storyboards are hard to refactor:

When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.

Storyboards are less flexible:

In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.

Storyboards don't let you change the type of special view controllers:

You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.

Storyboards add two extra liabilities to your project:

(1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.

Storyboards don't allow you to add a subview to a UIImageView:

Who knows why.

Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s:

By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard.

Storyboards have a higher risk of breaking backwards compatibility:

Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now.

Some of these reasons also apply to XIBs.

Yes, yes they do. You just have to right click on the application, choose show package contents, then go into Contents/Resources and there you see all those files that go into making of the application interface.

You will see hundreds of files that end in NIB, those are made using interface builder.

There seems to be the story that developers at apple don't eat their own dog food so to speak. The real answer is, sometimes they do, sometimes they don't.

For iOS :
In the early days of iPhone 1 and 2, they probably did not use interface builder because it really did not exist. Each application had rolled its own table view and other native controls. It was a bit of a mess, but they had to get the device out and it was easier to do, and like I said, they did not have the native tools we have today. But once iPhone 3 came out and the native SDK, they started to use Interface builder.
To try to make an iOS application today without Interface Builder is just ridiculous because you can't make the app support all the sizes without it, unless you make 1 version of the gui for each and every device. For the proof, you can unzip an application backup package and see the files that go into the application.

OS X:
For NextStep, OpenStep, Rhapsody, OS Server and then on every OS X release, yes they used Interface builder for every single application that had graphical user interface. You could back then actually change the NIB files because they were not compiled. Every single application had NIB files and you could clearly see the interface, all from 10.0 and up.

Hope this answer puts the theory to rest that somehow Apple doesn't eat its own dog food. Just watch the WWDC videos, they clearly tell you how they do it, and even in one of them they show the lock screen, how it was made in layers and so forth.

Usage of story board is not based on whether the application is a simple one or complex or with advanced features. We can develop iOS applications using XIB's, without using XIB's as well as using story board. Story board is just a feature which will reduce further development time by allowing the user to design the flow of application with just few clicks and drags. Some developers feel easy to write code even to create a simple button or label. Because they feel that they have greater control over the control creation. Similarly some people feel easy in creating XIB and use them (like me). They feel that by avoiding multiple lines of code, the task can be achieved without writing even a single line of code. Coming to story board, not just creating the views, but the navigation and flow can also be controlled. Like drag a button to a view controller which internally generates the code what has to be done on button click. Its simple to use unless people are familiar with the delegates related to story board.

So Its not the features or complexity or behavior of the application that decides the way the developers have to follow, its the ease with developers to create best quality app.

May be in future who knows if Apple stops XIB and force the developers to use Story board only !!!

Yes. They do.

Storyboard is just another tool in the iOS Dev’s belt. It gives you an additional way of going about things.

While it's not mandatory to use storyboards, it definitely simplifies a lot of things.

For one, it organizes all your views in a single place so that's easier than sifting through a bunch of nib files.

If your app has a simple linear or branched flow, storyboards can make the flow very apparent to the developers.

Also, as another answer mentioned, it all boils down to your needs. If you need greater control over your views, you'd ditch the storyboards. But that doesn't mean your app can't use both approaches for different flows.

It's good to know how to use storyboards, whether you use it or not is always upto your implementation.

No. Storyboards are a cancerous abomination that should have died a long time ago.

Storyboards are not version-control friendly and cannot be worked on by more than one person at a time.

Storyboards are a clumsy drag-and-drop non-substitute for simply writing your constraint code by hand, which is cleaner, simpler, easier to debug, and far, far, far easier to experiment with.

Don’t use SwiftUI. It forces you into a ludicrous “reactive” MVVM paradigm where even something as simple as “myTextField.onValueChanged” is no longer possible without extreme mental/programmatic gymnastics. Their heavy reliance on opaque types is jarring and weird.

Use NSLayoutConstraints in the form of something like SnapKit where you can trivially lay out constraints without all the boilerplate that the standard NSLayoutConstraint API forces on you. UIKit is a powerful toolkit and you’d do well to learn it.

The first time I ever did this, I literally formulated my own constraints DSL on the fly after seeing all that boilerplate. My DSL is similar to SnapKit, though far more primitive, but it works for my needs:

myView.constrain { 
	$0.width(0.9) 
	$0.height(0.5) 
	$0.center() 
} 
 
myOtherView.constrain { 
	$0.width(0.9) 
	$0.height(0.2) 
	$0.below(myView, 30) 
	$0.centerX() 
} 
 
//etc 

Voila.

Never use Storyboards. Write your UI in code. There’s a reason Apple came out with SwiftUI: even Apple agrees that Storyboards are garbage and Interface Builder has never had a reason to exist.

Storyboards.

There is no downside to using Storyboards. You can work very quickly and flesh-out a complete application in a day or so.

If you need to add an element, or make a change, its fast to do so in the GUI.
You can even make screens and buttons that work, with absolutely no code.

If you later want to add some customisation to those elements, you can do that programmatically.

Building an app 100% programatically seems like doing things the hard way for the sake of it.

In a recent project, the client wanted a non-standard segue behaviour.
I used storyboards to layout the app - using standard segues. And when that was working, I went back and changed them programatically.

Edit:
Eric Harmon
has pointed out one downside. The storyboard is a single file. Which means in a team environment, it becomes impossible for multiple developers to edit storyboard content simultaneously.

This is a legitimate problem. A workaround is making one individual the storyboard boss. But that would not fit all organisations.

In situations with large teams and very complex UI hierarchies there's a case for splitting the UI into individual NIBs or building more of the content programmatically.

While I don't outright recommend it, the last work-project I worked on with a team of ~8 other iOS developers, had a 100% programmatically-built UI. A bulk of the UI was built programmatically before I got there, and after I joined, I continued to build out the UI the same way so as to challenge myself and learn new things. The app had at least a dozen screens, with some pretty complex views and behaviors. Without a doubt, it took longer to build than a UI with Storyboards and Nibs would take. The upside to this approach was that we all became quite familiar with the quirks and gotchas of NSLayoutConstraint and using Auto-Layout programmatically. Looking back, I'm not sure how we could have even built some of the views using NIBS. Not to mention, sharing Storyboards and NIBS on a team with multiple developers can result in versioning conflicts and other issues.

The latest work-project I'm working on is a game, and uses quite a few IB-based views. IB has its own set of gotchas, but in my opinion, in many cases it can be drastically faster to use IB than the programmatic approach. Of course, the previous statement has caveats that I've previously mentioned- versioning conflicts, complexity of views, etc. The key to remember is that you cannot have two developers making changes to the same Storyboard at the same time. If developer A makes changes to a Storyboard, developer B must grab and merge those changes before making their own changes.

IB vs programmatic UI is a contentious topic, and there are development shops that have a visceral reaction if you mention programmatic UIs. Those people would do well to remember that they're not curing cancer here, in most cases, and shouldn't take themselves so seriously.

The bottom line: use whatever approach you're most efficient with. Learn all of them, because knowing all of them will benefit you, regardless of which approach you use on your current project, because hearing a variety of ways of describing something will benefit your understanding of the subject.

Many advanced iOS applications have custom views, specific view controllers or involve some special ways of presenting content onscreen. While storyboarding is very useful and you can literally build a simple app with storyboards in minutes, it falls short when trying to implement a custom interface. In an advanced app building a UI with storyboards and then trying to enhance it in code actually proves as more frustrating and time consuming than just building the entire thing in code. In apps with a standardized flow that's another story.

Update:
I decided to go with storyboards for my new app Scraps as it felt well suited for them. Not everything is done in Interface Builder, but the whole navigation stack is. I even did my own transitions with images and it is quite easy with custom segues. Also, iOS 6 introduces exit segues, which enable you to define dismiss actions and this leads to not needing a lot of view controller delegates.

In general, Interface Builder is becoming a very powerful tool with storyboards and auto layout, but adopting them surely presents an unnecessary strain to existing developers, especially when there are still points where it doesn't deliver. So the question is not whether an application is advanced, but whether storyboards benefit the overall development.

Multiple storyboards + Stackview is much better than Programmatically created constraints. (even though they increase compile time)

Storyboards without stackview are likely not worth it.

A single storyboard is also a headache.

Storyboards are also merge conflict headaches as well. But also most of the layout logic to xibs and storyboards and allow classes to focus on logic.

I’m actually surprised nobody has mentioned this. It’s an important tangent!

Ever since iOS9 where apple introduced stackviews the idea of using storyboards has began to get momentum. Why? Because with stackviews you just drag and drop AND no longer need to dance with constraints, rather you just configure its adaptive layout with the alignment and distribution properties of the stackview. If you have a web design experience, stackviews are very similar to flexbox. It saves you from all the alignment/div/margin hassle.

I STRONGLY recommend everyone to see “Mysteries of Auto Layout, Part 1” wwdc video. Jump to 3:47.

It really shows how simply it is to build complex stacks of views. It still doable programmatically, but with storyboards you see immediate results of complex distributions with far less typing. Doing the same in storyboards with constraints takes roughly 5X more times than with stackviews

An advanced tutorial is: https://www.raizlabs.com/dev/2016/04/uistackview/

Another thing that I feel like a lot of newbie developers don’t know about and had they knew they would be doing less complex code is knowing the use cases and differences between:

• readableContentGuide
• safeAreaLayoutGuide
• LayoutMarginsGuide
• Anchors

Once you master these, your usage of constraints become very reduced. A good example on their differences can be found in this SO answer: On iOS, what are the differences between margins, edge insets, content insets, alignment rects, layout margins, anchors...?

The (simple) nature of stackviews make it less breakable in Swift/iOS upgrades and its easily cross-compatible and safe for upgrades and migrations. Constraints/frames are a little more whacky in that sense.

Another reason to use storyboards is that you can see in realtime if your constraints are conflicting or not. If you do it programmatically then you won’t spot that until your UI is rendered. Though some UI issues only show up on landscape or happen if you have specific aspect ratio requirements etc, so you might have to switch between devices.

What I recommend to newbie developers is to do a bit of both as they are both helpful for learning. As storyboard hides too many good to know details and it would hurt a developer to not to know about them, later once you’re working in a team, the team would enforce that decision onto you.

I use Storyboards for some things, but not for others.

When the iOS developer kit first came out, Storyboards didn’t exist, and the typical paradigm was to define View Controller layouts in individual XIB files, and then instantiate them as-needed.

I still use this XIB->Instantiation technique when creating dynamically driven interfaces.

For example, a series of View Controllers whose number, order, and content are determined not at compile time, but at run time based on a dynamically transmitted config file.

Storyboards don’t really do well with this concept, they are much more ideally suited to situations where your user interface is pre-determined and fixed (with a few minor exceptions).

Yes, I use them for both old and new projects.

I don’t like relying on segues because code becomes cumberson when I need to pass objects with prepareForSegue function but I still connect view controllers just to have a quick visual reference (arrows) of the workflow when opening a project after a while.

That’s one of the many things I miss when porting to Android though I admit android XMLs are quite cool, the Visibility.GONE feature ia awesome.

I usually have all my view controllers in a single storyboard while I prefer Xibs for popups and custom views.

I have an helper function to retrieve quickly the Main storyboard and instantiate view controllers from it so that I can pass parameters and push them on navigator.

As of version 3.4.2, Facebook iPhone app uses HTML and CSS for actual content on most pages including your feed. One way to confirm this would be to sniff network traffic going through your iphone [1] and check for requests made by facebook app.

Attached screenshot showing HTML response (in green) received by facebook iPhone App on refreshing feed:

[1] How to inspect iOS's HTTP traffic: http://www.tuaw.com/2011/02/21/how-to-inspect-ioss-http-traffic-without-spending-a-dime/

Apple has added some really nice features to the Interface Builder in xcode 8. It’s generally easier and faster to build screens using the storyboard. But the storyboard comes with some downsides:

• As they grow (i.e. more screens are added), they get slower to load and get a bit tedious to work with (with all the segues, etc).
• If a team of developers are using the same storyboard when making changes to the UI, you’ll have merge conflicts when committing code to version control. These merge conflicts are tricky to resolve and can waste way too much time.
• You need to specify a storyboard id for each of your view controllers to be able to use them in code (and it’s a hardcoded id).

One solution to this problem is to use multiple storyboards. In fact, you can go so far as to create a storyboard for every view controller! I’ve done this and it actually works really well with not a lot of extra code. You can get an instance of your view controller by adding a static method to your subclass. In this case, I’ve named the storyboard the same as the view controller so that I can pass the class name to the UIStoryboard constructor:

class MyViewController: UIViewController {  
      static func getViewControllerInstance() -> MyViewController? {  
            let storyboard = UIStoryboard(name: String(self),  
								bundle: nil)  
			return storyboard.instantiateInitialViewController() as?   
            MyViewController     
      } 
} 

Then rather than using segues all over the place, just code the navigation (which is just a few lines of code). You can push and pop with a Navigation Controller, or just present it from a view controller. If you want to go back to previous controller (like a segue unwind), just call dismiss().

You should know both.

Doing everything programmatically in a correct way, taking into account constraints, rather than setting fixed coordinates is complex, but can be done.
Doing everything programmatically is easy, but it is way easy to get it wrong.

Also, Apple changed the constraints algorithm recently, and storyboards got faster, so the “I do everything programmatically because it is faster” is less and less applicable.

One advantage of using storyboards is the fact they are visual, and allow to get a visual representation of what you are doing.
I’d say Storyboards first, and use programmatical instantiation if you have a valid reason.

I'm going to guess that you have not written the app yet, or the question would be moot. What you're really asking then is not whether you should release such an app now, but whether you should start a new storyboard based app now and release it at some later date when it's complete.

To this I would say: yes, definitely. iOS 5 adoption has been fast and furious and will only increase while you're writing the app. If you think storyboarding will help you write a better app, go for it.

A caveat: Since you are targeting a specific niche, it would be worth some time to investigate that specific niche instead of the market as a whole. If the app will be used in schools, you probably know of a school or two where iPads are used. Ask people from the schools about their upgrade plans. Compare those plans to your expected schedule.

There are three main benefits to using storyboards when developing an app:

1. Storyboards allow you to see how your app will work and mock up its design and flow without writing hundreds of lines of code.

2. They are especially useful for beginner developers who need help visualizing the app's design and flow.

3. Storyboards can also be helpful when making changes to an existing app's design or adding new features, as they provide a convenient way to see how the changes will affect the overall app.

Storyboards allow you to prototype and design multiple view controller views within one file, and also let you create transitions between view controllers.

It’s important to use the right tool for the job. For example, it doesn’t make sense to use storyboards when the view has a dynamic or complex layout that would be better implemented in code. Here’s an excellent article that dives into details about the pros and cons of using storyboards.

If you’re interested in learning how to build your iOS app’s UI with code, here’s a tutorial for creating constraints programmatically that my colleague wrote. It uses an awesome library called PureLayout that extends UIView/NSView, NSArray, and NSLayoutConstraint and eliminates the hassle of dealing with huge function calls.

Hope this helps!

It purely depends on what are you more comfortable to work with and what is the fastest way for you to implement given tasks.

Storyboard is a good option for those, who prefer to visualise what they do - app screens, UIs, relations and interactions between screen elements and screens, etc. But they have major disadvantages:

• Storyboards are not quite friendly with VCS, some changes should be double-triple-checked after pulling a branch;
• Storyboards are laggy. I had dozens of cases, when all views became empty frames and I received message like “Storyboard stopped working”. This is annoying and frustrating;
• Storyboards are resource-demanding. They heat up processor a lot, while you are casually waiting for .storyboard file to open, because a lot of indexing and visualising is processing during file open.

Ok, we decided that storyboards suck, but what are the workarounds? Of course, writing UI in code. Even SwiftUI does that! But what are pros?

• SwiftUI does that with fresh Preview tool, that allows you to instantly see what is going on with your View. Nod to Flutter, but anyway. This is almost same thing as Storyboard, but you just configure 1 screen at a time. Big deal? Try using SwiftUI without Preview;
• Native Swift language came a long way of updating, but it is still quite massive, when we’re talking about building UI in code. Thus it requires native extensions or 3rd party libraries/frameworks (for example SnapKit);
• Building UI in code is not an easy thing and might be a hard task for beginners, that can’t imagine how to do it just because they didn’t try it with storyboards first. So it would be better if beginners start with storyboards, learn every aspect of it (basically how everything is called - margins, anchors, leading, trailing, top, bottom, inset, offset, safe area, centerX, centerY, priorities, less than or equal, greater than or equal, multipliers, size classes, etc) - then proceed to do it without storyboards.

PS. This video might answer your questions as well

I create two of them.

I think that's the right way to build a universal app. Obviously, some effort has to be invested in keeping the two in sync, but having to cope with a certain amount of complexity is a developer's job.

For an app which targets the iPad, I find that the iPad will often have the more complete, more complex UI. So initially, more time is spent iterating the iPad storyboard.

But when the iPad version stabilises, that's the time to invest effort to ensure that the storyboard for the small-screen device is complete, and there are no dangling connections, mis-named segues or IBActions that don't get acted upon.

I recommend storyboards. It’s visual and it’s nice and it works. If you’re learning then you already have a lot of code to learn. Let the layout not be a coding concern for you.

It seems there are two types of developers, ones use storyboards and others do layouting in code. Either way is good. I personally use storyboards as I’ve found that:

• it’s much quicker to update layout in there onstead of finding the right line in the code where things should be changed.
• making bigger layout structure changes seem to be quicker.
• Other developers will understand the app and get up to speed mich quicker using storyboards