iOS Is it worth looking into storyboards?

You don't use XIB's but you want to use storyboards? basically they are just a newer version imho, there's some more flexibility, but still, don't see the logic behind that ^_-

It's a billion times faster at fleshing out pixel perfect UIs. In code, to get things perfect you have to build repeatedly to check how things look. With IB, you know in real time whether things are lining up the way you want.

I started working at a company where we're building an app for iOS and Android. The Android version was mostly done, the iOS version hadn't even been started. They wanted a mockup. I told them to give me twenty minutes. The boss's mouth dropped when I actually did it in 20 minutes. My (Android) coworkers mouths dropped when they saw how easy it was. (I've been working on polishing the Android app up... Let me tell you, not all design tools are created equal. Don't bother with Android's, just edit the XML directly. The graphical editor will fight you at every step and move things in automatic and retarded ways nonstop. I don't understand why they didn't just copy Apple for it.)

Edit: The Android graphical editor isn't totally useless. You can quickly view what the XML layout will look like on a variety of devices. Because you'd never actually want to start the simulator (I kid you not, it takes 15 minutes to start the Android emulator.)

pulsewidth947 said:

Lol ok perhaps I phrased it wrong. I'm really looking for some pros and cons. I suppose I'd be correct in thinking;
pro) quicker fleshing out simple views,
con) would still have to flesh out some of the dynamic frame work in code, plus a lot of IBOutlets..

It's not that I want to use storyboards, just wondering if i'm missing something. Early on in my app dev life I worked with someone who talked me out of using IB.. Just wondered what, if anything, I was missing out on.

Click to expand...

Talked you out of IB.. hmm, mostly it's people who didn't really work with IB, or had something strange (that was their own fault), who talk you out of XIBs.
For easy stuff it's just trillion times faster using IB. drag image on, put the name of image in, even with autocomplete (hate that codewise Xcode doesn't has this).
Dragging buttons on there, connecting with IB.. just so easy, I can promise you, the story that Art told, I can understand that 100%, i've had it so many times, for basic mockups, it takes like 10 mins max. Just self.navigationController pushcontroller, new view you created in IB. then hook up an IBAction with same code to a new controller you created in IB, and so on. it's just so easy.
I admit I use it in all projects, because taking over a project that doesn't have it takes so much longer, because you have to perfect all the pixels by hand, rerun it, tweak it, run it again.. in IB it's like, tap arrow on keyboard 2ce, and you can see it live changing 2 pixels.

@Art, yeah, the Android is a hell.. it's faster to run it on your device then in the emulator

But again, about the storyboards, I have no idea, i started once, but gave up quickly because I don't have alot of time, and just went back to XIB's, they do everything I need and I can use them to their full extend. So no need for me to move

If you don't like Interface Builder, you're not going to like storyboards, since they take it to the next level. One advantage of using storyboards is that they bring a bunch of screens and the transitions between them into one place, the storyboard. A disadvantage, I found in my own tests, is that, for a universal app, they make it hard to share screens between storyboards.

pulsewidth947 said:

L
It's not that I want to use storyboards, just wondering if i'm missing something. Early on in my app dev life I worked with someone who talked me out of using IB.. Just wondered what, if anything, I was missing out on.

Click to expand...

Definitely learn to use XIBs! I was like you once, and found XIBs painful to deal with back in the early days when we were using XCode 3 and had to fire up Interface Builder (a separate app, back then) to tweak them.

But those days are gone. The workflow/integration between XIBs and code is much easier now. XIBs save you development time and help you write cleaner, more maintainable code by reducing the monotonous boilerplate and letting you focus on the customizations.

Storyboards are the next step of XIBs - allowing you to define the navigation paths between your views, not just the content of each view. I haven't used them a great deal, but if I were starting a new navigation based app tomorrow I would definitely strongly consider them.

pulsewidth947 said:

Some great replies here thanks everyone. What piqued my interest was being able to see the flow of an app quickly using storyboards.

I know IB is just a tool, that if I spent the time to learn it I would get something out of it.

Reducing the tedious boiler plate code would be nice. I've started using an AppTheme class in order to just call a method to quickly set up all my buttons, use the Appearance proxy etc.

I'm always interested in learning a new tool!

Click to expand...

Curious, you don't really need to learn "how to use it", if you know your elements that you would use in your application, like UIView, UIImageView, UIButton, UISegmentedControl, and on and on, then there's not much to learn. When you know where to find the elements, and how to connect them (personally, control + hold drag/click thingy works fastest for me), it's just a blast, you can build screens in matter of minutes. I build alot of animations with things I have on the IB on the right spot to visualise it, then I can just copy paste their frames in code, or just alpha them out to 0, and in code do some fancy things with it.

If you wonna learn how to use it, i'll be glad to help since you've not answered like "omaigod, you use xibs, that's for noobs", which I get alot in other places.

Well, i'd say, go for it, and we'll hear about it when you're stuck ^_-

I was talking about XIB's not segues, I have no idea how to use those x)
For that last quote you did with the frames.
Well yeah, but since you can still make outlets, you can redefine them if you want to do custom frame shizzle while animating, that's the easy thing. Just have it in your xib, and change it on the fly in code, since it's linked against the XIB

I find it funny when programming for iOS.
When I'm programming for OS X, I pretty much religiously use interface builder.

However, when I now program for iOS, I almost find myself never using xibs.
I think the biggest reason for me not trying to use xibs/storyboards was that I couldn't see how I could make a universal app out of them.

For example, I wanted to add in a row of 3 buttons into a uitableview footer.
My approach was to make a UIView, place 3 buttons horizontally and call it done.
I first tried this in interface builder, didn't specifically target for the iPad since I thought it should work fine on the iPad.

However loading up this view in the iPad would make the buttons not line up correctly with the uitableview cells in group style.

I ended up hard coding this view, and just took care of the spacing just by checking the userInterfaceIdiom. The code is very short, but at least I have a view that works on both ipad and iphone.

Now there could be way to make a xib work perfectly on the ipad/iphone. I just haven't found the way yet. I do agree with ArtOfWarfare that it requires a lot of bulding/running to figure out if it will look properly (although this can be mitigated to some extent by reading the user interface guildines). However what I like is that I have less files to deal with, and If I make a change, to me it seems like it's easier in code.

However it's quite subjective, and each use case is very different.

For posters above -> blueillusion, someone in my company created some class clustering, i mixed that with DeviceHW to load seperate iPad/iPhone code with seperate iPhone/iPad xib's. But you keep all the code in just 1 class (subclass yourself with _iphone and _ipad in your own class interface).
This is just perfect, I do understand your way of coding, and sometimes I do it too, but it's just a hell to take over someone elses project if they have done it this way, and therefor i prefer to do XIB's, because we have alot of interns doing small fixes on projects we worked on.