Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've been writing iOS apps for a while now and gradually went from doing the UI entirely programmatically to using the Interface Builder intensively. I'm now thinking about using the new Storyboarding feature for some of my new projects, but I don't have enough experience or knowledge with it to calculate the advantages and disadvantages of doing so.
Can anybody give some examples or information about when using Storyboarding payed off and when it was a waste of time?
Advantages of Storyboarding
It's cool - suave way to design interfaces
Use of StoryBoardSegues to identify navigation/modal relationships
If your app supports multiple devices, good way to organize different views (by storyboard file rather than naming, etc)
Nice for prototyping
Prototype UITableViewCell can save time
Disadvantages of Storyboarding
It's a runtime feature, so I believe it is only available in iOS 5
StoryBoardSegues are kind of rigid in my experience and you may make use of prepareForSegue a lot
Like IB, not very friendly with other display engines and toolkits
Makes it hard to share designs for a single view or set of views - you have to send all or nothing
These seem kind of superficial, I guess I haven't given it much thought... At first I was gung-ho about story boards, but now I've reverted to IB or even just programatic view configuration... The more I use them, the less I like them, and the more they feel like a gimmick/waste of time.
Edit
I wrote this answer a few years ago. I have left it the same as before for posterity, although some points are likely no longer relevant (ie the fact that it requires iOS 5+).
After some time, my opinion hasn't changed on storyboards. As others have mentioned, they're okay if you are working solo on an app with few views to manage, but they become a real pain with source control & collaboration. In addition, I prefer one-file-one-object, and storyboards obviously bundle stuff together (as does IB, but to a lesser extent).
If I were writing an app meant to be maintained for any serious length of time, I would go with programmatic view configuration over IB, but definitely IB over storyboards.
Another disadvantage with Storyboarding not mentioned is that merges can be very difficult if not impossible if there are conflicts.
Update: It also occurred to me that it puts logic in two places. If your segue is not doing the right thing it might be because of an error in prepareForSegue or it might be because you named your segue incorrectly. Doing things programmatically is, in the end, not that hard.
At the latest WWDC (2013) Apple Devs strongly recommend using storyboard and built in IB stuff to do most of your code for you instead of writing it by hand because you are much more likely to avoid deprecation and take advantage of feature updates via automated conversions.
The lone disadvantage is the difficulty in allowing git collaboration on storyboards, as there will be conflicts on virtually every commit.
If you are a solo programmer, you should always be using storyboards.
I have a similar background to you - I started with mostly building my iOS UI programmatically since IB was not really user-friendly, but lately decided to use IB more and more, since it is better for designing the UI and works fine for standard-elements.
With the new Xcode I switched to Storyboard, since they provide a full view of the application. It is possible to generate the complete UI (with all views) in a single File, which can be used for prototyping and which I can view my colleagues before writing the first code line. It is far better and easier than designing with photoshop or similar tools.
However if you use a lot of your own UI elements/controls or something using a different "engine" (cocos2d, OpenGL, etc.) it is usually better to generate the UI programmatically, since these "engines" are not really integrated with IB/Storyboards.
I have learn the storyboarding by following the tutorials from the raywenderlich's website and there is a lot of stuff about the storyboard.
Here is the link to site: http://www.raywenderlich.com/5138/beginning-storyboards-in-ios-5-part-1
Advantages of storyboard:
1) Before you start developing app you can see all the screens of the app.
2) You can visually see the relationship between each screen.
3) It can help to reduce the amount of the code specially in case of UITableView you can use prototype cells and static cells to design your TableView in storyboard.
4) In case if you have to work on someone else code you can get the better understanding of the flow of the app by viewing storyboard in short time.
5) 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.
6) If you are doing client based work then some clients want to see the prototype of the app before start developing it, here storyboard helps you a lot.
Disadvantages of storyboard:
1) For storyboard you will need a big screen specially in case of iPad.
2) I also experience a difficulty while copying views from other apps to storyboard.
3) I also experience problems in storyboard when multiple developers work on the same project by using git repository.
By reading and understanding the advantages and disadvantages you can judge your self when to use storyboard.
One Word (DON'T)
One of the biggest disadvantages of storyboard aside from the git conflicts that make it impossible for two or more persons to work on it. but also if the project went so big and you have +40 screens , if you insane enough to move anything just one pixel in any view controller you have in the storyboard, you'll have a very huge compilation time, that you can build your app and make it run in more than 5 minutes, and of course don't let me start with archiving to give some one adhoc of the app .
after this painful experience I totally fell back to the oldy goldy great xib files and deleted the storyboard file in a huge fire celeberation .
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been in a struggle for a long time with this one.
Lets say I have a UIViewController and need to place an UIImageView with an UIImage in that controller.
So I have two ways to do it:
1.) Via Storyboard
2.) UIImageView *imageView = [UIImageView new];
imageView.frame = CGRectMake(bla, bla, bla);
[self.view addSubview: imageView];
Also I need to support different screen sizes (from iPhone 4 till iPhone6+), and autolayout with constraints isn't fully clear for me. And I'm sh*tcoding like
int wrapperHeight = (screen.height == 480) ? 100 : 200
I feel that i'm doing something wrong.
When i started to learn objective-c, I have seen some opensource projects, and there was no storyboard at all, so i thought that adding views programmatically is a good practice.
Could you please explain me the "right way" ?
I'd say that most of the times storyboard with autolayout is the best choice. It has a number of advantages:
It separates presentation from the logic. Creating the entire interface in a controller is usually a bad design. And for simple interfaces declaring them in an imperative way brings in to much overhead. Very often you'll end up having hundreds of lines of code for the interface that could be done in a storyboard or xib in a 10 minutes without any effort.
With storyboards you have a great WYSIWYG editor, where you can see how the screen will look like on different devices without having to rebuild the project and run it on dozens of devices or simulators. Well, not dozens but 4 different resolutions for iPhones + 2 resolutions for iPads stills a lot. Also there may be tiny differences in text sizing and rendering between retina and non-retina screens
Autolayout. Of course, you can use it in code as well, but default apple's interfaces for them suck. There are some 3rd party libs which make working with autolayout a bit easier, but anyway with storyboards you're not gonna worry about autolayout in code at all in ~80% of the times. And the rest 20% would be just something like adding constraint outlet to the controller and then changing it's constant or priority with a single line of code
Size classes. Again, you may work with them in code, but with storyboards you'll probably wouldn't have to. Size classes allow you to have one single interface for all possible device form-factors, different device orientations, etc. Before size classes developers had to have 2 different sets of interfaces for iPhones and iPads.
However, there are certain places where storyboards aren't the best way to achieve the goal. For example, if you have some view that is used in different places of the app. With storyboards-only approach you'd have to have copies of this view in many places, so when making changes in one of them - you have to remember to make this changes in other copies as well. In such cases it's better to use a separate xib file with such view and then use it in a storyboard.
Also, autolayout may be quite expensive in terms of performance. So if your app starts lagging and you determined (with profiler) that autolayout routines are the reason of the lags - then it may make sense to handle creation and layout of certain views in code manually. But this could be the case only for a really complicated interfaces. Most of the times performance wouldn't be an issue.
You said that autolayout isn't clear for you. That's not the reason to deny using it. You'll have to do a lot more work to make an app look good on all devices without autolayout than with it. "some opensource projects" that you saw could have been written for the first iPhones (4s and before), which all had the same resolution in points and where all sizes and positions could be just hardcoded. Now, as I said earlier, we've got almost a dozen of different resolutions. And handling that all in code manually is a real struggle. Autolayout would make you life easier :)
Also you may take a look at these debates about when and where to use storyboards, xibs and manual view handling: http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate
And on the same site (http://www.raywenderlich.com) you could also look up for autolayout tutorials to understand it better.
Both ways has its own advantages, as a programmer you should be comfortable with both, and to use which one depends on your situation, sometimes its easy to use storyboard/xib and sometimes its easy to build view programmatically
Some advantages of creating views programmatically -
Better to work with team. It's easier to merge code and resolve conflicts when committing to a repository than it is in case of storyboard.
When debugging it's easier to trace errors and you don't have to look to IB.
Creating views programmatically gives you more control
Some advantages of adding views in storyboard -
It's faster to develop view in storyBoard, it helps you to put everything together, like centering views,aligning them, connecting their actions etc.
Your code is not crowded with UI related stuffs, so you have much cleaner code.
Also for people who just start developing apps, its pretty easier for them to use storyboard, and gives them confidence as they can see things they are building.
Bottom line is it depends on your situation and you should choose wisely, suppose you have static UI that doesn't change much or animate, its always easier and faster to use storyboard, but if you have some dynamic UI like it has lot animations and you need to manipulate your constraints then its easier to build your UI programmatically
Also keep in mind that XIB file loading time is longer than build UI programmatically.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So I'm new to iOS development and I found it easier to write the views all programmatically. So my views have UIViews, ScrollViews, UIButton, UILabel all created and positioned programmatically. (So I never used AutoLayouts).
I've now pretty much finished my app and want to make the iPad views, and realized maybe it was a bad idea to do it like this.
Is this bad practice or should I really be using auto layouts as much as I can?
If it's ok to do it how I'm doing it right now, what is the correct way to add different views for iOS and iPad? I've seen this answer below on how to find the device, is a simple if else statement sufficient? - iOS: How to determine the current iPhone/device model in Swift?
I am using programatic views in a live app and its awesome. A bunch of people I know us this as well.
Here is a little algorithm I use to choose between the two methods:
Are you building a fast app for a client or a hobby? Use storyboard with autolayout.
Are you building an open source project that will be used by many people? Use programatic UI
Are you building an app for the long run? (1+ year) Use programatic UI
Its also harder to make an app thats supposed to be rotated without autolayout. Because doing that with code takes much more work than autolayout. Most good apps dont use this feature anyways so I don't see much problem.
A good tip is never to use constants while writing programatic UI.
If you are going to make a button thats 100px in width, do not type in 100px anywhere in the code. Instead figure out the screen sizes and place the main views according to screen sizes. Then place the subviews or secondary views according to the position of the main views. If you do this correctly you will have more powerful multidevice layout support than autolayout.
Here is a little library I wrote, please inspect and play with the code on how I place the view: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift
Also here is a good article I like about this:
http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
This is only fine, If you have enough time, patience, good skill on calculations and relationship configurations between different UI elements.
However, using Auto Layout is pretty useful and low time consuming than manual calculations.
We can easily create a dynamic and versatile interface that responds appropriately to changes in screen size, device orientation, and localization with minimal effort.
Read Adopting Auto Layout,to implement the Auto Layout in your existing application
TL;DR
It depends
Longer version
Clearly one size does not fit all. AutoLayout is pretty powerful both in Interface Builder and code (be it visual language format, or simple constraint setting), but sometimes it just seems like you're "rubbing your right ear with your left hand" - that's when adding views programmatically comes in. But beware of not having it different in each view controller - you don't want to introduce too much complexity in your project, right?
I personally like using AutoLayout as much as I can and whenever I can't use it anymore, or the StoryBoard View would get too messed up with millions of constraints, I try to separate views into containers - have the container be resized by AutoLayout and have the subviews handled by code.
Example would be a custom Media Player - maybe I want to have two stripes below and above the video - I could have the video and two UIView extended stripes handled by the AutoLayout. But the subviews (controls) in the stripes themselves would be added by code. It gives me the control over my code but still it doesn't introduce too much complexity.
First of all - if you want to develop for iOS you have to learn Autolayout. There are already a lot of different devices with different resolutions and maybe will be even more in future.
Secondary - if you want to work effectively with IB you have to read guide / watch tutorial videos and have some practice. It could be difficult to start but then you will realize that IB is powerful, fast and often the best way to develop GUI. Often, but not always!
Code advantages:
Easy to copy-paste and reuse GUI. It could be critical if you have
several similar views or want to reuse some old code.
Easy to resolve merge conflicts and check commits.
Easier to make styles - like the same font for all labels depending on the country.
More powerful (there are things that could not be done with IB) so you have to use it sometimes.
IB advantages:
You can see your GUI during development for different resolutions/localizations so you do not have to compile and run a project on different devices/simulators to check is GUI ok or not. Also IB will show you warnings if you forget some Autolayout constraints or there are conflicts. Saves a lot of time if you have a complex GUI with non-trivial Autolayout constraints.
It is much easier to understand someones else code if it is developed in IB. Especially important for complex GUI - not so easy to find a required label or button in a few hundreds lines of code.
Small bonus - if you want to use a custom control developed via code you can make it IBInspectable and use it without problems in IB
Just to summarize - if you do not need IB benefits (for example GUI is quite simple and does not use Autolayout) developing GUI via code could be easier and faster. But in case you have to support different resolutions and/or you have hundreds lines of GUI code in each view controller I strongly recommend to try IB.
My doubt is very simple.
I want to develop one big iOS (iPhone) app of say 30 screens.
One my friend advice me to develop whole UI in coding only and do not use XIB's or storyboard.
I want to ask that, is it feasible for me to develop whole UI in coding instead using XIB and story board?
Will that affect my iOS app processing?
Will that affect my iOS app execution speed or not?
Please suggest me the proper way weather I use XIB and Storyboard of develop UI by Coding only ..... !!!!
Thank you.
Firstly, tell your friend not to give you advices again.(Just kidding! :)) You can develop the whole app programmatically but it's just a pain in the gut. Apple introduced the storyboards to ease the waste of having multiple xib files in your product.
For my personal opinion, use xibs in case of having lots of teammates working with you because of the pain of conflicts. If you're working solo, then storyboards would be the best fit.
Yes, there is no silver bullet that will solve all of your problems, every project is specific and your ability on predicting project requirements will enable you to decide. Here are some pros and cons of both approaches to help in making a decisions:
Storyboards/XIB pros: Very visual, Beginner friendly, Easy autolayout, MVC separation is straightforward on view side
Storyboards/XIB cons: SCM conflict are almost always unresolvable, not all parameters are configurable from IB so you still need to know how to do some stuff in code
Pure Code approach pros: Full control over entire presentation in code, conflicts resolvable easy as it can get
Pure Code approach cons: Might need more experience to master
My judgment would be:
Using storyboards/XIB is better solution for small to medium projects that consist of basic/stock UI elements.
Introducing visually complex solutions and non standard transitions will require that you start writing layout code more and more and stuff becomes easier without XIBs in your way.
From my experience if you are part of the bigger dev team, Storyboards and XIBs are a big NO..
I prefer not using IB at all even for smaller projects as pressing CMD+R after writing bunch of code, and seeing it come alive is very pleasing.. :-)
To answer your question literally: yes, you can make an app without any storyboards or xibs. I think with iPhone 6/6+ you have to have at least one because they check it to see if you support the bigger screens, but that's it.
In fact, my first app in 2013 had almost no Xib UI design. It was iPhone portrait only, I coded with frames and was happy with the precise results I got-- I also think I learned a lot. I think with Auto Layout, especially if you learned Visual Format Language (albeit that's not a easy thing to do) creating a robust interface entirely in code is doable.
That said, not using interface builder is not doing things "the Apple way." And not doing things the Apple way is usually -- not always, but usually -- going to be more difficult. On one level, WWDC videos, guides and sample code all assume you are using IB. Creating every label, subview and view controller in code is going to take several more lines, each, than using xibs or storyboard. You will be swimming against the current.
It's worth noting IB can be immensely frustrating at times. But generally it's worth it, and you learning how to relate it to the code is learning iOS programming. Also about IB , the files it generates are just XML files, it won't have any significant effect on size or performance- I'd be wary of advice from someone who told you that.
An all-code app is doable and would be a challenging way to learn, but this is not advice I would give anyone or second.
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.
This question already has answers here:
When to use Storyboard and when to use XIBs
(9 answers)
Closed 9 years ago.
I am new to iOS development (No apps created yet), but I ask for advice from my friend that has really high rated apps on the market. He said not to use storyboards.
As much as I want to take his advice, they seem really helpful.
Is this something that can cause problems for my app in the future?
Is there any reason I may want to not use storyboards?
Coming from an Android background, I don't see why I should use them.
I tend to avoid storyboards for anything apart from perhaps a quick prototype. If you know you have a very simple app which isn't going to get complicated, and you're the only developer, storyboards might be ok.
Here are a few blog posts that detail some of the pain points when using storyboards:
http://toxicsoftware.com/uistoryboard-issues.html
http://blog.waynehartman.com/archive/2012/01/07/uistoryboard-on-ios-5-the-good-the-bad-and-the.aspx
Both of the above are a bit dated, but I believe the pertinent points still hold true.
Note that in theory you need to use a storyboard(s) to get static tables, which can be useful. To get this benefit, you could put only the static tables in storyboard files (note: you can have multiple storyboard files in an app) and use xibs or just code for the rest of the UI.
I'd recommend against using either storyboards or Interface Builder.
You'll learn Objective-C faster if you spend more time using it. Switching between IB and code, you'll have two things to learn. The context switching will still slow you down later on.
Nibs and storyboards are big XML files that don't play well with source control; if you're working on one at the same time as someone else, you will get merge conflicts.
You can't see everything that's going on at once in IB, so it's hard to track down things like layout problems.
You can't search or replace in IB the way you can in code
Nibs and storyboards put your view logic in your controllers. Whether that's a problem for you depends on how much of an MVC purist you are.
If you want to port your apps to/from Android, IB will make it much harder.
This all comes from experience. I started out running a small software team developing iOS apps using IB (storyboard wasn't out yet) and within a year it had caused so many problems that I'd had to forbid its use. Our productivity went way up when we stopped using it.
I think it's not important to use it or not,the most important is how your application is?(quality, beautiful, fast...).
StoryBoard is great for beginner to shorten design time and understand.
But when to become professional developer, you will love to draw your interface by coding because typing more faster than graphic.
I don't think this question is really answerable. There are pros and cons of any technical decision and this one is no different.
Pros:
Visual, so you get a much better idea of what your app will look like more quickly
Less code
Autolayout can be easier
It's not all-or-nothing. You can build the "base" in Storyboards and finish it off in code
Cons:
A big hairball of an XML file makes merge conflicts pretty nasty
Less flexibility than code (no inheritance, etc.)
If you have lots of screens in your app, using a single storyboard can get pretty difficult unless you have a vast screen!
It depends only on you. If you developing your application alone, storyboards are very useful. If you work in a team, it's better yo use .xibs because there is less problems with merging them with svn in comparison to storyboards
Very broad question. There are times when storyboards are great and other times when they are a hassle. Depends on the requirements and compatibility needs of your app.
See this answer for a great explanation of when to use storyboards and when to use XIBs:
When to use Storyboard and when to use XIBs