If you're making fairly standard apps that substitute largely for websites - eg, login screens, some data in lists, couple forms - then you will probably want to go with IB storyboards. For these types of apps, development speed is most essential and future changes are mostly just tweaking the UI a bit as a large part of the functionality of the app is just pulling data from web services or doing standard calculations and displaying the result. Storyboards will let you get a nice looking and fairly simple UI done very fast and allow for rapid UI changes.
However, if you are going to have 3+ devs working on your app because it's actually the basis for a business or is very complicated, storyboards cause a lot of merge problems. They're far harder to create automated test code for. Refactoring your app becomes an exercise in tracking down IBOutlets. The couple days you saved at the start with easy layout and transitions get eclipsed by the amount of time you spend fighting IB later for changes. Also, if you use code review tools and have a heavy peer review culture then storyboards are a particularly bad fit.
Honestly I believe most apps fit into the first option and storyboards are the way to go. 95%+ of the apps on the Apple Store are definitely in the first category, and there usually isn't a need to over engineer them.
NIBs can be used in even extremely complex and large applications to make tasks easier. For example, iPhoto on iPad uses NIBs to load in UI interface assets as it's more convenient than doing it in code - and this is an app with a large development team and a significant codebase (there's an interesting WWDC 2012 video available on iPhoto's iOS architecture, which is where I got this piece of trivia from).
One of the problems with storyboards - versus NIBs - is that it can become difficult to work at scale. Not scale in terms of team members (although that can be a problem), but scale in terms of the size of your app's UI. A iPad app with a a dozen different screens of content can become very hard to navigate.
Where storyboards are useful is allowing those new to the platform to get up to speed on concepts such as custom table view cells, collection views, auto layout and the like without having to get bogged down in the large amount of code this would normally require. They're definitely not for everyone.
Sadly, NIBs have a bit of a bad reputation with some developers. I suspect this is mainly for historical reasons - as of Xcode 5 the XML schema has been significantly simplified making code review and source control much easier, and NIBs have significant advantages for newer technologies such as auto layout.
As the app has evolved over time and grown in complexity, we felt we reached a tipping point where using IB was slowing us down more than it was helping. Same for auto-layout.
Part of this was because the app simply has a lot more functionality today than it did three years ago, which means there were a lot more nibs to manage than before. Part of it is because we started developing more custom views that did not map to any existing IB components and thus had to be done by hand anyway. Part of it is because we found we had to switch to drawing certain things programmatically for performance reasons. Either way, I'm quite glad we made the conversion.
That said, I agree that most apps should start with IB and only move onto the more complex stuff once/if the need arises. IB helps a lot out of the gate (and also makes learning the platform a lot easier since you can visually see what you're setting up). Once it gets to be a hindrance, you'll know, and you can then make the decision to switch later on. And if your app goes nowhere, then you'll have wasted less of your time.
I also strongly agree that explicit is better than implicit, and configuring a view programmatically allows you to fully specify what its behavior should be, rather than what it happens to be. When you revisit a nib several months later after originally configuring it, sometimes you forget whether the configuration option you selected in the dropdown was intentional, or was it the default, or was it merely accidentally changed at some point?
1) Storyboards are different in Xcode 5 both constraints as well as the under-the-hood XML. It's much more human readable and cleaner. Easy to merge.
2) You can separate storyboard into logical parts. a)Signup flow b) Sign In Flow c) Tab1 and the rest of the navigationcontroller stack d) Shared controllers
One advantage is that it makes sure things are pixel-integral, no matter the scale factor of the screen. For example, his code example,
button.x = self.view.width * 0.2; // Position the inset at 20% of the width.
has a pretty good chance at starting the button at x=21.845, or some other point in-between pixels and producing a blurry line. If you do this same relation in Auto Layout, the engine makes sure that the positions and widths are all pixel-integral.
This is not as simple as just rounding everything, either! For example, if you have two views
[blue][red], you want to make sure you round their shared edge either to the left or to the right. Otherwise, there will be a gap between them. You need to make sure you round their shared edge the same way consistently too, or it will jump back and forth as you resize a window and produce a noticeable jitter.
Also, in that same code example, they set a button's x position to be directly related to the width of a view. If you ever want to support RTL interfaces, this is a bad idea. It is relating a width to a position. In a RTL interface, the correct code would be
button.x = self.view.width - self.view.width * 0.2 - button.width
Complicated! In general, you shouldn't convert between positions and sizes. Instead, I would make an invisible spacer view and lay them out like this using the layout format language
|[spacerView][button]
Then make a relation setting the spacerView's width to be 0.2 of the superview's width. This will produce constraints that correctly work in a RTL interface, laying it out like [button][spacerView]|.
Some things were harder than they needed to be, as well (e.g. centering a group of vertically layed-out elements). We often needed to create spacer UI elements to work around it.
FWIW, I rebuilt an iOS5-compatible version of AutoLayout (using Cassowary for solving and a lot of objective-c runtime magic to maintain a shadow hierarchy that consists of layout objects), which we even shipped for a while. Eventually we decided to move away and write our own system, with an emphasis on debuggability and simplicity. We ended up with a system that kept 90% of the benefits of AutoLayout but without needing to solve constraints.
The key element was the idea of 'smart rectangles' which were used for layout. You can set any two components explicitly of an axis (e.g. left and right) and the others (e.g width and centerX) would be determined automatically. Basically each rect system remembers the last two components on a given axis.
We also have the concept of a selection, which takes a group of 'rectangles' and can perform various operations as a group, like laying them out vertically, centering them all on an axis, and moving them as a group. This makes it easy to do things like center a group of vertically layed out elements (select, layout vertical, then set the selection's centerY).
The rectangles can then be applied to UI elements (which automatically handles rounding to pixel integrals, and ensures you don't end up updating UI unnecessarily as you build your layout, which is the problem with most of the UIView categories). But you don't necessarily need a UIView to apply - we've used this system for laying out OpenGL elements as well.
In practice, the code feels kinda like Autolayout:
buttonRect.centerX = bounds.centerX;
buttonRect.width = 100;
buttonRect.top = widgetRect.bottom;
buttonRect.bottom = bounds.bottom;
Hopefully we can eventually open source it - all of the devs who've used it miss it when working on personal projects.
In this case I would probably do something like:
red.left = blue.right;
red.leading = blue.trailing
to handle RTL scenarios
buttonView = [[UIButton alloc] init];
buttonView.translatesAutoresizingMaskIntoConstraints = NO;
[self.view addSubview:buttonView];
[self.view addConstraint:[NSLayoutConstraint constraintWithItem:buttonView attribute:NSLayoutAttributeTop relatedBy:NSLayoutRelationEqual toItem:self.view attribute:NSLayoutAttributeBottom multiplier:1.0f constant:0.0f]];
... etc
It's certainly better than the stress you'll have with UIView+Positioning or IB.
I'm the developer of UIView+AutoLayout, which is designed to provide the API that Apple should have in the first place (it's inspired heavily by the IB options): https://github.com/smileyborg/UIView-AutoLayout
Thank you for making this area of ios dev less painful. :)
Seriously though, thanks for this! It really makes working with AutoLayout so much easier.
Despite this I feel like Apple makes it very difficult to keep all UI code out of your view controllers. I'd go as far to say they actively encourage shoving UI code into your UIViewControllers. Take a look at the interface for UIViewController -- it is almost all view/presentation related [0]. Most of Apple's sample code and projects have view code sprinkled all over their UIViewControllers.
I feel like it is a constant fight to keep proper view/controller separation on the iOS platform.
#1 is saying that you're restricted to point based UI's in interface builder. This is absolutely not true. Wether you do you UI's in interface builder or code - use auto layout!
This way you get dynamic, resolution-independent UI's that can even work automatically with right-to-left text (realigning other elements according to text alignment).
The way the author is doing it is still point-based (just a bit more dynamic since he does some calculations) while auto layout has all this built in.
Yes, it is harder to get started with auto layout, but once you learn it, it is worth it.
#2, using things like UIView+Positioning still sets your frames. And it does so for each property you set. This means that the frame might be set 5 times instead of one (just for slightly cleaner code). This is not good since it might cause 5 calls to layoutSubviews instead of one (performance issue) and also it will ruin animations (dependent on a source and target frame).
Looking at that code reveals that it doesn't try to account for fractional positioning. If you set self.center on a view that is an even number of pixels wide, it will result in a non-pixel-aligned origin on non-retina displays, which results in in blurry rendering. If you're iOS-7 and iPhone only these days, that may not matter, but there are still millions of non-retina iPads out there, and in fact you can still buy new ones on the Apple store (both the original iPad mini and the iPad 2 are still for sale).
I've written lots of code for iOS and have generally always preferred programmatic layout over IB, but you have to be a little more careful than this post is implying. Beefing up your helper routines to take into account issues like the above is critical to making sure your UIs always look their best.
FWIW, I side on the NIB/Storyboard if your UI is even remotely complicated (sort of the opposite of what the article is saying). Having to nudge a ton of controls around in code is a huge PITA and time saved using NIBs and Storyboards (properly).
I imagine it would cause the occasional 1px drift but would probably be fine for most use cases.
Designers don't do things in code, they use the UI panel designer. end of story.
Because designers aren't coders. If you're after the coveted designgineer, good luck. They don't exist. Designers design things using the best tools for their job. Coders implement the design using the best tools for their job. Thinking that designers and implementers work on the same level is toxic.
the OP says that apple's NIB/XIB format actually makes a change to the file every time you open it, making uncommitted changes.
with android's XML, you make changes via the designer or otherwise. As far as I'm aware, simply reading/opening the files does not create random changes to the files.
Storyboards are good for small, simple apps where you're the sole developer (or maybe a team of 1-3). Go bigger, drop storyboards.
If you internationalise your app, you can extract all the copy out of a storyboard into a strings file.
Plus on a 13" laptop on the move? Oof, hard to deal with. Only really could work with them easily on a larger monitor.
For the most part IB mostly doesn't make sense for games, so I have a custom Photoshop script that exports each layer with metadata. A custom importer reads the metadata file and loads the whole view in the proper positioning. So I've basically swapped IB for Photoshop, but the work flow is essentially the same....
Recent example - went into a storyboard, changed a constraint, must have accidentally clicked on the wrong thing at one point, and the next time I ran my app, there was a faint detail disclosure icon in the middle of my view controller. It was absurd - somehow, unintentially, I had redirected a push segue onto a UIImageView. No clue how it happened, but it took me a good 10 minutes to diagnose it.
IB is just way too buggy to trust non-engineers with UI work, IMO.
this probably explains why android would have it but not iOS, originally iOS only had 1 screen size and didn't need it (though it still would have been much better). Now that new screen sizes are being released / rumoured its much more useful
I'm working on a design tool that aims to fix this: http://neonto.com
Neonto Studio is a completely visual environment with support for vector drawing, video, smart guides, multi-device layout with full previews, and so on... There's no coding involved -- this is an app for designers.
The tool generates readable iOS and Android code, and there's no special runtime involved, so it's ridiculously easy to take a few screens designed in Neonto Studio and drop them into a larger app.
It's currently in alpha testing. I'm hoping to release a full beta in the next few months. If you're interested in trying out the alpha today, I'd love to have your help -- just drop me an email at pauli <at> neonto dot com!
It doesn't tell me anything about the product.
I use UIView+Positioning, which exposes x, y, width,
height, right, bottom, centerX, and centerY as both
setters and getters.
You might need to use IB.
As a side note, I learned to enjoy Android layout systems. It was all a big mystery until I could finally test layouts interactively within the latest Android Studio [0] GUI. Although I'm not sure if I'd rather have a similar XML schema for iOS, I'd bet that the JetBrains folks might have already thought about doing this for their AppCode tool[1].
[0] http://tools.android.com/tips/layout-designtime-attributes/ [1] http://www.jetbrains.com/objc/whatsnew/
It's probably a testate to how good UIKit is to code with directly that makes it attractive.
Though whatever side you fall on, I think it's worth appreciating you have the choice. I remember when doing some brief Windows Phone development, and seemed all you had to work with was some XML API to design your interfaces. It was awful.
Recently I decided to give Storyboards a try on a project. I was shocked at how much time it saved (no more pushing/presenting view controllers, no more fighting tables to display custom cells) and for views that were only displaying information and a button to push another controller I didn't even need to create a class as the push could be done in Interface Builder. I don't think this approach is going to work well for all apps but when you've got something with a predetermined flow (a form for example) it saves a hell of a lot of time.
It's hugely valuable to get designers to adopt the SDK's design tools. Unless the designers on a project are obstinate about that, making that more difficult is usually a step in the wrong direction.
He also seems to be blaming the toolchain's refactoring and the declarative UI XML for being difficult to manage. It is really that bad?
There are two camps of iOS Engineers in my experience. Those that feel IB makes your life better and those that feel the opposite. Both sides make valid points, but I vote for sticking with code as much as possible.
It's a take on Apple's visual format language that allows for defining a ui from scratch: https://github.com/fjolnir/Visual-Layout-Language/blob/maste...