Related
I'm discovering storyboards and would like to use them for a new application.
I would like to know if it makes sense to have two separate storyboards, one for the login/signup related views and one for the main application views.
The purpose is to keep both storyboards clean and easy to maintain.
What would be the drawbacks of such approach ?
Thank you
I would suggest only having separate storyboards if it becomes an issue for you. I have gone down the path of having separate storyboards, and didn't find any advantage organizationally. It wasn't worth keeping track of which view was in which storyboard.
Once you move to a universal app it is probably more useful to have one storyboard for iPhone and one for iPad. I currently have 3 storyboards, and they are not organized according to what type of view, but which environment will be using the views.
iPhone Storyboard
iPad Storyboard
Shared Storyboard(some views you will use between both)
For me, storyboards are nothing more than just a container to dump my views, and prevents a bunch of separate .xib files all over the place(initialization of ViewControllers from the storyboard is much simpler though). I used segues for maybe a week, but then the app's needs quickly outgrew the limited benefit of transitions.
It is actually really easy to copy and paste between storyboards, so don't be afraid to try a bunch of different arrangements to see what you like. You'll just need to adjust which storyboard you instantiate the object from obviously.
I am new to iOS and was wondering which is the best to learn. I have read some of the answers here and SO, but some people say use Storyboards will others say learn XIBs first. Is there any real benefit to learning XIBs? Are XIBs easier to understand and will help with storyboards?
There is benefit to learning both approaches.
Apart from the historical value in the xib approach, xib's also provide modularity. Perhaps you have a library of code or wish to share a useful widget you made. Taking the xib approach would facilitate that sharing and reuse.
The xib approach also allows you some greater flexibility in terms of your own code. For example, iOS 5 contained a bug with UITableView and Accessibility/VoiceOver support that would cause -dequeueReusableCellWithIdentifier: to return nil despite being documented otherwise (see this blog post for further details). To dynamically load table view cells from xib provided the ability to work around the bug.
While the table and tablecell support in Storyboards is wonderful and provides support for what most people need to do in a table, sometimes you have to color outside the lines, you might need lots of different cells, and again, dynamically loading from xibs can be your solution.
One big advantage of Storyboard is the ability to view your entire application's GUI flow. Zoom out and you can see how everything interconnects and flows. With xibs, while the modularity is nice, it's tougher to envision how everything connects and flows together. This can be a useful feature for yourself, or if you have a larger team to share with, to allow others to see how the app flows.
There's value in both approaches, and it's good to know both so you can pick the best tool for your task at hand.
Update 2014-10-06 - Since I wrote the above, I've been involved in more projects. Some with xib, some that could use storyboards.
Storyboards have matured a great deal (we're at Xcode 6 now), and there's a great deal with them that's so nice. I really love how so much more can be done within a storyboard that is a bit more complicated in a xib-approach. A couple examples:
One is when working with UITableView or UICollectionView how much you can work with prototype cells directly in the storyboard. A lot of nice and easy setup, most of the heavy lifting can be in the storyboard, less code. It's quite nice. Trying to do this in the xib approach is certainly do-able, but there's a lot more work to make it happen.
Another is how nicely you can transition between UIViewControllers with the regular segues then go back with unwind segues. All right there in the storyboard, with minimal code. It's just so handy.
But the one thing that still kills storyboards for me is trying to use them in collaborative environments. It's just not going to merge well. And in some regard, it's not even if you're working on a team of > 1 person. If you yourself take advantage of version control, use a good branching and merging model for your own personal workflow, there may come a time where some change is going to have to be made in some branch that has to be brought into another branch, and oh the pain. To me, this is what kills storyboards.
As time and work has evolved, what I'm finding for myself is storyboards are great for prototyping. The ability to get things going quickly is a huge benefit of storyboards. There's much speed in using them. But the speed comes at cost. When it comes to writing the "real" code for some project, I'm just going to stick with xibs because while it may be more work, it's a more flexible route that just works better in larger teams or over time.
Update 2015-04-07 Another update, because the projects of the past some months have forced me to use storyboards, which has provided more insights.
First, some things will mandate one approach or another. For example, apparently there were some edge case bugs when working with size classes in xibs that didn't exist doing the same thing in a storyboard. So if you get affected by bugs, that may force your hand one way or the other. Another is to remember that storyboards generally work on the UIViewController level, so if you need to do something like have a UIView or a UICollectionViewCell to load, that's probably going to be better served by a xib.
Second, and I don't know why this didn't occur to me at first, but there is nothing that requires you to use a singular storyboard for your entire project! I think the nature of storyboard enables people to gravitate that way, but we have to remember nothing mandates that (that I'm aware of).
What I've found works well is to generally approach each "view grouping" per storyboard. That is, often your ViewControllers tend to be isolated and wind up being 1 per storyboard (or xib). But you might have a situation where you have two closely-related ViewControllers, and it makes sense to put them into the same storyboard, especially because then you can easily hook things up between them, such as segues.
The main advantage to multiple storyboards? Working in teams. This way Fred can work on his storyboard and Wilma can work on her storyboard, and there's no strong worries of merge problems or work coordinatinon! The use of multiple storyboards (and generally 1 ViewController per storyboard) has been a huge help in the use of storyboards on a multi-person dev team.
It's pretty evident Apple wants us to prefer storyboards, and I'm embracing them more these days. Using multiple storyboards, but still using a xib when needed, is working fairly well now.
Update 2015-09-21 Now that Apple's released Xcode 7, there's even more reason to adopt storyboards, as Apple works to overcome the shortcomings.
The most important improvement is storyboard references, which allow you to create in one storyboard a reference to another storyboard. It's dead simple to make, and now you can have cross-storyboard segues (both entrance and exit). I've used this a few times already on a new project and it's just a joy.
Another improvement is that you can create stand-alone UIView classes within a storyboard. However, as of this writing I've had mixed results with it. Simple cases work out ok, but some more "complicated" stuff did not. For example, I had a UIViewController with a UITableView within it. Since it was to be a simple table with 5 static cells, I merely instantiated the 5 UITableViewCells as a part of the ViewController in the storyboard. Seemed to work, but then at runtime nothing would actually load and show up; moved the UITableViewCells into a xib, and all worked. I'm not sure if I was doing something wrong or what it may be, so YMMV. But still, even if there's just some quirks, in time I'm sure Apple will resolve them and then another barrier against storyboards will fall. I would say that if you need such support, you should try it and see how it goes for you. There's great promise.
More and more, storyboards are shaping up to be excellent.
There are things you can do with a storyboard that you can't do with a nib. A storyboard lets you create segues between view controllers, and it lets you design table view cells in-place.
There are things you can do with a nib that you can't do with a storyboard. In a nib, you can create references to the File's Owner placeholder. You can create multiple top-level views, edit them, and create connections between them. See this answer for an example of why you'd want to do that. You can add external object placeholders (a rarely-used feature).
Storyboards have the drawback that they collect a bunch of different, loosely-related objects into one big file. If you're working on a project with several developers, you are much more likely to run into merge conflicts if you're using a storyboard than if you're using xib files.
You should definitely learn about nibs at some point. Whether you want to start with them or start with a storyboard is probably not too important. Just find some tutorials you like and work through them with whichever type of file (nib or storyboard) they use.
Are there any guidelines on when to use storyboards in an iOS project and when to use XIBs? what are the pros and cons of each and what situations do they each suit?
Near as I can tell it's not that clean to use storyboard segues when you have view controllers being pushed by dynamic UI elements (Like map pins).
Update 1/12/2016: It's 2016 and I still prefer laying out my UIs in code and not in Storyboards. That being said, Storyboards have come a long way. I have removed all the points from this post that simply do not apply anymore in 2016.
Update 4/24/2015: Interestingly Apple doesn't even use Storyboards in their recently open-sourced ResearchKit as Peter Steinberger has noticed (under the subheading "Interface Builder").
Update 6/10/2014: As expected, Apple keeps improving Storyboards and Xcode. Some of the points that applied to iOS 7 and below don't apply to iOS 8 anymore (and are now marked as such). So while Storyboards inherently still have flaws, I revise my advice from don't use to selectively use where it makes sense.
Even now that iOS 9 is out, I would advise against to use caution when deciding whether to use Storyboards. Here are my reasons:
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. Update: My new tool StoryboardLint mostly solves this problem.
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. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
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. (Thanks to Sava Mazăre for this point!)
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. (Thanks to thoughtadvances for this point. See the original comment)
Storyboards can make your code more complex: When you create your view controllers in code, you can create custom init methods, for example initWithCustomer:. That way, you can make the customer inside of your view controller immutable and make sure that this view controller cannot be created without a customer object. This is not possible when using Storyboards. You will have to wait for the prepareForSegue:sender: method to be called and then you will have to set the customer property on your view controller, which means you have to make this property mutable and you will have to allow for the view controller to be created without a customer object. In my experience this can greatly complicate your code and makes it harder to reason about the flow of your app. Update 9/9/16: Chris Dzombak wrote a great article about this problem.
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
These are my reasons for why I really don't like working with storyboards. Some of these reasons also apply to XIBs. On the storyboard-based projects that I've worked on, they have cost me much more time than they have saved and they made things more complicated instead of easier.
When I create my UI and application flow in code, I am much more in control of what is going on, it is easier to debug, it is easier to spot mistakes early on, it is easier to explain my changes to other developers and it is easier to support iPhone and iPad.
However, I do agree that laying out all of your UI in code might not be a one-size-fits-all solution for every project. If your iPad UI differs greatly from your iPhone UI in certain places, it might make sense to create a XIB for just those areas.
A lot of the problems outlined above could be fixed by Apple and I hope that that's what they will do.
Just my two cents.
Update: In Xcode 5, Apple took away the option to create a project without a Storyboard. I've written a small script that ports Xcode 4's templates (with Storyboard-opt-out option) to Xcode 5: https://github.com/jfahrenkrug/Xcode4templates
I have used XIBs extensively and completed two projects using Storyboards. My learnings are:
Storyboards are nice for apps with a small to medium number of screens and relatively straightforward navigation between views.
If you have lots of views and lots of cross-navigation between them the Storyboard view gets confusing and too much work to keep clean.
For a large project with multiple developers I would not use Storyboards because you have a single file for your UI and cannot easily work in parallel.
It might be worth for large apps to split up into multiple storyboard files but I have not tried that. This answer shows how to do segues between storyboards.
You still need XIBs: In both of my Storyboard projects I had to use XIBs for custom table cells.
I think Storyboards are a step in the right direction for UI implementation and hope Apple will extend them in future iOS versions. They need to resolve the "single file" issue though, otherwise they won't be attractive for larger projects.
If I start a small size app and can afford iOS5 only compatibility, I would use Storyboards. For all other cases I stick to XIBs.
Storyboards were created to help developers visualize their application and the flow of the application. It is alot like having a bunch of xib but in a single file.
There is a question similar to this located What is the difference between a .xib file and a .storyboard?.
You can also create custom transitions via code that will change dynamically if needed, much like you can with .xibs.
PROS:
You can mock up flow of an application without writing much, if any code.
Much easier to see your transitions between screens and your application flow.
Can also use .xibs if needed with storyboards.
CONS:
Only works with iOS 5+. Does not work with iOS4.
Can get cluttered easily if you have a very view intensive application.
There really isn't a right / wrong when to use one or the other, it is just a matter of preference and what iOS versions you are wanting to use.
I will just state 4 simple reasons why you should use storyboards, especially in a productive environment where you have to work in a team of product owners, product managers, UX designers, etc.
Apple has GREATLY improved working with Storyboards. And they encourage you to work with them. Which means they will not break your existing projects with updates, they will ensure that storyboards are future proof for newer XCode/iOS versions.
More visible results in less time for the product owners and managers, even during the creation phase. You can even use the storyboard itself as a screenflow diagram and discuss it in meetings.
Even after an app is done (and that's generally where its life-cycle begins) – in the future it will be faster and easier to apply small adjustments. And these could very well change multiple aspects of your layout at the same time, which you probably want to see in a WYSIWYG manner. The alternative would be hand-writing UI changes in code and switching back and forth between the IDE and the simulator to test it out, each time waiting for compile & build.
Non-developers can be taught to set up layouts in storyboards and create the necessary hooks for the developers (IBOutlets and IBActions). That's a very big plus because it lets the devs focus on the logic and the UX designers apply their changes in a visual manner, without having to write any code at all.
I won't write up any CONS, since Johannes has already listed probably all the viable ones in his answer. And most of them are definitely not viable, especially not with XCode6's major improvements.
I don't think there is a right answer for your question, it's just a matter of personal experience and what you feel more confortable with.
In my opinion, Storyboards are a great thing. It's true, it's really hard to find out why your app is misteriously crashing at runtime, but after some time and experience you'll realize it's always related to some IBOutlet missing somewhere and you'll be easily able to fix it.
The only real issue is working in team under version control with storyboards, in the early stages of development it could be a real mess. But after that first stage, UI updates that completely changes the storyboard are very rare, and in most cases you end up with conflicts in the very last parts of the xml, which are segue references that usually autofix themselves when you re-open the storyboard. In our team work we prefered to deal with this instead of heavy view-controllers with tons of view code.
I've read many comments againts auto-layout. With XCode5 it got really improved, It's really good even for autorotating layouts. In some case you'll have to do something in code, but you can simply outlet the constraint you need to edit and, at that point, do what you need in your code. Even animate them.
I also think that most of the people who dislike storyboards didn't fully try to understand the power of a custom manual segue, where you can totally customize (in a single file) the way you transition from a way to another and also (with some tricks) even reuse a previously loaded view controller by just updating it's view contents instead of fully reload the whole thing.
At the end you can really do the same things as in code, but I think you have a better separation of concerns with storyboards, but I agree that in many things they lack of features (fonts, image as color background, ecc...).
I am not using StoryBoard or XIBs in my any of the app.. but creating everything programmatically.
∆ Benefits :
√ You can create any complex kind of UI or transition animations for UIView's.
√ Support all iOS versions. No need to worry about < iOS 5.
√ *Your app would support all iPhone/iPod/iPad devices within your code.
√ You're always updated as you know the code that'll always work.
√ *Will work on any (new) device launched – No need to change in code.
√ Everything is upto you. At certain place you want to change something – No need to look into storyboard or xib. Just search for it in particular class.
√ Last but not the list – You'll never forget that, how to manage everything programmatically. This is the best thing as you know a control very deep then anyone.
I've never find a problem by not using SB or XIBs as I'm good with this.
* if you've set UIKit's object frames according to screen size.
P.S. If you've still not done this thing – you may faced difficulty (or may feel boring) but once you get familiar with this – its really a Candy for you.
If you are about to care about Storyboard performance, watch WWDC 2015 Session 407
Build Time
When interface builder is compiling a storyboard it's doing two things
first, it's trying to maximize the performance of your application and
secondly it's also minimizing the number of nib files created.
If I have a view controller with a view and a bunch of sub views,
interface builder, the build time is going to create a nib file for
the view controller and create a nib file for the view.
By having separate nib files for both the view controller and the
view, this means the view hierarchy can be loaded on demand.
Run Time
When you allocate a storyboard instance using UI storyboard, API,
initially all you are allocating memory for is the UI storyboard
instance itself.
No view controllers no views yet.
When you instantiate your initial view controller it will load the nib
for that initial view controller but, again, no view hierarchy has
been loaded yet until someone actually asks for it.
I have been working on a reasonably sized project (>20 scenes in storyboard parlance), and have come across many limitations and have to repeatedly go to documentation and google searches for doing things.
The UI is all in one file. Even if you create multiple storyboards, you still have many scenes/screens in each storyboard. This is a problem in medium-large teams.
Secondly, they do not play well with custom Container Controllers which embed other container controllers etc. We're using MFSlideMenu in a Tabbed application and the scene has a table. This is almost impossible to do with a storyboard. Having spent days, I've resorted to doing the XIB way where there is complete control.
The IDE does not allow to select controls in zoomed-out state. So, in a large project, the zoom-out is mostly to get a high level view and nothing more.
I would use storyboards for smaller applications with small team sizes and use XIB approach for medium-large teams/projects.
If you want to reuse some UI in multiple view controllers then you should use XIBs
What are the main differences between using Storyboards and xib files.
Specifically,
what are the advantages or disadvantages of using a Storyboard?
Unfortunately, despite doing quite a bit of research, all I've been able to find on Storyboards are simple tutorials that show you how to set up a Storyboard, instead of concrete information explaining what they are.
A Storyboard is:
A container for all your Scenes (View Controllers, Nav Controllers, TabBar Controllers, etc)
A manager of connections and transitions between these scenes (these are called Segues)
A nice way to manage how different controllers talk to each other
Storyboards give you a complete look at the flow of your application that you can never get from individual nib files floating around.
A reducer of all the "clutter" that happens when you have several controllers each with it's own nib file.
I have been using Storyboards for awhile now and the ONLY downside is that you can't target iOS 4 or below. Storyboards only work on devices running iOS 5 or better. Other than that, the benefits are many and the downsides are non-existent IMO.
The best tutorial I have seen is Ray Wenderlich's
Also, if you are a member of the Apple Developer program, check out last years WWDC session on Storyboards (iTunesU), it is awesome.
Another great one (also on iTunesU) is the latest Stanford iOS Application Programming course.
There are not only pro sides of Storyboarding, also cons - just because you asked for input:
it's not easy to work with SBs in a team, since only one participant can work on the SB at once (because it's one file).
-The following is not true:
- if you need to do things SB doesn't offer, it's not quite easy to get SB mixed with programatical created views (well, it is possible though)
The rule of thumb seems to be: the more complex you expect your project to get, the more you'll better not go for SB.
EDIT:
- another disadvantage of SB: working around all the annoying bugs of XCode regarding SB. E.g. having to frequently flush the DerivedData folder because of several inconsistencies. Sometimes storyboard files or the link to them get corrupted. Then you might have the joy to search for the problem. Take a look at this thread to get the idea
EDIT 2 (March 2013): meanwhile Storyboards and Xcode are working much better, and documentation and best practices are wide spread. I think working with storyboard can be recommended for a majority of projects, even if there are still some glitches.
EDIT 3 (Sept 2013): now with the new Xcode 5 format working in teams with SB might get even better, as it seems to become possible to merge SB-code much easier now.
Another EDIT: well, if you have an hour of time, sit back, relax and listen to these guys discussing this topic (Ray Wenderlich & Co)
Edit 2016.1: after a long time being a Storyboard advocate, I had so much hassle with it the last months, that I decided to abandon Storyboards as far as possible. The reason for that is that Apple adds feature like stupid, but doesn't care about the bugs and the flaws. The performance having a lots of auto layout constraints is really bad (while design time), and the error-prone-ness has become huge.
Example: even less complex Storyboards tend to get into a 'dirty mode' right after opening a project in Xcode (see git state).
Tip: as a beginner you will love Storyboards since you can prototype quickly and get things running without lots of code. As you enter an intermediate state, you'll add more GUI code to your project. Now you start going back and forth between code and SB - and things start working out worse. Sooner or later you'll tend to do most of the GUI stuff in code, because the result is more predictable than having several sources.
Summary
Nibs/.xib files and Storyboards both are Interface Builder files which are used to visually create user interface for iOS and Mac applications in Xcode (i'll use iOS terminology for classes as this question is tagged iOS but it also applies to Mac programming).
Differences
Nibs are intended to be used with a single UIView. They can also be connected to a UIViewController subclass by settings the class of File's Owner to any subclass of UIViewController and connection the view outlet (drag to connect using the Connections Inspector in the far right pane of Xcode).
Storyboards are intended to contain the user interface for 1 or more UIViewController. You can build your entire user interface in a single storyboard or separate it into smaller parts.
Advantages
Storyboards should always be used in favor of .xib files/Nibs (for view controllers). Storyboards have more features and are actively developed by Apple.
Every argument in favor of Nibs rely of the fact that they used individually while storyboards contain many scenes. You can use a single storyboard for each UIViewController just as easily as you can with Nibs (see code samples below). Keep reading for a detailed explanation and code examples.
Detailed
Why are Storboards superior to Nibs?
The answer basically comes down to Apple encouraging the use of Storyboards and putting more development effort into them.
Storyboards have zooming capability which Nibs lack. Seriously, you can't zoom at all in Nibs which sucks when designing for bigger screens on a small laptop.
Nibs are missing key functionality like:
Prototype and dynamic cells for UITableView (more info)
The top layout guide property (see comment)
There are probably more, please edit or comment if you have something to add to this list
You don't need to mess with setting the class of Files Owner.
The basic argument against storyboards is that having all your view controllers in one place leads to merge conflicts, a slow Xcode, slow build times and being a general pain in the butt to maintain. Hence, general advice is to use a Nib for each UIViewController.
But... You can just create storyboard for each UIViewController. A common practice (for me at least) is to hide all the UIViewController initialization in a class method (as no other class needs to know the name of the file where the controller's Nib/Storyboard is located).
Lets compare the related code snippets that one might use to create such a method. A single line of code is the entire 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];
}
Usage
- (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)
}
Usage
func showMyViewController() {
let vc = ViewController.create()
self.presentViewController(vc, animated: true, completion: nil)
}
Arguments
I'll address all the usual arguments for Nibs; as I mentioned earlier, there are mostly in favor of single files, not as an argument for Nibs over Storyboards
Teams and merging
Argument: Having a storyboard with lots of view controllers will
cause merge conflicts if you are working on a team with multiple
people making changes
Response: A single storyboard causes no more merge conflicts than a single Nib
Complexity
Argument: Very complex apps have a lot of scenes in the Storyboard which leads to a giant storyboard that takes forever to load and is barely comprehensible because of it's size.
Response: This is a great point, but you can easily break Storyboards into smaller parts. Storyboard References look like a great feature that can be used to link Storyboards together but they are only available in Xcode 7/iOS 9+. Also, still not a reason to choose individual Nibs over Storyboards.
Reuseability
Argument: Creating a Nib for each UIViewController subclass lets you reuse code so you don't have to setup all your constraints and outlets for each scene in your storyboard.
Response: Again, not a reason to choose individual Nibs over individual Storyboards.
There was a nice presentation about Storyboard given at the LiDG meeting a couple of months ago.
Personally, I'd say it's the way to go with a new app. There are some gaps, especially for very complex apps, but the pro's mostly outweigh the cons.
Some more benefits of storyboards:
Storyboards have better support for tableviews. That is you can use
"Dynamic" and "Prototype" cells.
It is easier to instantiate view controllers using storyboards. You can do stuff like: [se lf.storyboard
instantiateViewControllerWithIdentifer:]
Storyboards support view controller containers, so you can have child view controllers layed out graphically.
Downsides are:
Storyboards are slow to render in XCode when they contain lots of view controllers
Autolayout can not be enabled for one view controller in the storyboard.
Be careful, if you use Storyboards your app is not backwards compatible with older OS installations.
A storyboard is basically a device to make your job as a developer easier. It is complied into a series of nib files, so the performance is pretty much equivalent, but it's great as a developer to be able to look at a quick overview of your entire application flow.
I'm starting to transition to using storyboards on new projects, providing I can convince the client to accept iOS 5 as a minimum version. This is purely because I prefer to do it this way, and it takes me less time to accomplish the same tasks.
Your attitude toward Auto Layout may also affect whether you want to use Storyboards. Using xibs you can enabled or disable Auto Layout is on a per .xib basis, allowing for a mix within your application, while Storyboards apply your choice to ALL views they contain.
You see the big picture in one second. Having many NIB files, well, you don't see the big picture.
Easier to maintain your programs. Easier to understand others programs... among others.
Advantages:
1) It's very nice to design interfaces
2) You can use StoryBoard Segues to identify navigation/modal relationships in a cool manner.
3) If your app supports multiple devices, it's a good way to organize different views.
4) Prototyping is another added advantage.
5) Prototype UITableViewCell can save time and it reduce the amount of the code too.
6) you can see all the screens of the app at one place by using StoryBoard.
7) You can easily view the relationship among them
8) if you are working on someone's code you can get the better understanding of the flow of the app.
9) You can setup the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from storyboard, without running the app again and again.
10) Clients can see the prototype of the app before start developing it, here storyboard helps you a lot.
Disadvantages:
1) It is only available in iOS 5+
2) StoryBoardSegues are kind of rigid and you may make use of prepareForSegue many times.
4) Like IB, not very friendly with other display engines and toolkits.
4) Makes it hard to share designs for a single view or set of views - you have to send all or nothing.
5) For storyboard you will need a big screen specially in case of iPad.
6) Difficulty while copying views from other apps to storyboard.
7) Problems in storyboard when multiple developers work on the same project by using git repository
copied from some resource
Storyboards have many more problems than benefits. Here's is a list of their problems, copied from iraycd:
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. Update: My new tool StoryboardLint mostly solves this problem.
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. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
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 make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.
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 not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.
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. (Thanks to Sava Mazăre for this point!)
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. (Thanks to thoughtadvances for this point. See the original comment)
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
Prior to iOS 7, Storyboards were kind of neat but not a must have. They introduced as many problems as they solved. iOS 7 tilted the balance towards Storyboards.
With iOS 8 and 9 this is not a question anymore: Use storyboards!
The main downside of storyboard is that you're completely dependent on XCode, and you might end up spending hours spinning your wheels on XCode bugs. But XCode has gotten a lot better, and the advantages with Storyboards are now too numerous to ignore. Table view cell prototypes, Size classes, auto layout support and so on.
Some Tips:
Think of each Storyboard as a container for view controllers that
belong together. Don't think of it as a grand layout of your entire
application.
You might need more than one Storyboard
Segues are really only useful for the most trivial use cases - they're great for that. But in a real world app many transitions will happen from within code.
And that's OK.
Write a category to programmatically instantiate view controllers
from the storyboard(s) so all you have to do is let
vc=SomeViewController.create(), where the method handles all the
details (pull story board, pull view controller out of story board
etc).
I'm working on 2 iOS apps using the "multiple nib files method".
I came across storyboards not long ago and this seems really great in terms of efficiency.
Any reason not to switch to storyboards (for quite simple applications) ?
Are there any stuff that were possible in the old methods that are not more possible now ?
The answer is... it depends. Storyboards are all fine and dandy, but there are circumstances where multiple nibs are still beneficial. For example, if you are using a scroll view to swap multiple subviews on and off screen then it's far easier to design each subview in its own NIB, then load and add them programatically.
I have found a comfortable compromise: I use a storyboard for the main app screen and any major state transitions (e.g. a 'main' mode to a 'config' mode), but I still use separate NIBs for subviews which are off-screen to start with (e.g. dynamically created popovers not tied to a fixed UI element.) I get the ease and efficiency of storyboards for big stuff which could be a bit tricky in the past, but I get full flexibility for designing very dynamic UIs using separate NIBs.
Anecdotally, I have heard that storyboards are a particular pain for people developing in teams of any significant size. They are extremely hard to share, and they make dividing up responsibilities for separate areas almost impossible. Separate NIBs work perfectly in those cases.
They're another tool, nothing more. They're certainly not a complete replacement (at least, not yet.)
The main reason you might stick with NIBs and programmatic transitions rather than a storyboard is to retain compatibility with iOS 4 and below. Once you're supporting iOS 5 only there's going to be very little reason for using NIBs, however they'll still be useful for any occasion when you want to be able to load a resource on demand, possibly several times.
So, off the top of my head, I'd still expect to use NIBs to design UITableViewCells and other similar content, and as a way to store graphical-type data in a way that's visually editable.
I'm not sure how common a practice it is, but often when I want, say, for the palette used by a program to vary from target to target or by locale, I find it more manageable to create a NIB with a bunch of views set to the relevant palette colours and to programmatically load the NIB and pull the colours out. I find that to be a good solution because you set the visual properties of the thing through a visual editor, built right into the IDE.
I like storyboards over "multiple nib files method". Only difficult part i encounter in storyboards is Control object. Messaging between two views are little difficult but once you understand it will be very easy. All the stuff is possible which you can achieve by multiple nib files method. I will recommend you to use storyboards over multiple nib files.