What are the benefits of using storyboards instead of xib files in iOS programming?

What are the main differences between using storyboards and xib files.

In particular, what are the advantages or disadvantages of using storyboards?

Unfortunately, despite quite a bit of research, all I could find on Storyboards was simple tutorials that show how to set up a storyboard, rather than specific information explaining what it is.

+69
ios xcode interface-builder xib storyboard
Jan 31 '12 at 17:07
source share
11 answers

Storyboard:

  • A container for all your scenes (view controllers, Nav controllers, TabBar controllers, etc.)
  • Connection manager and transitions between these scenes (they are called Segues)
  • A good way to control how different controllers talk to each other.
  • Storyboards give you a complete overview of the flow of your application, which you can never get from individual nib files floating around.
  • The reducer for all the โ€œclutterโ€ that occurs when you have multiple controllers, each of which has its own nib file.

I have been using storyboards for a while, and ONLY the underside is that you cannot configure iOS 4 or lower. Storyboards only work on devices running iOS 5 or higher. In addition, there are many advantages, and the disadvantages are nonexistent IMO.

The best tutorial I've seen is Ray Wenderlich

Also, if you're a member of the Apple Developer program, check out WWDC's past storyboard session (iTunesU), which is awesome.

Another great thing (also on iTunesU) is the latest Stanford iOS app programming course.

+80
Jan 31 '12 at 17:31
source share

There are not only supporters of the storyboard, but also cons - just because you asked to enter:

  • It is not easy to work with SB in a team, since only one participant can work on SB right away (because it is one file).

- The following is not true: - if you need to do what SB does not offer, it is not so easy to get SB mixed with software created views (well, maybe, though)

The thumb rule seems to be: the harder you expect to get your project, the more you better not go to SB.

EDIT: - another SB flaw: working on all the annoying Xcode errors regarding SB. For example. however, it is necessary to frequently empty the DerivedData folder due to several inconsistencies. Sometimes storyboard files or a link to them are corrupted. Then you may have the joy of finding a problem. Take a look at this thread to get an idea.

EDIT 2 (March 2013): Meanwhile, storyboards and Xcode work much better, and documentation and best practices are widespread. I think that working with the storyboard can be recommended for most projects, even if there are still some glitches.

EDIT 3 (September 2013): Now the new Xcode 5 format, working in teams with SB, can be even better, since it seems now possible to merge SB-code is much easier.

Another EDIT: well, if you have an hour of time, sit back, relax and listen to these guys discussing this topic (Ray Wenderlich and Co)

Edit 2016.1: After a long time when I was a supporter of the storyboard, I had so much trouble with it in recent months that I decided to leave the storyboards as far as possible. The reason for this is that Apple adds a feature such as stupidity, but does not care about errors and shortcomings. Performance with many auto-layout limitations is really bad (while development time), and the prone to errors has become enormous. Example: even less complex storyboards tend to get into "dirty mode" right after opening a project in Xcode (see git Status). Tip: As a newbie, you'll love storyboards, as you can prototype quickly and get work without a lot of code. When you enter the intermediate state, you will add more GUI code to your project. Now you start going back and forth between the code and SB - and everything starts to get worse. Sooner or later, you usually make most of the GUI content in your code, because the result is more predictable than having multiple sources.

+50
Jun 25 2018-12-12T00:
source share

Summary

Nibs / .xib files and storyboards are Builder interface files that are used to visually create a user interface for iOS and Mac applications in Xcode (I will use iOS terminology for classes, as this question is marked by iOS, but this also applies to Macs) .

Differences

Tips are intended for use with one UIView . They can also be connected to a subclass of UIViewController by setting the File Owner class to any subclass of UIViewController and attaching the output image (drag and drop to connect using the Connection Inspector in the right right pane of Xcode).

Frames must contain a user interface for 1 or more UIViewController . You can create an entire user interface in one storyboard or split it into smaller parts.

Benefits

Frames should always be used in favor of .xib / Nibs files (for view controllers). Cracking has more features and is being actively developed by Apple.

Every argument in favor of Nibs relies on being used individually, while storyboards contain many scenes. You can use one storyboard for each UIViewController as easily as you can with Nib (see Code Examples below). Keep reading for detailed explanations and code examples.

Detailed

Why do Storboards outperform Nibs?

The answer basically comes down to the fact that Apple encourages the use of storyboards and puts more effort into them.

  • Storyboards have scaling capabilities that Nibs do not have. Seriously, you can't scale everything in Nibs, which sucks when designing for large screens on a small laptop.
  • Nibs lacks key features, such as:
    • Prototype and dynamic cells for UITableView ( more )
    • Property top layout guide (see comment)
    • There are probably more, please edit or comment if you have anything to add to this list.
  • You do not need to mess with setting up the Owner Owner class.

The main argument against storyboard is that having all of your view controllers in one place leads to merge conflicts, slow Xcode, slow build time, and general pain in the butt for support. Therefore, a general tip is to use Nib for each UIViewController .

But ... you can just create a storyboard for each UIViewController . A common practice (at least for me) is to hide all UIViewController initialization in the class method (since no other class should know the name of the file in which the Nib / Storyboard is located). Let's compare the related code snippets that you can use to create such a method. The only line of code is the whole difference between the two.

Objective-c

Storyboard

 + (ViewController *)create { UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil]; return [storyboard instantiateInitialViewController]; } 

Nib

 + (ViewController *)create { return [super initWithNibName:@"ViewController" bundle:nil]; } 

