14 ms·

So, a word of advice to new folks trying out iOS land: Interface Builder is most emphatically your friend. The compile/debug cycle in iOS is sufficiently lengt

So, a word of advice to new folks trying out iOS land: Interface Builder is most emphatically your friend. The compile/debug cycle in iOS is sufficiently lengthy that laying out views programmatically gets very tedious very fast. Besides realtime previewing of exactly how your view is going to look, IB also helps you understand how your layout is affected by rotations to landscape and differences in view height between device classes (3GS/4/4S vs 5). Nibs make it easy to tweak and adjust – and even to throw away and start fresh. Most importantly, though – every nib you use is code you do not have to maintain. If a UI object has some part of its API deprecated, your nibs don't care. They're automatically up-to-date. Can you do every fancy thing you'd like with nibs? Certainly not. But you can do the basic braindead layouts of labels and buttons there, and you're much likelier to get what you want the first time. There's enough tedious code to wrangle in iOS as it is – don't create more for yourself by rejecting a mature, useful tool. edit: For clarity, though, by all means, enjoy this solid tutorial so you understand how to get your hands dirty when necessary. Just don't fear the IB.

objclxt 13y ago
I agree with pretty much everything you say (especially now Apple will be pushing auto-layout for newcomers to the platform), but the one thing that's really bothered me with the "Your First iOS App" tutorial is that as some point it switched from NIBs over to a full Storyboard. And Storyboards are certainly in principle a cool idea, but I've never seen a production app that has actually used them (please do correct me if you're reading this and use them in your own shipping app). As far as I know, Apple aren't dog-fooding them in their own apps either. I'm not sure of the benefits of introducing them as pretty much the first thing out of the gate. But I'm prepared to be wrong!
- danilocampos 13y ago
  Yeah, Storyboards are still in their awkward phase. That's totally fair. And I don't yet trust them for running view navigation. But you know what they're awesome for? Static table views. If you want to build a grouped table view as login view, settings panel or the like, Storyboards are perfect. I'm also a big fan of Storyboards for prototyping. You can get to a pretty good fidelity demo of your app's information architecture, and often you can re-use what you built when it's time to code the app for real. (Though I often cut the Storyboard content out and paste it into a nib.)
  - brodney 13y ago
    Half the stuff on my storyboards aren't even connected. I treat it like a big nib file. It's excellent for having everything displayed in front of you, in one place, and you can add segues and other storyboard magic as needed.
- Scorponok 13y ago
  Our app has ~15 view controllers laid out in a single storyboard, and we haven't had any issues with them. We only have one iOS developer, so I don't know if that makes a difference. We don't really use segues, though, since they seem to add complexity if you want to pass data around between the view controllers.
  - tvon 13y ago
    In case you are not aware, there is UIViewController's `prepareForSegue:sender:` method (http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html http://developer.apple.com/library/ios/#documentation/UIKit/...). In short you figure out which segue was being prepared (segue.identifier) and setup the destination view controller (segue.destinationViewController) as needed.
  - ant512 13y ago
    I've got a production app I switched from nibs to storyboards. It's got a storyboard for the iPhone and a separate storyboard for the iPad. 58 views on each. I'm using segues for pretty much all navigation. It's working amazingly well for me.
- M4v3R 13y ago
  I'm writing a fairly complex iOS app, and I opted in for storyboards in it. It doesn't handle 100% of navigation, because I only was invited to work on the app at some point and I didn't feel to rewrite the whole thing, but I use it for a substantial part of UI. It gets a while to get used to, but then you have this very cool overview of this whole part of the app. Some static parts are done 100% in IB (like a menu with grouped-style UITableView, utilizing static cells), others only use placeholders which are filled in code. But it works, and it works pretty well.
- nanijoe 13y ago
  How would you know if a production app was using Storyboards? I just submitted my first "Storyboard App" . It was a little uncomfortable for me seeing as I have gotten used to using NIBs, but I did it because I assumed Apple was moving away from NIBs.. I wonder how other people who use Storyboards do it..I pretty much had to sit at a desk with my MBP connected to external monitors anytime I wanted to do any work, just because the Storyboard required a lot of screen space.
  - objclxt 13y ago
    > How would you know if a production app was using Storyboards? Because just like NIBs, Storyboards exist as part of an app's resource bundle, which is easily viewable. It is usually fairly straightforward to examine an IPA from the store and determine whether it's using NIBs and the like.
    - BHSPitMonkey 13y ago
      I think the most likely explanation is that the grandparent commenter was referring to their own experience with projects they've worked on.
- Aqua_Geek 13y ago
  > And Storyboards are certainly in principle a cool idea, but I've never seen a production app that has actually used them Fly Delta app uses them all over the place (first-hand experience) - they're fantastic for static cell table views. Admittedly, merging them can be a HUGE pain, though. > As far as I know, Apple aren't dog-fooding them in their own apps either. From what I've heard from an Apple engineer, Apple doesn't dog-food a lot of this stuff because the tools either don't exist yet by the time they need to ship or aren't stable. A lot (most?) of their apps end up being done programatically.
meeech 13y ago
"There's enough tedious code to wrangle in iOS as it is – don't create more for yourself by rejecting a mature, useful tool." That's probably true. But some of us learn better by doing the tedious bits (basically less magic) to see how everything works together, and then look for the path to remove the tedious bits (which would lead to using IB) once we have a better grasp of things. So this tutorial is quite welcome.
- danilocampos 13y ago
  Oh yeah – you should totally understand how the magic works. But there's an odd strain of fear against IB, so it bears mentioning.
allsystemsgo 13y ago
I jumped into iOS dev after storyboards so, I fear nibs... I've never used one. If I started with a storyboard, should I throw in nibs every now and then for certain tasks??
- danilocampos 13y ago
  Here's the haphazard way I'm using this stuff these days: 1. Non-view controller views. These typically go in nibs. Custom tableview cells, tableview headers used across multiple views, custom buttons, nibs are all fine for this. (And the UITableView API accepts nibs for setting up reusable cells.) You can certainly do custom tableview cells in Storyboards, but it's weird because I don't know how you can re-use those cells across multiple tableviews. 2. View Controllers. These I'm often using Storyboards to build. Since they're great for static tableviews, Storyboards end up having a decent chunk of stuff built in them lately. It can be nice to look at two views side by side. I seem to be grouping related view controllers together in single storyboards. Nibs have performance penalties if they're packed down with too many objects, as every single one has to be loaded into memory. My understanding with Storyboards is that they don't have this drawback, so that's helpful.
- bennyg 13y ago
  I like to think of Nibs like classes. A lot of times I'll have a certain design I want reused throughout the app, and this works perfectly. For instance, in an app I'm working on now, I have a few different views that have scroll-views inside of them, with each object of the scroll-view being a view itself. In the last of the chain of views, I use a nib because there's a solid amount of data there, and visually designing it in IB is easier to iterate and make it look exactly like I want it to. I have a .m/.h attached to the view (just a subclassed UIView) with a custom init method, returning what is basically a custom object (that happens to be that .xib). It's super efficient to make changes and keep things looking good when the data or the feature-set needs to change.
  - BHSPitMonkey 13y ago
    Keep in mind, this scenario is just as good a candidate (maybe even better) for doing the layout in code rather than a nib.
jallmann 13y ago
Writing code in iOS is tedious, but IB is also dog slow and XCode becomes pretty unresponsive every time I switch to/from it. Not to mention the mess xibs make in source control. There is no reason for xibs to be human readable -- a binary format would limit diff hemorrhaging, and performance would certainly be helped by not having to process unholy amounts of XML. Either way, good luck merging xibs with multiple collaborators.
SeoxyS 13y ago
I've been a Cocoa developer for close to a decade now, and I've gone back and forth on this many times, but by now I've settled 100% in the nibs-are-evil camps. There are several reasons for that: - Nibs are a nightmare when working with version control and merge tools. Now, at least, they are XML instead of a proprietary binary format, but it's still a joke… - Auto-layout in IB is provably the worst GUI I have ever used. It's completely impossible to make it do what you actually indent. I was one of the guys cheering and wooing in the audience when it was announced at WWDC 2011, but it's proven to be a huge flop. - I have a similar experience with storyboards. - Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app. - Ultimately laying out your views in code doing some simple arithmetic is easier to reason about and more likely to do what you expect. (People have no problem doing it to lay out websites with CSS–it's not that complicated.) At the end of the day, nibs make it a little easier to get started (like using Ruby on Rails, and the Active* set of libraries), but it does not belong in a serious project, as it would add a prohibitive amount of technical debt.
- pc86 13y ago
  If you say "provably" you really do need to... prove it. What studies are you citing when you say IB auto-layout is "provably the worst GUI?"
  - spac 13y ago
    He might have meant "probably".
    - mratzloff 13y ago
      This is one of those quintessentially Hacker News exchanges that I have begun calling "Hacker News moments".
    - SeoxyS 13y ago
      I did :). I wrote the comment on the bus this morning on my iPhone, and the autocorrect failed me! I wish I could still edit it to add a little more substance, though – hard to be thorough on an iPhone screen.
andrewljohnson 13y ago
Perhaps the worst, most insidious, damning thing about IB is it keeps novice iOS developers novices. You end up with programmers who don't know what they don't know. I can write UI code faster than any developer I've ever met who uses IB, and that's doubly true for class hierarchies I have subclassed for multiple apps, and triply true when it comes time to change those subclassed hierarchies. You note that IB is for simple UI layouts, but I would argue that for layouts that simple, the code is simple too. Maybe it's a matter of how you think, but I can "see" the changes when I adjust the frames, colors, padding, resizing masks, and that's basically all IB will do for you. IB will also happily confuse your localization effort, and introduce bugs when you ship apps with unreferenced XIBs.
- jakebellacera 13y ago
  > Maybe it's a matter of how you think, but I can "see" the changes when I adjust the frames, colors, padding, resizing masks, and that's basically all IB will do for you. I know what you mean. I'm not an iOS/Cocoa dev by any means, but when I write CSS I typically know what the outcome is going to be in my head because I've done it so many times.
  - jcampbell1 13y ago
    I can see it in both code and interface builder. Doing it in code on iOS is like using CSS where the only selector is `#id` and there are no child selectors. Would you write CSS if you had to do this? #username-label { text-align:right } #first-name-label { text-align:right } ... #last-name-label { text-align:right } #address-label { text-align:right } With CSS, you get nice things like: #user-form label { text-align: right } iOS code looks more like the first example but it goes on for hundreds of lines. You can create something like classes by creating real classes, but then you end up with inheritance hell. I find IB's WYSIWYG to be a lesser evil.
    - BHSPitMonkey 13y ago
      If your iOS code comes out looking that repetitive, sub-optimal code organization is probably the real culprit.
abbott 13y ago
I'd love one of these for Android. I am also anti-nibs: Examples — NIB caching; Managing UI in two places (class & IB); Nightmare managing versioning and diffs (same from @SeoxyS), especially in a team environment; "Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app" (Repost from @SeoxyS); Want a custom UI implementation? Forget about using NIBs Without NIB's — yes you have to write a lot more code. Concerns of code bloat are overblown. Your viewcontrollers are likely already bloated without inline UI implementations. It really comes down to personal preference especially on smaller projects/apps, but I'd argue if you have ever worked on a large scale app that you are responsible for maintaining and enhancing long term, your opinion of NIB dependencies will change. This is especially true as your team pushes the limits of the UI and app performance. If I was going to teach you how to write an app, I'd explain what NIBs are (known pros and cons) and let you decide for yourself. Just like explaining to (my) kids about religion. Fun fact, not all WWDC examples use NIBs. Say what?! Blasphemy!
- M4v3R 13y ago
  Also a fun fact: Stanford University in their CS 193p classes teaches how to utilize Storyboards. And Auto Layout. And everything else that Apple provides for the devs.
  - abbott 13y ago
    There is a huge difference between academia and real world products shipped by teams w/real world experience w/academic backgrounds. Stanford academic guidelines endorsed and supported by Apple, Inc. I wonder what approach Evan Doll uses at Flipboard...hmmm?
    - argonaut 13y ago
      While I have no idea why M4v3R made that comment, as it's utterly irrelevant what Stanford teaches in their iPhone app class, it's also evident that you don't even know what M4v3R is referencing. He's referring to a class Stanford teaches on making iPhone apps, which has nothing to do with any sort of academic guidelines. The professor chose to use Storyboards, and that's that.
andymoe 13y ago
xibs get in the way really really quickly after you ramp up. I would rather have a solid UI library built out that I can use between apps than have to constantly reinvent the wheel and fight with xibs and the GUI editor. Maybe they are fine for one man projects but for larger apps and larger teams they are almost certainly a mistake especially if you use them all over the place. I'm not saying they did not work for hipmunk or for you generally but every app I have taken over that uses them extensively has been a nightmare to get back on track. Maybe I just have not been burned by the roll your own approach yet but I sure have been burned by the use xibs for everything approach.
koko775 13y ago
Hey, long-time iOS dev here. Interface Builder is emphatically a beginner's friend. For "major league" stuff it is wholeheartedly the enemy. Avoid Storyboards like the plague. It's merge nightmare city when in teams, and a big enough app will suffer under the complexity required. It's simply not worth the pain. With DCIntrospect (https://github.com/domesticcatsoftware/DCIntrospect https://github.com/domesticcatsoftware/DCIntrospect), positioning in code actually becomes easier than nibs. You can print out the view properties, tweak positioning, then once it looks right you can get the values you need to tweak your code. Additionally, getting to know UIAppearance and adding categories to UIColor and UIFont that return your app's standard fonts let you create a styleable application with consistent typography and color palette.

objclxt 13y ago

I agree with pretty much everything you say (especially now Apple will be pushing auto-layout for newcomers to the platform), but the one thing that's really bothered me with the "Your First iOS App" tutorial is that as some point it switched from NIBs over to a full Storyboard. And Storyboards are certainly in principle a cool idea, but I've never seen a production app that has actually used them (please do correct me if you're reading this and use them in your own shipping app). As far as I know, Apple aren't dog-fooding them in their own apps either. I'm not sure of the benefits of introducing them as pretty much the first thing out of the gate. But I'm prepared to be wrong!

danilocampos 13y ago
Yeah, Storyboards are still in their awkward phase. That's totally fair. And I don't yet trust them for running view navigation. But you know what they're awesome for? Static table views. If you want to build a grouped table view as login view, settings panel or the like, Storyboards are perfect. I'm also a big fan of Storyboards for prototyping. You can get to a pretty good fidelity demo of your app's information architecture, and often you can re-use what you built when it's time to code the app for real. (Though I often cut the Storyboard content out and paste it into a nib.)
- brodney 13y ago
  Half the stuff on my storyboards aren't even connected. I treat it like a big nib file. It's excellent for having everything displayed in front of you, in one place, and you can add segues and other storyboard magic as needed.
Scorponok 13y ago
Our app has ~15 view controllers laid out in a single storyboard, and we haven't had any issues with them. We only have one iOS developer, so I don't know if that makes a difference. We don't really use segues, though, since they seem to add complexity if you want to pass data around between the view controllers.
- tvon 13y ago
  In case you are not aware, there is UIViewController's `prepareForSegue:sender:` method (http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html http://developer.apple.com/library/ios/#documentation/UIKit/...). In short you figure out which segue was being prepared (segue.identifier) and setup the destination view controller (segue.destinationViewController) as needed.
- ant512 13y ago
  I've got a production app I switched from nibs to storyboards. It's got a storyboard for the iPhone and a separate storyboard for the iPad. 58 views on each. I'm using segues for pretty much all navigation. It's working amazingly well for me.
M4v3R 13y ago
I'm writing a fairly complex iOS app, and I opted in for storyboards in it. It doesn't handle 100% of navigation, because I only was invited to work on the app at some point and I didn't feel to rewrite the whole thing, but I use it for a substantial part of UI. It gets a while to get used to, but then you have this very cool overview of this whole part of the app. Some static parts are done 100% in IB (like a menu with grouped-style UITableView, utilizing static cells), others only use placeholders which are filled in code. But it works, and it works pretty well.
nanijoe 13y ago
How would you know if a production app was using Storyboards? I just submitted my first "Storyboard App" . It was a little uncomfortable for me seeing as I have gotten used to using NIBs, but I did it because I assumed Apple was moving away from NIBs.. I wonder how other people who use Storyboards do it..I pretty much had to sit at a desk with my MBP connected to external monitors anytime I wanted to do any work, just because the Storyboard required a lot of screen space.
- objclxt 13y ago
  > How would you know if a production app was using Storyboards? Because just like NIBs, Storyboards exist as part of an app's resource bundle, which is easily viewable. It is usually fairly straightforward to examine an IPA from the store and determine whether it's using NIBs and the like.
  - BHSPitMonkey 13y ago
    I think the most likely explanation is that the grandparent commenter was referring to their own experience with projects they've worked on.
Aqua_Geek 13y ago
> And Storyboards are certainly in principle a cool idea, but I've never seen a production app that has actually used them Fly Delta app uses them all over the place (first-hand experience) - they're fantastic for static cell table views. Admittedly, merging them can be a HUGE pain, though. > As far as I know, Apple aren't dog-fooding them in their own apps either. From what I've heard from an Apple engineer, Apple doesn't dog-food a lot of this stuff because the tools either don't exist yet by the time they need to ship or aren't stable. A lot (most?) of their apps end up being done programatically.

meeech 13y ago

"There's enough tedious code to wrangle in iOS as it is – don't create more for yourself by rejecting a mature, useful tool." That's probably true. But some of us learn better by doing the tedious bits (basically less magic) to see how everything works together, and then look for the path to remove the tedious bits (which would lead to using IB) once we have a better grasp of things. So this tutorial is quite welcome.

danilocampos 13y ago
Oh yeah – you should totally understand how the magic works. But there's an odd strain of fear against IB, so it bears mentioning.

allsystemsgo 13y ago

I jumped into iOS dev after storyboards so, I fear nibs... I've never used one. If I started with a storyboard, should I throw in nibs every now and then for certain tasks??

danilocampos 13y ago
Here's the haphazard way I'm using this stuff these days: 1. Non-view controller views. These typically go in nibs. Custom tableview cells, tableview headers used across multiple views, custom buttons, nibs are all fine for this. (And the UITableView API accepts nibs for setting up reusable cells.) You can certainly do custom tableview cells in Storyboards, but it's weird because I don't know how you can re-use those cells across multiple tableviews. 2. View Controllers. These I'm often using Storyboards to build. Since they're great for static tableviews, Storyboards end up having a decent chunk of stuff built in them lately. It can be nice to look at two views side by side. I seem to be grouping related view controllers together in single storyboards. Nibs have performance penalties if they're packed down with too many objects, as every single one has to be loaded into memory. My understanding with Storyboards is that they don't have this drawback, so that's helpful.
bennyg 13y ago
I like to think of Nibs like classes. A lot of times I'll have a certain design I want reused throughout the app, and this works perfectly. For instance, in an app I'm working on now, I have a few different views that have scroll-views inside of them, with each object of the scroll-view being a view itself. In the last of the chain of views, I use a nib because there's a solid amount of data there, and visually designing it in IB is easier to iterate and make it look exactly like I want it to. I have a .m/.h attached to the view (just a subclassed UIView) with a custom init method, returning what is basically a custom object (that happens to be that .xib). It's super efficient to make changes and keep things looking good when the data or the feature-set needs to change.
- BHSPitMonkey 13y ago
  Keep in mind, this scenario is just as good a candidate (maybe even better) for doing the layout in code rather than a nib.

jallmann 13y ago

Writing code in iOS is tedious, but IB is also dog slow and XCode becomes pretty unresponsive every time I switch to/from it. Not to mention the mess xibs make in source control. There is no reason for xibs to be human readable -- a binary format would limit diff hemorrhaging, and performance would certainly be helped by not having to process unholy amounts of XML. Either way, good luck merging xibs with multiple collaborators.

SeoxyS 13y ago

I've been a Cocoa developer for close to a decade now, and I've gone back and forth on this many times, but by now I've settled 100% in the nibs-are-evil camps. There are several reasons for that: - Nibs are a nightmare when working with version control and merge tools. Now, at least, they are XML instead of a proprietary binary format, but it's still a joke… - Auto-layout in IB is provably the worst GUI I have ever used. It's completely impossible to make it do what you actually indent. I was one of the guys cheering and wooing in the audience when it was announced at WWDC 2011, but it's proven to be a huge flop. - I have a similar experience with storyboards. - Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app. - Ultimately laying out your views in code doing some simple arithmetic is easier to reason about and more likely to do what you expect. (People have no problem doing it to lay out websites with CSS–it's not that complicated.) At the end of the day, nibs make it a little easier to get started (like using Ruby on Rails, and the Active* set of libraries), but it does not belong in a serious project, as it would add a prohibitive amount of technical debt.

pc86 13y ago
If you say "provably" you really do need to... prove it. What studies are you citing when you say IB auto-layout is "provably the worst GUI?"
- spac 13y ago
  He might have meant "probably".
  - mratzloff 13y ago
    This is one of those quintessentially Hacker News exchanges that I have begun calling "Hacker News moments".
  - SeoxyS 13y ago
    I did :). I wrote the comment on the bus this morning on my iPhone, and the autocorrect failed me! I wish I could still edit it to add a little more substance, though – hard to be thorough on an iPhone screen.

andrewljohnson 13y ago

Perhaps the worst, most insidious, damning thing about IB is it keeps novice iOS developers novices. You end up with programmers who don't know what they don't know. I can write UI code faster than any developer I've ever met who uses IB, and that's doubly true for class hierarchies I have subclassed for multiple apps, and triply true when it comes time to change those subclassed hierarchies. You note that IB is for simple UI layouts, but I would argue that for layouts that simple, the code is simple too. Maybe it's a matter of how you think, but I can "see" the changes when I adjust the frames, colors, padding, resizing masks, and that's basically all IB will do for you. IB will also happily confuse your localization effort, and introduce bugs when you ship apps with unreferenced XIBs.

jakebellacera 13y ago
> Maybe it's a matter of how you think, but I can "see" the changes when I adjust the frames, colors, padding, resizing masks, and that's basically all IB will do for you. I know what you mean. I'm not an iOS/Cocoa dev by any means, but when I write CSS I typically know what the outcome is going to be in my head because I've done it so many times.
- jcampbell1 13y ago
  I can see it in both code and interface builder. Doing it in code on iOS is like using CSS where the only selector is `#id` and there are no child selectors. Would you write CSS if you had to do this? #username-label { text-align:right } #first-name-label { text-align:right } ... #last-name-label { text-align:right } #address-label { text-align:right } With CSS, you get nice things like: #user-form label { text-align: right } iOS code looks more like the first example but it goes on for hundreds of lines. You can create something like classes by creating real classes, but then you end up with inheritance hell. I find IB's WYSIWYG to be a lesser evil.
  - BHSPitMonkey 13y ago
    If your iOS code comes out looking that repetitive, sub-optimal code organization is probably the real culprit.

abbott 13y ago

I'd love one of these for Android. I am also anti-nibs: Examples — NIB caching; Managing UI in two places (class & IB); Nightmare managing versioning and diffs (same from @SeoxyS), especially in a team environment; "Having classes that may be instantiated both from code or from NIB deserialization adds a layer of complexity and messiness to your app" (Repost from @SeoxyS); Want a custom UI implementation? Forget about using NIBs Without NIB's — yes you have to write a lot more code. Concerns of code bloat are overblown. Your viewcontrollers are likely already bloated without inline UI implementations. It really comes down to personal preference especially on smaller projects/apps, but I'd argue if you have ever worked on a large scale app that you are responsible for maintaining and enhancing long term, your opinion of NIB dependencies will change. This is especially true as your team pushes the limits of the UI and app performance. If I was going to teach you how to write an app, I'd explain what NIBs are (known pros and cons) and let you decide for yourself. Just like explaining to (my) kids about religion. Fun fact, not all WWDC examples use NIBs. Say what?! Blasphemy!

M4v3R 13y ago
Also a fun fact: Stanford University in their CS 193p classes teaches how to utilize Storyboards. And Auto Layout. And everything else that Apple provides for the devs.
- abbott 13y ago
  There is a huge difference between academia and real world products shipped by teams w/real world experience w/academic backgrounds. Stanford academic guidelines endorsed and supported by Apple, Inc. I wonder what approach Evan Doll uses at Flipboard...hmmm?
  - argonaut 13y ago
    While I have no idea why M4v3R made that comment, as it's utterly irrelevant what Stanford teaches in their iPhone app class, it's also evident that you don't even know what M4v3R is referencing. He's referring to a class Stanford teaches on making iPhone apps, which has nothing to do with any sort of academic guidelines. The professor chose to use Storyboards, and that's that.

andymoe 13y ago

xibs get in the way really really quickly after you ramp up. I would rather have a solid UI library built out that I can use between apps than have to constantly reinvent the wheel and fight with xibs and the GUI editor. Maybe they are fine for one man projects but for larger apps and larger teams they are almost certainly a mistake especially if you use them all over the place. I'm not saying they did not work for hipmunk or for you generally but every app I have taken over that uses them extensively has been a nightmare to get back on track. Maybe I just have not been burned by the roll your own approach yet but I sure have been burned by the use xibs for everything approach.

koko775 13y ago

Hey, long-time iOS dev here. Interface Builder is emphatically a beginner's friend. For "major league" stuff it is wholeheartedly the enemy. Avoid Storyboards like the plague. It's merge nightmare city when in teams, and a big enough app will suffer under the complexity required. It's simply not worth the pain. With DCIntrospect (https://github.com/domesticcatsoftware/DCIntrospect https://github.com/domesticcatsoftware/DCIntrospect), positioning in code actually becomes easier than nibs. You can print out the view properties, tweak positioning, then once it looks right you can get the values you need to tweak your code. Additionally, getting to know UIAppearance and adding categories to UIColor and UIFont that return your app's standard fonts let you create a styleable application with consistent typography and color palette.