Your First iOS App – 100% Programmatically
blog.austinlouden.com
blog.austinlouden.com
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.
- 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.
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.
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.
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.
Which are like noses. Everybody has one.
>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?
Of course.
Merging isn't even funny with regular code.
How about having a process for who works on what or when?
Either than or let a single person be responsible for the UI.
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.
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.
#username-label { text-align:right }
#first-name-label { text-align:right }
...
#last-name-label { text-align:right }
#address-label { text-align:right }
#user-form label { text-align: right }
I find IB's WYSIWYG to be a lesser evil.
for (UILabel *l in @[self.usernameLabel, self.firstNameLabel, …]) {
l.textAlignment = UITextAlignmentRight;
l.textColor = [UIColor redColor];
} +(void)styleLabelForCertainPage:(UILabel *)label {
label.textAlignment = UITextAlignmentRight;
label.textColor = [UIColor redColor];
}
[[UIToolbar appearance] setTintColor:[UIColor redColor]];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.
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.
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!
Stanford academic guidelines endorsed and supported by Apple, Inc.
I wonder what approach Evan Doll uses at Flipboard...hmmm?
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!
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.)
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.
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.
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'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.
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:
UIView *newView = [CustomClass createCustomViewWithObject:(id)object];
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.
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.
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.
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 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.
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.
this
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.
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).
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.
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 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.
Btw, for rapidly prototyping iOS apps I highly recommend Balsamiq - it's amazing what you can do with that tool :)
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.
Paper does work well for this, and you're free to not like Balsamiq.
Using Interface Builder will make you a permanent novice.
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.
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?
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.
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.
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.
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.
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.
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
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.
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.