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.
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.
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!
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!
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??
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 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 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.
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 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.
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.
[+] [-] danilocampos|13 years ago|reply
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.
[+] [-] SeoxyS|13 years ago|reply
- 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.
[+] [-] andrewljohnson|13 years ago|reply
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.
[+] [-] jallmann|13 years ago|reply
[+] [-] meeech|13 years ago|reply
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.
[+] [-] koko775|13 years ago|reply
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.
[+] [-] abbott|13 years ago|reply
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!
[+] [-] objclxt|13 years ago|reply
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!
[+] [-] andymoe|13 years ago|reply
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.
[+] [-] allsystemsgo|13 years ago|reply
[+] [-] RyanZAG|13 years ago|reply
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.
[+] [-] lazerwalker|13 years ago|reply
[+] [-] arange|13 years ago|reply
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 highly recommend new iOS developers to start with Auto-Layout from the getgo: https://developer.apple.com/library/mac/#documentation/UserE...
It's like tables vs css. Use CSS, it's much more portable.
[+] [-] zachwill|13 years ago|reply
[+] [-] nahname|13 years ago|reply
[+] [-] peterkelly|13 years ago|reply
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.
[+] [-] danneu|13 years ago|reply
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.
So that's why I like these kinds of blog posts.
[+] [-] SurfScore|13 years ago|reply
this
[+] [-] nicholassmith|13 years ago|reply
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.
[+] [-] gfodor|13 years ago|reply
[+] [-] terhechte|13 years ago|reply
[+] [-] k-mcgrady|13 years ago|reply
[+] [-] Inebas|13 years ago|reply
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).
[+] [-] aaronbrethorst|13 years ago|reply
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.
[+] [-] SurfScore|13 years ago|reply
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.
[+] [-] jgrall|13 years ago|reply
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.
[+] [-] bennyg|13 years ago|reply
[+] [-] Yaggo|13 years ago|reply
[+] [-] kyrriana|13 years ago|reply
[+] [-] Kiro|13 years ago|reply
[+] [-] M4v3R|13 years ago|reply
[+] [-] titraxx|13 years ago|reply
[+] [-] JuDue|13 years ago|reply
[+] [-] andrewljohnson|13 years ago|reply
Using Interface Builder will make you a permanent novice.
[+] [-] myko|13 years ago|reply
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.
[+] [-] M4v3R|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] duffman|13 years ago|reply
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?
[+] [-] M4v3R|13 years ago|reply
http://dl.dropbox.com/u/1127246/Screenshots/op4t.png
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:
http://dl.dropbox.com/u/1127246/Screenshots/rulo.png
If you do the same with the app from the article, you'll see this:
http://dl.dropbox.com/u/1127246/Screenshots/sncv.png
And then you'll have to write another bunch of code in layoutSubviews method, or manually create struts and strings or constraints.
[+] [-] evo_9|13 years ago|reply
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.
[+] [-] potatolicious|13 years ago|reply
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.
[+] [-] k-mcgrady|13 years ago|reply
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.
[+] [-] MaxGabriel|13 years ago|reply
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.
[+] [-] CodeCube|13 years ago|reply
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
[+] [-] matwood|13 years ago|reply
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.
[+] [-] chairmankaga|13 years ago|reply
[+] [-] danilocampos|13 years ago|reply
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.
This is also pretty useful for prototyping.
[+] [-] raingrove|13 years ago|reply