iOS Storyboards Vs NIBS?

[PriapusZA]

Hi guys,

So I was handed another project from an old developer who used to work for us to go over the code and app. I had a hard time getting the flow of the app down due to nib files all over the place and not knowing exactly what they did / were for.

So I went on a hunt for a storyboard tutorial and ran into one from Raywenderlich's site - it was based on iOS5's storyboards.

So, it looks a lot easier to track the flow of the app using storyboards and it seems to take away some glue code. However the negative side of things is you need a big screen - even bigger for iPad apps. Small obstacle, I think.

I hear some guys don't like Storyboards and others do - is there a reason for this?

Lastly - I'm reading that in iOS6 storyboard got a little easier with the unwind-segue button?

Appreciate any input.

Thanks guys.

 

[dantastic]

I'm not using story boards.

They may be the greatest thing since sliced cheese but I'm pretty fast at doing what I need to do with nibs so taking the time to learn story boards have not yet been a priority.

Second I think it's a lot to do with project organization. I know a lot of people dump all nibs into one group in xcode and they feel real good about themselves that their project is organized. In fact when you take over a project you don't have a clue what does what when you have a folder with 50 nibs with pretty similar names.

I prefer to put all files that makes up a logical view together in a group (folder). That way you know immediately which tableview some tableviewcell nib belongs to.

Many devs would argue that I'm completely wrong and that nibs should be in their own folder.

 

[PriapusZA]

I'm not using story boards.

They may be the greatest thing since sliced cheese but I'm pretty fast at doing what I need to do with nibs so taking the time to learn story boards have not yet been a priority.

Second I think it's a lot to do with project organization. I know a lot of people dump all nibs into one group in xcode and they feel real good about themselves that their project is organized. In fact when you take over a project you don't have a clue what does what when you have a folder with 50 nibs with pretty similar names.

I prefer to put all files that makes up a logical view together in a group (folder). That way you know immediately which tableview some tableviewcell nib belongs to.

Many devs would argue that I'm completely wrong and that nibs should be in their own folder.

I like your idea of splitting up logical views like that. I actually handed the project back to the old developer as the code wasn't commented and secondly nibs / files all over the place so I had no idea what was going on.

However with Storyboards we don't need to worry about where the nibs go. We just have one file for all our views. Maybe taking time to learn storyboards would be a benefit to things?

The reason I am asking is due to being new to iOS development. So I don't have any old habits. I am looking at this with fresh eyes so to speak.

 

[dantastic]

If you're learning then learn the latest & greatest.

I don't have any problems that storyboards can solve for me. Maybe in the future they will add handy features but for the time being....

I'm really hoping for Bindings like we have for the desktop.

 

[PriapusZA]

If you're learning then learn the latest & greatest.

I don't have any problems that storyboards can solve for me. Maybe in the future they will add handy features but for the time being....

I'm really hoping for Bindings like we have for the desktop.

Thanks I think I will start off with Storyboards rather then. Just need to get up to speed ASAP with it.

Thanks for the input.

 

[ArtOfWarfare]

Storyboards vs nibs is comparable to Obj-C vs C or C vs assembly

Yes, you could use the later, and the later can do more, but the former will probably do 95+% of what you want in significantly less time.

The only thing a nib can do that a storyboard can't (that I can think of) is it'll let you design a prototype cell that can be used in multiple places in your app. Storyboard prototype cells can only be used in a single view.

 

[dejo]

The only thing a nib can do that a storyboard can't (that I can think of) is it'll let you design a prototype cell that can be used in multiple places in your app. Storyboard prototype cells can only be used in a single view.

Storyboards still can't, AFAIK, share XIBs. I have an info view that I would like to use in my universal app both in the iPad storyboard as well as the iPhone storyboard. I can't.

 

[dantastic]

I do believe the argument that storyboards makes development so much faster is a bit cracked up to be honest.

The amount of stuff I have in my nibs isn't all that significant. And surely building up the view will have to be done when using a storyboard as well?

The only thing would be transition between views... possibly.

But most everything else I have to do in code anyway (read: I have libraries for already).

Storyboards may help when building pretty simple static apps but when you're dealing with dynamic content mostly then the nib is pretty insignificant.

 

[Duncan C]

Storyboards still can't, AFAIK, share XIBs. I have an info view that I would like to use in my universal app both in the iPad storyboard as well as the iPhone storyboard. I can't.

I am a recent convert to Storyboards.

What we're doing is as follows:

We're ignoring the iPad specific storyboard that Xcode sets up for us.

