5 ms·

I'm coming around to the point of view that storyboards cause more problems than they solve but throwing out xibs entirely seems a little extreme. Are they real

I'm coming around to the point of view that storyboards cause more problems than they solve but throwing out xibs entirely seems a little extreme. Are they really doing all their layout in code?

codewright 14y ago
A relatively new to iOS engineer at my company does all his layout in code. Way more flexible.
prawks 14y ago
I essentially did this for my senior capstone at university, and it worked pretty well for my purposes. Granted, I was working mainly in data visualizations. I'd propose that doing so is actually not too bad of a thing if you're a) not rapidly prototyping, and b) need to manipulate the large majority of the UI in code anyways. I haven't made many more iOS apps after that, so I can't really say that with lots of experience, but still. As long as you're mindful of how you structure your code, it's not extremely difficult to maintain.
_stephan 14y ago
Using code for layout has several advantages: - easier version control and code merging - you don't need Interface Builder to review the layout code - code is easier to search, e.g. for the use of certain controls (Xcode doesn't support searching XIB files) - code can be parameterized (you can e.g. use global constants for font sizes, colors and margins) - layouts that follows certain rules (fixed heights and margins etc) are sometimes easier to build with code, especially when the number of visible controls is variable or some controls are only optionally displayed - you can easily refactor aspects of the layout into reusable components (i.e. functions or classes)
- cageface 14y ago
  I'm a big fan of declarative layouts and vastly prefer doing Android UIs to iOS UIs for this reason. But that's only because Android has a sane & powerful layout language. Obj-C is so hideously inflexible and verbose for this kind of thing that I prefer to stick to xibs despite their limitations. Of course there will always be cases in iOS apps where layout in code makes more sense though.
  - bjustin 14y ago
    AutoLayout (new in iOS 6 and OS X 10.7) is decidedly OK to use in code or in IB.
- bennyg 14y ago
  I'm of the "do both" camp. Personally, I like starting out the interface in .xib because of the wysiwyg style - I've been an Illustrator and Photoshop design guy for much longer than I've worn my iOS Dev Hat. By laying out areas of apps in subviews of the main view, then manipulating those in code, I get very easy content sizing (3.5" vs 4" screen) without using the springs/struts and the terrible iOS6 autosizing constraints, and animations couldn't be easier. Just looking through my open projects right now, all of my ViewControllers have a buildUI method right under ViewDidLoad.
  - cageface 14y ago
    Glad to hear I'm not the only one that thinks that the new iOS 6 auto layout stuff is a train wreck. The WWDC sessions on the subject are like Onion parodies of normal tech talks.
- mikec3k 14y ago
  I'm starting to prefer using code for layout, since it does make some things easier. When I inherit a large project, it's nice to be able to search & easily change stuff in code rather than having to tweak lots of xibs.
objclxt 14y ago
XIBs and programatic layout is the Vim vs Emacs of the iOS world. There are a lot of pros and cons of both. I used to spend a not insignificant amount of time trying to moderate debates between iOS engineers who favoured one approach versus the other. Doing all your layout in code isn't inherently bad, and there are lot of Apple written apps that do this (conversely, some of the newer iOS built-in apps do use NIBs). The main problem that I've found with layout entirely in code is that whilst it's fine for you, the sole developer, once you bring in more people onto the project you can have problems with getting people up to speed on what exactly is going on where. Of course, the solution to this is to enforce strict coding standards over how to layout the views themselves in code, which Google clearly do. And as the article points out, resolving merge conflicts in code is somewhat more enjoyable than in nibs. That said, just as programatic layout isn't inherently bad, neither is leveraging interface builder strategically. Here's a good example: iPhoto on iPad has a completely custom interface that's mainly laid out programatically, but certain key elements are actually composited together in IB. For example, the brushes that slide up when touching up photos are being brought in from NIBs, but animated and manipulated in code. Using the nib file to load in the images reduces the code without sacrificing understanding (or at least, that's Apple's argument. There's a fantastic WWDC 2012 session that covers how the iPhoto UI is put together in more detail). The TLDR; - the only risk of programatic layout that I see if developers going 'off piste' and laying out in a non standard way. With the right coding standards you should be fine.
- cageface 14y ago
  XIBs and programatic layout is the Vim vs Emacs of the iOS world. To me that implies that one essentially makes the other redundant but I prefer to see them as two powerful tools in my box that each have their uses. I've always thought the people that insist on doing everything in xibs were a little weird but going too far the other way doesn't make sense to me either.
  - objclxt 14y ago
    You're right, it's a pretty bad analogy! I was more going for the whole NIB/Code debate being something that's never going to be adequately resolved.
reidmain 14y ago
There was a nice article on Reddit recently about why someone doesn't use nibs but the discussion in the comments may shed some light on your question. http://www.reddit.com/r/programming/comments/15jjfi/why_i_dont_use_interface_builder/ http://www.reddit.com/r/programming/comments/15jjfi/why_i_do...

I'm coming around to the point of view that storyboards cause more problems than they solve but throwing out xibs entirely seems a little extreme. Are they really doing all their layout in code?

codewright 14y ago

A relatively new to iOS engineer at my company does all his layout in code. Way more flexible.

prawks 14y ago

I essentially did this for my senior capstone at university, and it worked pretty well for my purposes. Granted, I was working mainly in data visualizations. I'd propose that doing so is actually not too bad of a thing if you're a) not rapidly prototyping, and b) need to manipulate the large majority of the UI in code anyways. I haven't made many more iOS apps after that, so I can't really say that with lots of experience, but still. As long as you're mindful of how you structure your code, it's not extremely difficult to maintain.

