Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
So I'm just starting developing an iPhone application and I've been told to not use Storyboard. I've read that the alternative is using xib files - can anyone recommend good tutorials using xib files?
Thanks
Storyboards are a relatively new feature to Xcode and Cocoa. Arrived with Xcode 4.2.
For decades (see history), NeXTSTEP/OpenStep/Cocoa programmers have been building individual nib/xib files, loading them with ViewControllers. When the user does something to cause the app to move to the next nib/xib, the current view controller instantiates another view controller that loads its desired nib/xib. That new view controller is then shown on screen.
Storyboards are not magic. They just reduce your programming load a bit, handling that loading and displaying of one view controller from another. They still use the same nib/xib technology underneath, you are just less aware of it. Think of a Storyboard as an automatically managed collection of xibs. A superset of nib/xib, rather than a replacement.
In iOS, we often get the new view controller on the screen by pushing it onto a UINavigationController's stack. The Back button automatically appears to close the current view controller and return to the previous one.
There are pros and cons to Storyboards. For relatively simple apps with a certain flow of views, they can be handy.
But there are reasons to not use them. One reason is if moving from view to view is somewhat arbitrary and not easily laid out in a Storyboard. Another reason is that some views are more easily done programatically on-the-fly rather without defining any nib/xib. Typically such views have only one, or very few, components. UIListView and UIWebView are two examples of single widgets that may fill the screen and can therefore be more conveniently created in code.
Tutorial and books abound. Some show both Storyboard and non-Storyboard ways of doing things. Look for some older iOS 5 or 6 books to see more non-Storyboard ways.
Some new articles and Apple docs may push Storyboard because they are the new fresh thing. I suggest taking a more measured approach. Rather than saying Storyboards are the greatest thing or saying Storyboard are terrible, consider them as yet another tool. Sometimes you may want to use them, sometimes they not fit your needs optimally. Also you can mix them, doing part of your app with a Storyboard, and part without.
You can use storyboards (.storyboard files), use older interface builder (.xib files) or do everything programmatically.
I recommend to use storyboards, makes many things easier and less writing, storyboard is similar to interface builder and my opinion, when creating iOS app, it's better choice than older interface builder. And you still can do many things programmatically, e.g. change properties of objects created in storyboard etc.
So if someone says, don't use storyboards, it's his/her opinion and I suggest that you try it out and make your own opinion about it.
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.
I started a project using the Storyboard in Xcode 6 and now I think I would like to use XIB files. Are there any risks associated with moving from Storyboard to XIB? I thought I read somewhere that Xcode 6 would prefer developers to use the Storyboard, is this true? Are there benefits of using the Storyboard over XIB files? I feel like you have more control when using XIB files. Is there something I'm missing? Am I able to convert fairly easily or would it make more sense to start my project over?
I'm an Android developer moving into iOS, so please forgive my lack of knowledge on the subject.
UPDATE
I am more interested in knowing if there are any risks or problems in switching from Storyboard to XIB mid project. Currently, I'm using Storyboard, but I am thinking of switching some parts to XIB. Will this cause any problems with my project? Is there anything I need to be aware of in doing this?
Code, storyboard and xibs are all different ways of creating views and layouts.
There is no rule that says you can only use one of them in a project.
In most of my projects I use a combination of all three.
Storyboards give a quick and easy way to create "flow" in the app. I tend to use one storyboard per "workflow" inside the app.
Xibs I tend to use for views that are common in multiple places within the app. In a storyboard I'd have to define them multiple times. Using xibs is a bit like refactoring interface builder files.
I then fall back to using code when necessary. Sometimes it isn't possible to do what I want with interface builder.
To say that you are only going to use xibs is purely denying yourself access to the other tools. Learn when to use each and how to use them together.
There are some things like container views and embed segues that only work with Storyboards.
For the most part, though, it's a question of personal taste.
Apple does seem to be moving in the direction of Storyboards, so as a new developer you may want to put your efforts into Storyboards.
There are a lot of articles on the internet that discuss this topic, example: http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
I would take a look at the answers to this question for some great info.
Here's a quick summary:
Storyboards have some great features such as letting you create segues between views, and design table view cells in-place.
The biggest downside to storyboards is working a project with multiple developers. Dealing with merge conflicts can be a big headache.
This question already has an answer here:
Started making my app, now need story boards
(1 answer)
Closed 9 years ago.
I started developing an application, adding and coding up view controllers manually. I was wondering whether it was possible to add a storyboard after development has started? The reason I ask is that if I create a blank storyboard project with one or more linked view controllers, I do not see any of the traditional view switching code. I assume that the storyboards are doing something clever behind the scenes which I cannot see.
So if I already have two view controllers and then add a storyboard, will I damage any of the code I have already written for example?
No, adding the storyboard won't damage any code. You can (I believe) copy the nibs one by one into your storyboard.
There are some things to be aware of, though:
You don't use initWithNib anymore, you use [self.storyboard instantiateViewControllerWithIdentifier:]
Storyboards are much better, and may lead to increased productivity *.
* Your mileage may vary.
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
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 .