We have a single storyboard for both iPad and iPhone. So far ALL the scenes are shared between them. If we need to create a custom scene for iPad at any point, we'll create a separate scene and give it an identifier with the suffix _iPad. Then we'll write code to load that at runtime. (The app uses a scheme where it instantiates view controllers from a descriptor file, and uses unique IDs instead of segues.)

Storyboards are the wave of the future. Many of Apple's new tricks are built on storyboards, and don't work with XIBs, or are much harder to use with XIBs.

As a simple example, iOS 6 has embed segues, which make it PAINLESS to create parent/child view controller relationships. Without that, you have a fair amount of rather fussy code to write. Certain view controllers like table view controllers pretty much have to be child view controllers (since a table view controller's root view is a table view, it doesn't lend itself to managing other UI elements)

I put off learning storyboards for quite a while, and regret that I did.

Overall they are easier to use, enable new features, and are well worth it. I was productive with storyboards almost instantly.

 

[Menge]

I think it's a matter of taste and what you're used to doing.

I myself use neither. I build my views by code and I love it. So much more flexibility and better yet: views load faster when no NIB/XIB/Storyboards are involved – especially on a lower-end iPhone.

But Apple doesn't seem to be pushing storyboards much and pushing AutoLayout+NIBs. If you're starting now, I'd go for what Apple is pushing.

 

[dejo]

Storyboards are the wave of the future. Many of Apple's new tricks are built on storyboards, and don't work with XIBs, or are much harder to use with XIBs.

Oh, I'm not avoiding storyboards completely. There just are some circumstances where they don't work as nicely as I would like. Even the storyboards generated from a universal Master-Detail template leave much to be desired in terms of DRY.

 

[ArtOfWarfare]

DRY

<3 DRY

I'm working on giving him a best friend called DROP - Don't Repeat Other People. It's not really feasible to use DROP today (so many PITAs that make it so that it's often quicker to write the same code someone else has), but I'm hoping to make it feasible in the future.

Give me a few (2-5?) years - I'm brainstorming a new language and IDE (and then some) centered around making it work right now.

 

[Duncan C]

Oh, I'm not avoiding storyboards completely. There just are some circumstances where they don't work as nicely as I would like. Even the storyboards generated from a universal Master-Detail template leave much to be desired in terms of DRY.

We developed a scheme for a client that uses a descriptor file to describe the different view controllers and content, and links. The whole app is driven by these descriptor files.

Each record has a Storyboard ID (which implies the class of the view controller) plus data to fill it, and all the links that it leads to.

That actually works VERY well in terms of DRY.

 

[iMacFarlane]

The word from the Big Nerd Ranch:

Well, I'm not really just starting out but I have just gotten serious about iOS development. Went through the current edition of the iOS Programming Guide from BigNerdRanch to get back up to speed and then some.

Here's what they have to say about Storyboard use:

Pros
- Storyboards can be used to easily show off the flow of an application to a client or a colleague.
- Storyboards remove some simple code from your source files.
- Tables with static content are easy to create.
- Storyboards sure do look pretty.

Cons
- Storyboards are difficult to work with in a team.
- Storyboards screw up version control.
- Storyboards disrupt the flow of programming.
- Storyboards sacrifice flexibility and control for ease of use.
- Storyboards always create new view controller instances.

Overall, storyboards make easy code easier and difficult code more difficult.

I would have to say that at this point in my experience, with the projects I've worked on and the projects I have in mind, I agree with them.

To each his own, though. Happy coding!

 

[dantastic]

Cons
- Storyboards are difficult to work with in a team.
- Storyboards screw up version control.

Can you expand a bit on this please. We've several people working on an app at the same time and you are likely to have people working on UI at the same time. Different screens but still, same file as such. We use SVN as well...

 

[PriapusZA]

Can you expand a bit on this please. We've several people working on an app at the same time and you are likely to have people working on UI at the same time. Different screens but still, same file as such. We use SVN as well...

Yes, would also like an explanation on that too.

 

[Duncan C]

Can you expand a bit on this please. We've several people working on an app at the same time and you are likely to have people working on UI at the same time. Different screens but still, same file as such. We use SVN as well...

I don't have concrete details for you. I installed some of our company's apps on devices under iOS 7 and Xcode 5, and found that there were lots of layout problems.

From memory:

The status bar overlapped with navigation bars. "Buttons" (clickable text in iOS 7) did not get drawn in the right place. Rotation didn't work correctly.

 

[ArtOfWarfare]

I don't have concrete details for you. I installed some of our company's apps on devices under iOS 7 and Xcode 5, and found that there were lots of layout problems.

From memory:

The status bar overlapped with navigation bars. "Buttons" (clickable text in iOS 7) did not get drawn in the right place. Rotation didn't work correctly.