_stephan 14y ago

Using code for layout has several advantages: - easier version control and code merging - you don't need Interface Builder to review the layout code - code is easier to search, e.g. for the use of certain controls (Xcode doesn't support searching XIB files) - code can be parameterized (you can e.g. use global constants for font sizes, colors and margins) - layouts that follows certain rules (fixed heights and margins etc) are sometimes easier to build with code, especially when the number of visible controls is variable or some controls are only optionally displayed - you can easily refactor aspects of the layout into reusable components (i.e. functions or classes)

cageface 14y ago
I'm a big fan of declarative layouts and vastly prefer doing Android UIs to iOS UIs for this reason. But that's only because Android has a sane & powerful layout language. Obj-C is so hideously inflexible and verbose for this kind of thing that I prefer to stick to xibs despite their limitations. Of course there will always be cases in iOS apps where layout in code makes more sense though.
- bjustin 14y ago
  AutoLayout (new in iOS 6 and OS X 10.7) is decidedly OK to use in code or in IB.
bennyg 14y ago
I'm of the "do both" camp. Personally, I like starting out the interface in .xib because of the wysiwyg style - I've been an Illustrator and Photoshop design guy for much longer than I've worn my iOS Dev Hat. By laying out areas of apps in subviews of the main view, then manipulating those in code, I get very easy content sizing (3.5" vs 4" screen) without using the springs/struts and the terrible iOS6 autosizing constraints, and animations couldn't be easier. Just looking through my open projects right now, all of my ViewControllers have a buildUI method right under ViewDidLoad.
- cageface 14y ago
  Glad to hear I'm not the only one that thinks that the new iOS 6 auto layout stuff is a train wreck. The WWDC sessions on the subject are like Onion parodies of normal tech talks.
mikec3k 14y ago
I'm starting to prefer using code for layout, since it does make some things easier. When I inherit a large project, it's nice to be able to search & easily change stuff in code rather than having to tweak lots of xibs.

objclxt 14y ago

XIBs and programatic layout is the Vim vs Emacs of the iOS world. There are a lot of pros and cons of both. I used to spend a not insignificant amount of time trying to moderate debates between iOS engineers who favoured one approach versus the other. Doing all your layout in code isn't inherently bad, and there are lot of Apple written apps that do this (conversely, some of the newer iOS built-in apps do use NIBs). The main problem that I've found with layout entirely in code is that whilst it's fine for you, the sole developer, once you bring in more people onto the project you can have problems with getting people up to speed on what exactly is going on where. Of course, the solution to this is to enforce strict coding standards over how to layout the views themselves in code, which Google clearly do. And as the article points out, resolving merge conflicts in code is somewhat more enjoyable than in nibs. That said, just as programatic layout isn't inherently bad, neither is leveraging interface builder strategically. Here's a good example: iPhoto on iPad has a completely custom interface that's mainly laid out programatically, but certain key elements are actually composited together in IB. For example, the brushes that slide up when touching up photos are being brought in from NIBs, but animated and manipulated in code. Using the nib file to load in the images reduces the code without sacrificing understanding (or at least, that's Apple's argument. There's a fantastic WWDC 2012 session that covers how the iPhoto UI is put together in more detail). The TLDR; - the only risk of programatic layout that I see if developers going 'off piste' and laying out in a non standard way. With the right coding standards you should be fine.

cageface 14y ago
XIBs and programatic layout is the Vim vs Emacs of the iOS world. To me that implies that one essentially makes the other redundant but I prefer to see them as two powerful tools in my box that each have their uses. I've always thought the people that insist on doing everything in xibs were a little weird but going too far the other way doesn't make sense to me either.
- objclxt 14y ago
  You're right, it's a pretty bad analogy! I was more going for the whole NIB/Code debate being something that's never going to be adequately resolved.

reidmain 14y ago

There was a nice article on Reddit recently about why someone doesn't use nibs but the discussion in the comments may shed some light on your question. http://www.reddit.com/r/programming/comments/15jjfi/why_i_dont_use_interface_builder/ http://www.reddit.com/r/programming/comments/15jjfi/why_i_do...