
Your First iOS App – 100% Programmatically - austinl
http://blog.austinlouden.com/post/47644085183/your-first-ios-app-100-programmatically
======
danilocampos
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.

~~~
SeoxyS
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.

~~~
pablasso
Not any of those points is justified, "a nightmare", "the worst". You need to
provide something to support all those affirmations.

~~~
ianstallings
It's called an opinion. This isn't a peer reviewed paper we're talking about.
And his opinion is that merging Nibs is a nightmare. Does he need to document
how he did it, when, where, and what the room temp was at the time to
"justify" an opinion? Hardly.

~~~
coldtea
> _It's called an opinion._

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.

~~~
ianstallings
Well allow me to elaborate - have you ever merged two nib files? With today's
variant you merge XML. With yesterday's variant you simply don't do it because
it's not possible. So you're merging an obtuse XML file at best. In my mind
that's painful versus merging clean .h and .m files where we know what's going
on. So he's using colorful language to describe such situations - A
"nightmare".

------
RyanZAG
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.

~~~
lazerwalker
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.

~~~
BenSS
Please do a write up on how you use TDD with ObjC/VCs. I'm sure that others
would be interested as well.

------
arange
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 highly recommend new iOS developers to start with Auto-Layout from the
getgo:
[https://developer.apple.com/library/mac/#documentation/UserE...](https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html)

It's like tables vs css. Use CSS, it's much more portable.

~~~
zachwill
I seriously doubt you've made a complex app if you're recommending Auto
Layout.

~~~
gfodor
I hear this over and over again but don't understand why "complex" suddenly
means "non-idiomatic UX." Most iOS apps follow common design patterns, and IB
makes building these patterns extremely straightforward. For the one-off odd
screens, sure, don't use IB, but certainly if you are building an iOS app the
majority of screens will not require crazy unique UX. If they do that is
probably a design smell.

~~~
cageface
_Most iOS apps follow common design patterns._

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.

------
peterkelly
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.

------
danneu
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.

So that's why I like these kinds of blog posts.

~~~
SurfScore
_we all still fake it with jQuery_

this

------
nicholassmith
What a lovely tutorial, very well put together.

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
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.

------
terhechte
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.

------
k-mcgrady
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.

------
Inebas
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).

------
aaronbrethorst
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.

------
SurfScore
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.

------
jgrall
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.

~~~
bennyg
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).

~~~
jgrall
I can definitely see how .xibs and storyboards might be useful for prototyping
or quickly mocking up and iterating on a design that is changing rapidly.
Whether or not you ship the app with the .xibs intact I think depends on
whether you can tolerate the problems I mentioned, or whether your app is
simple enough that it's NBD.

Btw, for rapidly prototyping iOS apps I highly recommend Balsamiq - it's
amazing what you can do with that tool :)

~~~
bennyg
The things is, I've just never had those problems you mention in the 7 apps
I've shipped, and I always use .xibs. Some apps of mine are simple, and some
are fairly complex.

As a side note, I also hate, hate, hate using things like Balsamiq and other
wireframing/mockup tools that you use a computer for. I'm a designer first and
foremost (Art degree), and if I have to see something before beginning any
coding/visual design work I'll draw it out on paper first. Most of the time
though, I can keep the whole visual design process of which screens go to
where and how they should look in my head. I think you're also underestimating
how much visual design work has to happen, including after iterating a few
times on the design, after doing your mockups. A few pixel shift here and
there or bumping up/down a font-size, or even changing a gray from 65% black
to 63% is fairly common. So, I just skip that mockup phase and start making
the thing - iterating the design all the way through.

~~~
jgrall
I think you misunderstand what I mean by "prototyping or quickly mocking up a
design that is changing rapidly". It has nothing to do with achieving a pixel-
perfect design, finding the perfect shade of gray, or the right font size. It
has a lot more to do with quickly testing ideas and iterating, rather than
committing to a design and trying to get a finished look.

Paper does work well for this, and you're free to not like Balsamiq.

------
Yaggo
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.)

~~~
kyrriana
Had exactly the same experience a week ago. Mad me yearn for Rails!

------
Kiro
When will building an iOS app be as easy as building a homepage? I really
don't understand why it must be such a big difference in complexity.

~~~
M4v3R
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.

------
titraxx
Thanks for this link, it is useful for beginners to understand. Comments are
even more interesting.

------
JuDue
Wonderful, I'll be checking this blog regularly.

------
andrewljohnson
This is exactly how you should build your first app.

Using Interface Builder will make you a permanent novice.

~~~
M4v3R
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.

~~~
andrewljohnson
I'm not reinventing any wheels - I'm choosing not to use a square wheel, and
instead just write the code. Tip: It works for us and many other developers of
high-ranking iOS apps.

------
duffman
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?

~~~
evo_9
Having used both, the answer is actually no.

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.

~~~
bennyg
This is still fairly trivial stuff, and I like the IDE a ton better in Xcode
than Visual Studio (seriously, I shouldn't have to stop my current build just
to add lines in VS - that's lame). Just open up your dual screen editor, put
the xib on the left or right, then your header on the other side. Right-click
down on an element (hold it!) then drag over to the header. It'll set
everything up you need to add your event actions in the header and
implementation files, as well as the getter/setter methods.