Using

 - (void)showMyViewController { ViewController *vc = [ViewController create]; [self presentViewController:vc animated:YES completion:nil]; } 

Swift

Storyboard

 static func create() -> ViewController { let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle()) return storyboard.instantiateInitialViewController() as! ViewController } 

Nib

 static func create() -> ViewController { return ViewController(nibName: "ViewController", bundle: nil) } 

Using

 func showMyViewController() { let vc = ViewController.create() self.presentViewController(vc, animated: true, completion: nil) } 

Arguments

I will consider all the usual arguments for Nibs; as I mentioned earlier, mostly single files are used, not as an argument for Nibs over Storyboards

  • Commands and Merge

Argument: having a storyboard with a lot of controllers cause merge conflicts if you work in a team with several people making changes

Answer. A single storyboard does not cause more merge conflicts than a single Nib

  1. Complexity

Argument: very sophisticated applications have many scenes in the storyboard, which leads to a giant storyboard that loads forever and is hardly understandable because of its size.

Answer: This is a great moment, but you can easily break the Chipping into smaller parts. Storyboard links look like a great feature that can be used to connect Storyboards together, but they are only available in Xcode 7 / iOS 9+. In addition, there is still no reason to select individual Nibs over Storyboards.

  1. Reuse

Argument: creating a Nib for each subclass of the UIViewController allows you to reuse the code, so you donโ€™t need to configure all your restrictions and access points for each scene in your storyboard.

Response: Again, no reason to choose individual Nibs for individual storyboards.

+7
Jun 22 '15 at 3:46
source share

there was a good presentation about the storyboard presented at the LiDG meeting a couple of months ago.

Personally, I would say that this is the way to go with the new application. There are some gaps, especially for very complex applications, but pro mostly outweigh the cons.

+5
Jan 31 '12 at 17:16
source share

Some more advantages of storyboard:

  • Cracking has better support for viewing tables. That is, you can use "Dynamic" and "Prototype".
  • Easier to create view controllers using storyboards. You can do things like: [se lf.storyboard instantiateViewControllerWithIdentifer:]
  • Splitting supports view controller containers, so you can graphically display child view controllers.

Bottom Sides:

  • Cracks are slowly processed in Xcode when they contain many view controllers.

  • Autostart cannot be enabled for a single view controller in a storyboard.

+4
Feb 02 '14 at 23:21
source share

Be careful if you use storyboards, your application will not be backward compatible with old OS settings.

+3
Jan 31 2018-12-12T00:
source share

A storyboard is basically a device that facilitates your work as a developer. It obeys a number of nib files, so performance is pretty much equivalent, but great for a developer to be able to take a quick look at the entire application stream.

I am starting to switch to using storyboards in new projects, providing an opportunity to convince the client to accept iOS 5 as the minimum version. This happens solely because I prefer to do it this way, and it takes me less time to complete the same tasks.

+2
Jan 31 '12 at 17:31
source share

Your attitude towards automatic layout can also affect whether you want to use storyboards. Using xibs, you can enable or disable auto-layout based on .xib, which allows you to use the mix in your application, while storyboards apply your choice to all the views they contain.

+1
04 Oct '13 at 16:29
source share

You see a big picture in one second. Having a lot of NIB files, well, you don't see the big picture. Itโ€™s easier to maintain your programs. Itโ€™s easier to understand other programs ... among others.

+1
Feb 02 '14 at 22:52
source share

<strong> Benefits:

1) It's very nice to create interfaces

2) You can use StoryBoard Segues to pinpoint navigation / modal relationships.

3) If your application supports multiple devices, this is a good way to organize different views.

4) Another added benefit is prototyping.

5) The prototype UITableViewCell can save time and reduce the amount of code.

6) you can see all the screens of the application in one place using StoryBoard.

7) You can easily view the relationship between them.

8) if you are working on user code, you can better understand the flow of the application.

9) You can customize the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from the storyboard without launching the application again and again.

10) Customers can see the prototype of the application before starting to develop it, here the storyboard helps you.

Disadvantages:

1) It is only available in iOS 5+

2) StoryBoardSegues are pretty tough and you can often use prepareForSegue.

4) Like IB, it is not very friendly with other engines and display tools.

4) Enhances the sharing of projects for one presentation or a set of views - you need to send all or nothing.

5) For storyboards, you will need a large screen specifically for the iPad.

6) Difficulty copying views from other applications to the storyboard.

7) Problems in the storyboard when several developers are working on the same project using the git repository

copied from some resource

+1
Jan 16 '15 at 1:13
source share

Prior to iOS 7, storyboards were tidy, but not required. They introduced as many problems as they solved. iOS 7 tilted the balance towards storyboards.

With iOS 8 and 9, this is no longer a question: use storyboards!

The main disadvantage of storyboards is that you are completely dependent on Xcode, and you can spend hours spinning wheels on Xcode errors. But Xcode has become much better, and the benefits with Storyboards are now too numerous to ignore. View prototypes of table cells, size classes, support for automatic layout, etc.

Some tips:

  • Think of each storyboard as a container for view controllers that belong together. Do not think of it as a great layout for the entire application.
  • You may need more than one storyboard.
  • Segues are really only useful for the most trivial use cases - they are great for this. But in the real world, many transitions come from code. And this is normal.
  • Enter a category to allow programmatic presentation controls from the storyboard (s), so all you have to do is enable vc = SomeViewController.create (), where the method handles all the details (pull out the storyboard, pull out the view controller from the bulletin board ) etc.).
0
Jun 15 '15 at 11:22
source share



All Articles