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.
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.
Since you seem to be catching some flak for your post, I'll elaborate a bit further.
AutoLayout is a constraint solver, and as such it's very easy to either over-specify or under-specify your constraints in a way where it no longer evaluates.
On top of this, AutoLayout also has a priority for each constraint such that if/when such a conflict occurs AutoLayout has some ordering as to which constraints get abandoned first.
When you run into cases where AutoLayout breaks, debugging is a chore. You have to go through your entire view hierarchy and query each view for its hasAmbiguousLayout flag, which will give you some pointers as to what views are breaking your whole layout.
Interface Builder makes this somewhat worse because it doesn't give you an easily understood 1:1 match between what you do in the UI vs. the code that gets generated out of the other end. The opacity makes it hard to triage AutoLayout failures.
We use AutoLayout in small parts of the app, and we've found that doing it in code has been preferable - for a system that is as easy to break as AutoLayout you really don't want to be poking buttons on the top of a black box in the hopes that whatever comes out the bottom is sane. If there was a more transparent mapping of Interface Builder -> NSLayoutConstraint this would be less of an issue.
Also, yes, XIB merges are one of the Prime Evils of Hell, second only to pbxproj merges.
It's hard for me to believe that Storyboards or AutoLayout were designed by someone that actually builds non-trivial apps for a living. They're the kind of technologies that look good in a one-hour conference demo but quickly fall apart in real world use. After nearly throwing my laptop across the room on my latest project I ripped AutoLayout out of my project entirely and went back to springs & struts + frame math.
What this means though is that a layout I can build in five minutes in Android with <GridLayout> takes hours in iOS and is utterly opaque to version control. This is a cost I have to pass on to my clients.
I understand it. The problem is that not only is it a fundamentally flawed concept but the tools are inadequate. Moving a control by as much as one pixel in IB can completely scramble your constraints, including deleting user constraints attached to properties.
The API is ridiculously verbose and the visual language is underpowered and cryptic. It's sad but going back to manual frame calculations actually saved me a lot of time.
I think a lot of iOS devs don't realize how crap it is because they haven't taken the time to learn how other platforms solve these problems in a much more logical & developer friendly way.
The API, on the other hand, is very nice. Although constraints can be slightly verbose, they are ages better than having to manually re-layout views after every single change of the superview's bounds. Spring and struts are nice, but cannot replace all of the CGGeometry math which is equally as, if not more, verbose than adding constraints. Autolayout is add-and-forget. The only downside is that it is iOS6+ only.
Have you done any Android dev? I find the various layout containers there far, far more intuitive and explicit and semantically clear. Let's face it, 95% of UI is nested grid layouts. Plus, having instant visual feedback for layout tweaks is a big time saver.
I tried using Auto-layout on an app when it was first released, but for anything beyond simple cases it's incredibly buggy and unpredictable. It's now the first thing I turn off in any nib.
It's called an opinion. This isn't a peer reviewed paper we're talking about. And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion? Hardly.
>And his opinion is that merging Nibs is a nightmare. Does he need to document how he did it, when, where, and what the room temp was at the time to "justify" an opinion?
Does he needs to elaborate more in order to justify it?
Well allow me to elaborate - have you ever merged two nib files? With today's variant you merge XML. With yesterday's variant you simply don't do it because it's not possible. So you're merging an obtuse XML file at best. In my mind that's painful versus merging clean .h and .m files where we know what's going on. So he's using colorful language to describe such situations - A "nightmare".
We're a two person development team who sits in the same 5 foot radius and we've had to merge xibs semi-frequently. It's not overly viable to ask the person next to you what files they plan to work on in the hour, because that can be difficult to determine in advance. Additionally once I upgraded Xcode before my partner, and suddenly our xibs were out of sync. In terms of one person working on the UI, even if that's the case, the other person might change an outlet, or create a non-UI object in the xib. It's complicated to coordinate changes because the breadth of features (as they appear in the codebase) is unpredictable.
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.
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.
> 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.
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?
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.
Then run those through your loops. If you're seriously considering writing a lot of lines for something trivial, then you're probably doing it wrong in Objective-C.
I love UIAppearance. I am not too well versed in CSS but UIAppearance adds a lot of what I have seen done with CSS. You can change the default appearance of most default elements really easily, and declare containers inside of that with a whole different set of defaults. It makes styling your app a really painless process. All you have to do to make all the UIToolbars in your app red, for example, is use this one line at the start of your program.
You could write generator/setter methods for aligning labels to the right, no need for inheritance here. But, smart categories and inheritance go a long way. The last time I tried IB, I really regretted it because I constantly had to click through all those element layers (object hierarchy inspector is not that good either). After about 2h I gave up and rewrote everything to code-only.
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.
"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.
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), 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.
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!
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.
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.
+1 for this. Also, I18n with nib files is a pain, the CLI tool that xcode provide for translating nib files is a joke really... Also, if you have custom UI or a custom font, you're nib file will look like shit anyway...
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!
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.)
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.
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.
> 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.
> 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.
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.
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.
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.
In case you are not aware, there is UIViewController's `prepareForSegue:sender:` method (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.
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.
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??
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.
The end product, what my nib is for, has 12 labels, three UIView border bars (1px thick), two UIViews just for a differing background color in a couple spots, and a UIImage. Now you're right, I could set all those in code, alloc all those labels and adjust their sizes and positions relative to the ones that came before and all of that jazz, and that's all fine and dandy. Until I realize that my design needs tweaking. So, instead of selecting all elements on the nib and pressing up twice for a two pixel shift, I'm sitting there editing 20 different things in a CGRect call... way more work.
So instead of doing it all in code, the way I went about was creating a subclass of UIView with a .xib file attached to it. The .xib has everything where I want it visually and it's connected to the header via properties of everything that needs to be dynamic. Then I made a custom init method that just takes in my object and returns a UIView object that is the totality of that nib loaded with the data I need it to be.
All in all, instead of bloat, every time I need to return an instance of that custom subclass I effectively call something like this:
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.
Having made a few iOS apps in team/solo environments, I now stick to the following:
Large team - don't use Interface Builder. Synchronizing it is too difficult and any productivity gains will be lost. Layout in code is best here, but really is time consuming for complex UIs. However, pixel-perfect match for designers is a great benefit since you're specifying everything in pixels that you can copy right out of the designer's graphic.
Solo dev on a small app - Storyboards. In this case, 99% of the time the budget is fairly low and getting out something that works is the most important. Storyboards can speed things along and make it quick for matching a design to an outside designer's Photoshop.
Small team with only a couple of developers - either way is fine, but you need to manage it correctly. If going for Interface Builder, you need to have a list of devs who 'own' each screen, and only they make changes to it. This prevents any kind of conflicts when merging. If going for in-code layout, make sure the design is set in stone and won't change. Moving things around to meet designer's goals for a small team can kill productivity fast.
Also if you like TDD (it's not really popular at all in iOS dev circles, probably because TDD for ObjC/UiKit is not that great), then 100% stay away from IB. IB and TDD are very incompatible in my opinion.
Can you elaborate on why you feel IB and TDD are incompatible? I haven't found it particularly difficult to drive out behavioral tests for views/view controllers powered by NIBs (at least relative to Obj-C TDD in general), since any actions or subview settings you declare in your NIB will be exposed programmatically as well. I'd love to hear about what pain points you have.
This article, although still great for beginners to get started, is using dated techniques that should be avoided.
In the past, developers would have resorted to starting with interface builder to do their designs. As they continued the development process, theyd notice that more and more of their views had to be done in code because Interface Builder wasn't powerful enough to do what they wanted. It could then be understandable why for newer projects, someone would skip Interface Builder altogether and go for code-only from the start.
Things have changed now though. Auto-Layout is extremely powerful in both Interface Builder and through code. Out of the box your visually designed interfaces now support powerful alignment and resizing irregardless of screen size. This is a big deal because there are a lot of screen sizes in iOS these days (iphone4, iphone5, ipad, all of these in landscape and portrait and yet again all these permutations with and without the keyboard open). auto-layout makes internationalization super easy too as all objects on your interface are designed to get bigger as words get longer (such as in German), yet have all associated objects around them still be perfectly aligned. Even right-to-left languages (and interface re-ordering) is supported without any additional code.
Looking at the code in the article, none of these are supported. If you even turn your iphone landscape the ui will be cut off. Let alone supporting ipad, keyboard open, longer words in the buttons/labels, etc.
I hear this over and over again but don't understand why "complex" suddenly means "non-idiomatic UX." Most iOS apps follow common design patterns, and IB makes building these patterns extremely straightforward. For the one-off odd screens, sure, don't use IB, but certainly if you are building an iOS app the majority of screens will not require crazy unique UX. If they do that is probably a design smell.
Really? Every app I see in the top ten and every app clients want me to build for them is customized out the wazoo, with nary a stock control in sight. Most apps these days have highly dynamic content too, with elements resizing, moving around, and appearing and disappearing based on context. IB is worse than useless for this kind of UI and editing AutoLayout in IB should be considered cruel & unusual punishment.
I have to say I agree totally the philosophy of this article. I tried interface builder when I first got started on iOS development, but I just found it far too restrictive in terms of creating the sorts of interfaces I needed.
I can see it's uses for simple apps, but when you've got something complicated where there's lots of non-trivial interactions between the different elements and you often want to change certain parts of the interface (like adjusting the set of buttons visible on the toolbar depending on the mode you're working with), interface builder doesn't really cut it.
Perhaps this is just my nature - I prefer expressing things programatically and having everything defined in code (or in a suitable declarative language). It gives me a lot more control over how changes in the UI happen. But it depends very much on your background and the type of app you're developing and I can understand its appeal for some developers.
As always, you should choose the right tool for the job.
I've finally arrived at the fascination with learning something by just starting with nothing and building onto it one step at a time.
My first two to three years of programming were spent jumping into random tech (like Rails, SQL, jQuery) and faking it til I made it (although we all still fake it with jQuery). I didn't necessarily understand my tools but it let me rapidly gain a feeling for how tools come together.
But now that I have a fledgling intuition and opinion on how software can be put together, I've gone off the deep end this year and have been learning from the other end of the spectrum: By starting with a blank canvas and using no other reference than API docs and maybe some Getting Started blog posts if I get stuck.
Some examples:
* Learning Emacs starting with nothing but `C-h` and Open File (`C-x f`). Don't install a plugin until you've toiled with the vanilla way for a while.
* Building familiarity with Linux by installing Ubuntu on a VPS/VM/partition and slowly creating your own bash aliases for commands. Like `untar` instead of `tar -xzvf` or `ag-install`, `ag-upgrade`, `ag-depends` for the various apt-get commands. Read the man pages and see if you can improve your abstractions (aliases) with options you didn't know about. I don't remember the iptables file location. I just type `edit-iptables`.
* Learning iOS dev via RubyMotion which has a really nice cli workflow.
* Learning Clojure's Ring, Ruby's Rack, Python's WSGI, etc. by making a Hello World app and gradually expanding it piece by piece. Add session support. Params support. Create your own middleware. Then start looking at community middleware.
I'll put my hat in for 'use IB where possible'. I've used old IB, current IB, and programmatic for building Cocoa UIs and honestly it comes down to what you're doing with that project. Often IB gives you a nice productivity boost out the gate. It's worth building with it and banging heads with it so you know when to switch to putting on your coding tool belt.
I don't understand all the anti-IB sentiment. I feel like it speeds up my workflow tremendously compared to manual code, especially now w/ autolayout. I put off learning it for years and feel like an idiot for not learning it sooner. It's elegantly designed to not hide anything from the programmer (a common mistake with visual tools like it), it essentially is just a way to design an object hierarchy and pass it into code.
When the iPhone SDK came out, this was what you got. And this was how the first Apple tutorials were. Back then, there was no Interface Builder for iOS. All the views had to be laid out by hand. That's how I wrote my first iOS app. Man, that was tedious. I'm happy there's interface builder now. Though a word of advice: the ugly XML/plist format of interface builder files makes tracking changes or merging very, very difficult.
Title should probably be changed to remove the reference to Apple. I know the URL isn't an Apple one but I still thought this was something official they had put together. The article title doesn't contain the 'Apple's' part.
I came from a electrical and computer engineering background and so I am more used to procedural programming. When I started with iOS development, I tried IB but then I cannot figure out the magic and decided to create my UI mostly from code. Then, I started doing more and more software and adding more code, and managing it becomes painful. Since this is a personal project, I do not want to spend too much time and want to follow Apple's way of doing things. Since then, I started using XIB file and adding them slowly. It is important to realize that it is NOT an all or nothing approach. You can mix and match XIB and code with what you are comfortable with.
Some comments say that using UI will eventually restrict you. That might be true and I can totally see that. However, at that time, it is a good idea to step back and look at the overall design and figure out if you over design something. I like functional apps that work with little effort. It does not mean that it have to look ugly but you can customize and beautify the UI within the constraints of Apple's framework. Yes, there will be limits but is it worth the extra complexity of rolling it out on your own?
I have not tried storyboard but I would like to try it out soon.
In general, my philosophy has changed to use good, solid, reliable frameworks and keep the design (UI) and features (code) simpler. You will be able to get 90% of what you really want with less work (coding and maintaining).
XIBs are great for user interfaces that use components that are not table views. XIBs are completely unnecessary and actually a hindrance for view controllers whose primary UI element is a UITableView or UICollectionView.
Most apps, most of the time on iOS make heavy use of these two classes. Even if you're building a data entry form, you're likely to place the text fields inside of a UITableView.
For subclasses of UITableViewController, you actually have to do more work to use a XIB than not.
I find IB (and storyboards in particular) to be amazing for rapid prototyping (MVP anyone?). I can put together a basic app with 5 views, buttons, maps, whatever I want (as long as its a standard iOS control) in like an hour.
HOWEVER, in the long run storyboards can get annoying, because you're constantly switching between code and a visualizer. The first time you can't find what exactly is making that button do what its doing is quite frustrating, to say the least.
I've written 3 fairly sophisticated iOS apps that have highly customized user interfaces (most recently "Just Landed"). I dumped Interface Builder a long time ago and haven't looked back. For those interested, here's why...
I remember loving IB when I was just starting out with iOS. If you're building a quick throwaway app using stock UI components, it's great. However, as your app grows in complexity, and the needs for UI customization increase, IB quickly becomes a crutch and a source of hard-to-find bugs.
The nail in the coffin for me was realizing that IB would frequently get out of sync with my code if I renamed anything or moved code around. I found myself frustrated clicking through menus to hunt down incorrectly set IB outlets, fix references to nonexistent classes and methods that had been changed, and rewire event targets that had gotten out of sync with my code. There's also some UI customization that just isn't possible with IB, for example much of the stuff that the UIAppearance APIs now allow isn't customizable within IB, as well as any time you make a totally custom UI widget (IB doesn't really know what to do with it, and if memory serves me just shows a blank rectangle). Trying to add additional customization to IB user interfaces (beyond what IB can do) generally involves tagging them in IB, then retrieving them by tag in code, and then making the change. Convoluted and high maintenance IMHO.
When you add to this that changes to .xib files can't be easily merged, that it's generally pretty useless to diff them (the format is complex), and the fact that you have to look at both the .xib and your code to piece together the end-to-end functionality, it was pretty clear that dumping IB was going to be a big win for me. Turns out, it was.
I now override the -(void)loadView methods of all my UIViewControllers, and create and position all of my custom UI for each controller in there. I never have to worry about what IB will or will not let me do. Additionally, in the case of customized UI elements, I either create subclasses of UIKit classes (often subclassing UIView or UIControl), or categories of existing classes if the change to their functionality is small. Doing things this way also makes it much easier in the rare case that I need to do custom drawing within -(void)drawRect. I suppose what makes this a bit easier for me is that I have no problem visualizing the UI I've written in code before I actually see it. Other people may miss seeing their UI in IB and being able to visually edit it. I suppose I got over that pretty quickly.
If you're still not convinced, consider that by coding your UI by hand you'll also have a lot more control over memory usage since you control what gets created and when, you can share resources between elements more easily (colors, images, fonts etc.), and also avoid the performance hit of your app parsing .xib files.
But what does hand-coding your UI do to code length, you might say? In my experience it adds about 25% to the length of your UIViewControllers. Perhaps a small price to pay for all these benefits? For me it was the right tradeoff. Try it - I suspect you'll come away feeling empowered and understanding a lot better how UIKit works.
I think the perfect thing to do is use a tool when it's necessary to use that tool, and no more/no less. Sometimes it's unnecessary and a pain in the ass to use .xibs or storyboards and other times it makes iterating through designs magnitudes faster (why not select all objects in a .xib and press up twice for a 2 pixel shift instead of editing 20+ cgrect calls).
I can definitely see how .xibs and storyboards might be useful for prototyping or quickly mocking up and iterating on a design that is changing rapidly. Whether or not you ship the app with the .xibs intact I think depends on whether you can tolerate the problems I mentioned, or whether your app is simple enough that it's NBD.
Btw, for rapidly prototyping iOS apps I highly recommend Balsamiq - it's amazing what you can do with that tool :)
The things is, I've just never had those problems you mention in the 7 apps I've shipped, and I always use .xibs. Some apps of mine are simple, and some are fairly complex.
As a side note, I also hate, hate, hate using things like Balsamiq and other wireframing/mockup tools that you use a computer for. I'm a designer first and foremost (Art degree), and if I have to see something before beginning any coding/visual design work I'll draw it out on paper first. Most of the time though, I can keep the whole visual design process of which screens go to where and how they should look in my head. I think you're also underestimating how much visual design work has to happen, including after iterating a few times on the design, after doing your mockups. A few pixel shift here and there or bumping up/down a font-size, or even changing a gray from 65% black to 63% is fairly common. So, I just skip that mockup phase and start making the thing - iterating the design all the way through.
I think you misunderstand what I mean by "prototyping or quickly mocking up a design that is changing rapidly". It has nothing to do with achieving a pixel-perfect design, finding the perfect shade of gray, or the right font size. It has a lot more to do with quickly testing ideas and iterating, rather than committing to a design and trying to get a finished look.
Paper does work well for this, and you're free to not like Balsamiq.
I wrote my first little Cocoa app couple of days ago and indeed the most confusing thing was how stuff in interface builder interacts with the written code. (Coming from webdev background.)
Since when building a homepage is easy? I'm not talking about a simple static page with company contact info, but a full-fledged, dynamic web page. It includes knowledge of HTML, CSS, Javascript, (no)SQL and some backend technology like PHP or Python/Django/Sinatra. A whole lot more to learn than just one language - Objective-C.
Why? I've used nibs/IB pretty extensively since I started doing iOS development full time (about 2 years), maybe I'm still a novice and don't realize it but anytime I need to do anything complicated within a layout I can manipulate it programmatically.
The only objectively bad thing about IB is that the generated files are impossible to merge. It would be much nicer if they were more like Android's human readable xmls.
Perhaps you know how things are going on under the hood, but I have worked with many iOS developers, and the ones who love InterFace Builder have been clueless. They don't understand the actual view hierarchy, autoresizing masks, and god forbid you need an IB-guy to dabble in CoreGraphics drawing.
Do you really think that reinvent the wheel is better than using technology that a vendor gives you? Do you really think that folks at Apple make all their interfaces in code? Tip: Probably every feature that was added in Xcode was added because Apple engineers benefited from it.
I'm not reinventing any wheels - I'm choosing not to use a square wheel, and instead just write the code. Tip: It works for us and many other developers of high-ranking iOS apps.
I made a fake account to ask this question b/c I'm too ashamed not to know this:
Is there an equivalent Visual Basic-style editor for making iOS apps? You just place the button, double click on it, add functionality, drop in elements and you're off the races?
Just looking at this tutorial, it is astonishing how much knowledge you need to have to get up & running and create something so simple like a HelloWorld example (I've heard it is a herculean effort to do something really exotic like make text both bold and underlined in label on say a title screen)
Can somebody who knows their stuff please disabuse me of my ignorance/foolishness?
While learning how to do this stuff in code is a good exercise, it's much better to do these things in IB when possible. Here's the same app done in IB:
This is it, that's the whole app (there is also an AppDelegate which I didn't even open and contains virtually no code). There are literally 3 lines of code written by me here (compared by 40-50 lines in the article). Everything else is generated/hooked up in the NIB by Interface Builder. This was done in about 2-3 minutes.
In fact, this code performs better than the one from the article, because it uses Auto Layout. So when you rotate the device, you get a desired outcome:
People will say that Interface Builder is the equivalent and to some degree that's true - you use both to drag/drop UI elements on the page.
However, the main feature I think you are looking for from VB (and any Visual Studio language for that matter) is the ability to double-click on a something like a Button control and have it create a new click event all wired up ready to go for you to add your code (or take you to an existing click-event if you've already done this). So Visual Studio adds the delegates/wiring necessary for the control to fire properly when clicked on.
Unfortunately this is where Interface Builder gets crazy and confusing. Double-clicking a Button control in Interface Builder does not do this for you; Instead you have to use Actions for something like a click event and Outlets if you wanted to wire up a Label and then be able to programmatically change it from code-behind. You'll actually need to drag a special Outlet or Action connector in Interface Builder to make that crucial relation between Interface Builder and Xcode.
So while Interface Builder serves a very similar purpose to Visual Studios UI builder there is a pretty significant disconnect between it and the code-behind that makes it much less intuitive to use.
This is still fairly trivial stuff, and I like the IDE a ton better in Xcode than Visual Studio (seriously, I shouldn't have to stop my current build just to add lines in VS - that's lame). Just open up your dual screen editor, put the xib on the left or right, then your header on the other side. Right-click down on an element (hold it!) then drag over to the header. It'll set everything up you need to add your event actions in the header and implementation files, as well as the getter/setter methods.
Why the shame? It's not as if iOS development is taught in grade school ;)
Anyways, yes, in fact the linked tutorial is a version of Hello World without using Apple's own VB-like visual tools and doing everything in code. It's valuable to understand what's actually going on under the hood when you touch things in Interface Builder (the visual tool used to build UIs).
Keep in mind Interface Builder is not as simple as VB, but it's a reasonable place to start if that's your background.
> "(I've heard it is a herculean effort to do something really exotic like make text both bold and underlined in label on say a title screen)"
It can be, yes. Keep in mind that iOS specifically lacks API available to regular old MacOS largely due to performance concerns. It is at the end of the day a phone. NSAttributedStrings is what you're looking for in this instance, and constructing them can still be a pain.
>> "Is there an equivalent Visual Basic-style editor for making iOS apps? You just place the button, double click on it, add functionality, drop in elements and you're off the races?"
That's pretty much how it works on iOS with Interface Builder (for laying out UI's) and Xcode. It's only slightly more complicated. Instead of double clicking the button and having the method auto-created for you, you create the method yourself and then in Interface Builder you link your button to the method (Ctrl click and drag from the button to your First Responder/Class object).
Edit:
VB is slightly easier to create a click method from an object but having used it to develop a Windows 8 style app I feel like Interface Builder is simpler overall. VB required me to write a LOT of XAML even when I was dragging objects on to the UI and double clicking. With Interface Builder all standard UI layout can be done without writing any code.
The tutorial here is foregoing the Xcode templates that start you off with a view controller, which adds alot of complexity. Personally I prefer Paul Hegerty's approach, where using the basic Xcode template+Storyboards means you don't have to deal with app delegate/window stuff until you need or want to.
Previously underlining text was quite difficult, and required using CoreText (C framework) or an open-source wrapper around it, like TTTAttributedLabel. In iOS 6, support for attributed strings was introduced which makes it much easier.
That's interface builder ... It's not quite as "RAD" as VB was because you have to wire up all the data sources for things like tables manually, and rather than double clicking to add a click event, you have to this whole weird outlet/action thing. But, generally speaking, same concept :P
edit: I meant "weird" as in, weird to someone coming from VB-land. Once you're used to it there's nothing wrong or inherently bad with it
Way back in the day I started my software career in VB5. Helloworld in iOS isn't quite that simple, but pretty close if you follow a quick tutorial that explains what's happening. The most confusing part for newcomers to iOS is the connections between IB and code.
Starting in iOS is just like starting in anything else for the first time, it is all new so very little makes sense. As far as your example, the problem with the label pre-ios 6 was that it wasn't easily styleable beyond simple styles. For anything complicated it was generally easier to put the text in a web view and present it that way. With iOS6 Apple finally added an attributed text field with a lot more style options.
I have written native apps in both Android and iOS and each have their strengths and weaknesses.
I never actually used VB so maybe I'm talking out of my ass but...
Storyboards sound like an attempt to do what you're describing. You can throw together a bunch of views without writing any code at all, then string them together so that a tap on a given button or cell pushes one view to the next.
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.