5 ms·

Utilizing storyboards and xibs is one of the best way to decrease development time. Stop the coding madness!!!! The only people I still know that avoid heavy u

Utilizing storyboards and xibs is one of the best way to decrease development time. Stop the coding madness!!!! The only people I still know that avoid heavy utilization of these do not understand how to properly use them. Go learn!

jkubicek 14y ago
Totally agree. It's well worth working closely with your designer to make your interface work with nibs, not against them. Little things like putting button icons on the left side of the button and putting a 20px gutter between elements add up fast.
- protomyth 14y ago
  That's actually a good way to see if your designer knows how to create a design within the conventions of the platform. Violating too many of a NIBs conventions tends to mean either a game (not really going to use NIBs) or something that will be hard on the users.
jsankey 14y ago
I started out using XIBs, but also found myself moving a lot of my controllers away from them as soon as things got non-trivial. The biggest problem I found was weak layout support, so if you had a lot of dynamic content in a screen, it was easier to make a flexible layout in code. I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain. Maybe I was missing something, but my experience matches the OP.
- robterrell 14y ago
  Perhaps you're missing something. XIBs are arguably among the most powerful features of Cocoa. I built an app with a really complex, dynamic layout using them (look up "Panna" in the App Store). Working with an evolving design and changing team, with layout elements often changing and getting tweaked in tiny ways... Well, if I did the entire layout in code, I would have needed a full-time developer just for the ongoing GUI changes. I agree that dynamic layout support was weak pre-constraints, but it was still a much better development experience, and now you can do really complicated things without any code at all. If you're just talking about some buttons in a toolbar, go nuts, but otherwise it's worth the time investment to learn.
  - andrewroycarter 14y ago
    100% agree. IB makes for faster development time, easier maintenance, and it's way better for auto layout if you're targeting iOS 6.0
    - ravenger00 14y ago
      I think there's a case to be made though, that using IB when starting out doesn't make you fully understand how UIViews work. So starting out I'd probably recommend you make your own views programmatically to know what you're hooking into. That said once you get that base level of understanding, nibs and storyboards are huge time savers, and are the way to go.
      - MaxGabriel 14y ago
        While using storyboards definitely meant that I didn't understand things like how my root view controller got set up, I don't think it abstracts too much. Most importantly, using Interface Builder allowed me to explore the properties of views and get immediate feedback on how they're made. I still go back to a Storyboard when I need to figure out what combination of UIControl content settings I need.
  - jsankey 14y ago
    My experience is all pre-autolayout, which is very new. It sounds like I definitely need to take another look for future work.
- reidmain 14y ago
  I'm 100% with you. I used nibs a lot when I started out but now I've slowly drifted away from them. The only thing I use them for is setting the frame so I can get a general idea of the layout of the view. Sometimes I'll set a few properties like text color and font size but I'll then move those lines into viewDidLoad: so I know exactly what my view will be like when it is loaded. I've dealt with far too many bugs involving Interface Builder and it's random changes and "upgrading" the second I touch a nib that it's more of a liability now. People who say it's less "code" are just delusional. Setting the font in IB versus a single line in viewDidLoad: doesn't save you anything. At some point in time that line of code is getting executed and you will at some point have to maintain it.
cageface 14y ago
Agreed. If iOS actually had a sane declarative language like Android's xml layouts then I'd do everything in code but since layouts coded in Obj-C are excruciatingly painful to read and edit you're better off with a WYSIWYG tool, even if (IMO) WYSIWYG is fundamentally the wrong approach for UI development. I actually consider this a big liability for Apple going forward. The explosion of "phablets" and other form factors spells the end of their pixel-perfect design approach and their tools and APIs for managing dynamic, variable layouts are stone age compared to Android's.
- Zev 14y ago
  Cocoa Auto Layouts are what you're looking for: https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html https://developer.apple.com/library/mac/#documentation/UserE...
  - cageface 14y ago
    They're better than nothing but compared to the html-esque layouts in Android they're much harder to write, read and debug.
    - weiran 14y ago
      I would beg to differ. I much prefer to work with AutoLayout constraints rather than some custom XML layout like with Android or WP.
      - cageface 14y ago
        YMMV but when the presenter of the WWDC AutoLayout track had to dig into Instruments to find out why his layout was throwing exceptions I felt like I was watching some kind of really nerdy April fools joke.
pjmlp 14y ago
As someone with experience in several RAD tools, I never understood the design UI in code mentality. Sure, you can control all your code, but there is so much time that is lost until the UI is finally ready, and than the marketing department wants it redone in one day.
melling 14y ago
How do I set up view containment in iOS5 with Storyboards so I can have multiple segues in a dashboard view? This is something that I was just looking into last night.