It sounds to me like your issues revolve around using unreleased beta software, not with inherent flaws in storyboards.

 

[PhoneyDeveloper]

I think that storyboards can't be merged in source control so if two different developers are working on different view controllers but both are in the same storyboard then the second one to check in his changes will have merge conflicts. Nibs also can't be merged but each one represents a much smaller amount of the app's UI than a storyboard.

I think it's possible to have multiple storyboards for a single app so that each developer is less likely to have merge conflicts with others.

The project file has similar issues.

I also found that changing the existing flow in a storyboard wasn't so simple. Adjusting a single view controller's view is the same as editing a nib. Some aspects of table views seem simpler.

 

[xStep]

I don't have concrete details for you. I installed some of our company's apps on devices under iOS 7 and Xcode 5, and found that there were lots of layout problems.

From memory:

The status bar overlapped with navigation bars. "Buttons" (clickable text in iOS 7) did not get drawn in the right place. Rotation didn't work correctly.

Things have changed. Check out the WWDC 201 session, Building User Interfaces for iOS 7. For your first problem, start play at 12:30.

EDIT: The video refers to UIExtendedEdgesAll and UIExtendedEdgesNone. Those are wrong. Jump to the new definition for UIViewController to reveal the current names.

 

[iMacFarlane]

Well. And here you go.

I commented on this thread and then ran into a concrete example of Interface Builder weirdness, probably due to AutoLayout or some such thing.

I take 4 image files (a clock face and three hands), and order them as the first image (all hands centered, pointing up). Then I set up a timer and apply a rotation transformation on each hand as appropriate for each second. To put the hands in the proper rotation, I adjust the anchorpoint to each CALayer, centered X, 90% Y. In Interface Builder, I get the unexpected (and unexplainable) mess in frame 2 (hands way too far from center).

Without changing any code whatsoever, I switched from IBOutlets to Property based UIImageViews for each hand. Runs as expected (Proper clock face).

In IB, I turned off AutoLayout, messed with struts/springs, to no avail. Only by shifting to code was I able to get the expected results.

Anyone have any ideas? If I am missing something simple or stupid, I would love to know what it is!

 

[PriapusZA]

I've got another question:

What if the app you're building has a lot of view controllers - say, 30 or so. Storyboards still the way to go?

How would you fit 30 screens on there or would you simple reuse some screens, some how?

 

[pmau]

I too use data-driven ViewControllers.

I use IB mostly to layout UIView hierarchies which I then load from ViewControllers.

Most times, I don't use auto-layout, but tweak a little in viewDidLoad.

In my opinion, the whole StoryBoard and Autolayout stuff is for prototypes or simple catalog drill-down apps.

If you want to have a unique user interaction, IB does not get you very far.

Also, I try to rely heavily on QuartzCore to apply alpha masks or image effects.
I try really hard to not include lots of artwork assets in the App bundle.

It's better for App size, can be updated server-side or can be generated and cached on the fly.

You can get really far with just a few ViewControllers that are controlled by a model, use QuartzCore for the core design of your app and use lots of CALayer based stuff to make your app look more vibrant and less static.

 

[PriapusZA]

I too use data-driven ViewControllers.

I use IB mostly to layout UIView hierarchies which I then load from ViewControllers.

Most times, I don't use auto-layout, but tweak a little in viewDidLoad.

In my opinion, the whole StoryBoard and Autolayout stuff is for prototypes or simple catalog drill-down apps.

If you want to have a unique user interaction, IB does not get you very far.

Also, I try to rely heavily on QuartzCore to apply alpha masks or image effects.
I try really hard to not include lots of artwork assets in the App bundle.

It's better for App size, can be updated server-side or can be generated and cached on the fly.

You can get really far with just a few ViewControllers that are controlled by a model, use QuartzCore for the core design of your app and use lots of CALayer based stuff to make your app look more vibrant and less static.

Well my app will be mostly table view drill down of categories. Only ending at a detailed view controller for the item. Can't really get away from table views for that. UICollectionView will be used for iPad app - but its the same as table views under the hood.

I want the category list view controllers to be reusable. I think that would be the way to go. But the app will have about 10 other screens which may or may not be reusable. So just wondering how good storyboards are for that.

As for custom UI - the app design doesnt allow much in the way of custom controls etc because of the type of app it is.

Thanks for the input

 

[ArtOfWarfare]

Storyboards are definitely the way to go. Would you rather have 30 NIBs with no way of easily seeing how all of them relate to each other, or 30 scenes in one storyboard where it's easy to see the flow of your app?