jkubicek 14y ago

Totally agree. It's well worth working closely with your designer to make your interface work with nibs, not against them. Little things like putting button icons on the left side of the button and putting a 20px gutter between elements add up fast.

protomyth 14y ago
That's actually a good way to see if your designer knows how to create a design within the conventions of the platform. Violating too many of a NIBs conventions tends to mean either a game (not really going to use NIBs) or something that will be hard on the users.

jsankey 14y ago

I started out using XIBs, but also found myself moving a lot of my controllers away from them as soon as things got non-trivial. The biggest problem I found was weak layout support, so if you had a lot of dynamic content in a screen, it was easier to make a flexible layout in code. I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain. Maybe I was missing something, but my experience matches the OP.

robterrell 14y ago
Perhaps you're missing something. XIBs are arguably among the most powerful features of Cocoa. I built an app with a really complex, dynamic layout using them (look up "Panna" in the App Store). Working with an evolving design and changing team, with layout elements often changing and getting tweaked in tiny ways... Well, if I did the entire layout in code, I would have needed a full-time developer just for the ongoing GUI changes. I agree that dynamic layout support was weak pre-constraints, but it was still a much better development experience, and now you can do really complicated things without any code at all. If you're just talking about some buttons in a toolbar, go nuts, but otherwise it's worth the time investment to learn.
- andrewroycarter 14y ago
  100% agree. IB makes for faster development time, easier maintenance, and it's way better for auto layout if you're targeting iOS 6.0
  - ravenger00 14y ago
    I think there's a case to be made though, that using IB when starting out doesn't make you fully understand how UIViews work. So starting out I'd probably recommend you make your own views programmatically to know what you're hooking into. That said once you get that base level of understanding, nibs and storyboards are huge time savers, and are the way to go.
    - MaxGabriel 14y ago
      While using storyboards definitely meant that I didn't understand things like how my root view controller got set up, I don't think it abstracts too much. Most importantly, using Interface Builder allowed me to explore the properties of views and get immediate feedback on how they're made. I still go back to a Storyboard when I need to figure out what combination of UIControl content settings I need.
- jsankey 14y ago
  My experience is all pre-autolayout, which is very new. It sounds like I definitely need to take another look for future work.
reidmain 14y ago
I'm 100% with you. I used nibs a lot when I started out but now I've slowly drifted away from them. The only thing I use them for is setting the frame so I can get a general idea of the layout of the view. Sometimes I'll set a few properties like text color and font size but I'll then move those lines into viewDidLoad: so I know exactly what my view will be like when it is loaded. I've dealt with far too many bugs involving Interface Builder and it's random changes and "upgrading" the second I touch a nib that it's more of a liability now. People who say it's less "code" are just delusional. Setting the font in IB versus a single line in viewDidLoad: doesn't save you anything. At some point in time that line of code is getting executed and you will at some point have to maintain it.

cageface 14y ago

Agreed. If iOS actually had a sane declarative language like Android's xml layouts then I'd do everything in code but since layouts coded in Obj-C are excruciatingly painful to read and edit you're better off with a WYSIWYG tool, even if (IMO) WYSIWYG is fundamentally the wrong approach for UI development. I actually consider this a big liability for Apple going forward. The explosion of "phablets" and other form factors spells the end of their pixel-perfect design approach and their tools and APIs for managing dynamic, variable layouts are stone age compared to Android's.

Zev 14y ago
Cocoa Auto Layouts are what you're looking for: https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html https://developer.apple.com/library/mac/#documentation/UserE...
- cageface 14y ago
  They're better than nothing but compared to the html-esque layouts in Android they're much harder to write, read and debug.
  - weiran 14y ago
    I would beg to differ. I much prefer to work with AutoLayout constraints rather than some custom XML layout like with Android or WP.
    - cageface 14y ago
      YMMV but when the presenter of the WWDC AutoLayout track had to dig into Instruments to find out why his layout was throwing exceptions I felt like I was watching some kind of really nerdy April fools joke.

pjmlp 14y ago

As someone with experience in several RAD tools, I never understood the design UI in code mentality. Sure, you can control all your code, but there is so much time that is lost until the UI is finally ready, and than the marketing department wants it redone in one day.

melling 14y ago

How do I set up view containment in iOS5 with Storyboards so I can have multiple segues in a dashboard view? This is something that I was just looking into last night.