

Becoming an iOS Developer - smiler
http://joshsmithonwpf.wordpress.com/2012/02/19/becoming-an-ios-developer/

======
dkarl
I'm a new Cocoa developer (on OS X) and can attest to the mental pain of
accepting Interface Builder if you're used to programming other GUI
frameworks. Usually I stick my neck out and comment on HN when I know what I'm
talking about or I think I have an interesting question, but here I'll speak
as a noob, for what that's worth. (I'm speaking so that people who know what
they're talking about can get the perspective of somebody who doesn't, in
other words. Please don't make fun of me, but corrections would really help.)

The first mental sticking point for people used to other frameworks is that
you really _must_ use Interface Builder as a beginner, even if it seems
undesirable or unnecessary. Drag and drop an NSFooView in Interface Builder,
and it will be nicely initialized and will act the way you expect. Instantiate
an NSFooView in code, and you have a debugging task ahead of you, because the
defaults you get when you init an object in code are different from the
defaults you get when you create it in Interface Builder. It doesn't look or
act the same at all. You end up creating the same object in Interface Builder
just so you can inspect its attributes and try to set them to be the same in
your code, maybe running your Interface Builder code in the debugger to see
how the object behaves. (I assume the same is true of UIFooViews, though their
default configuration might be closer to what Interface Builder creates since
iOS interface objects are newer, code-wise, than the NextStep-derived objects
used in Cocoa on OS X.) It's hard work to do things the wrong way. Someone
used to another UI framework can put themselves through a lot of misery trying
to figure out how to accomplish things in code without the help of Interface
Builder, before they realize Interface Builder is an important part of the
framework, not just a minor feature of Xcode that you can easily do without.

Another major cause of disorientation is that the learning curve is shaped
very differently because of Interface Builder. In a framework that doesn't
have a GUI builder, the beginner documentation holds your hand line by line
through the code required to create a window, instantiate UI elements,
configure them to behave properly, add them to a container, and specify how
they're laid out. Why all that? Because you can't do _anything_ without being
able to do that! You can't pop up "Hello World!" with a button below it saying
"Hi there" unless you can do all of the above!

With Interface Builder you don't have to do any of that in code. It's just
drag, drop, done. No need for a twenty-page tutorial that explains containers
and layout managers and the event-handling loop.

But here's the thing. There isn't much more to a typical UI framework than
containers, layout managers, elements inside the containers, and events. So
the "beginner" tutorial in a typical framework holds your hand across all the
territory you need to master, and a decent book will explain the things that
the tutorial glossed over. By the time you're able to make the button under
"Hello World!" change the text to "Ha ha ha fart face" you've learned all the
fundamentals, and you can reason things out for yourself. You're self-
sufficient! From that point on, the rest of the learning curve consists of
reading documentation for the various framework elements you need to use
(individual widgets, menus and menu items, layout managers, framework APIs for
background tasks, keyboard shortcuts, persistence of preferences, etc.)

Interface Builder, on the other hand, makes it so easy to get a simple
application up and running that programmers are assumed to spend a certain
amount of time at the static layout level. If you try to jump ahead and create
a more complex app (what I think of as a _realistically_ complex application)
then you're already leaving beginner territory. If it's your first app, then
you're trying to take the curve too fast. Personally, it's been weeks and I
don't feel self-sufficient. I don't grok GUI development in OS X at all; I
can't fend for myself at all in Cocoa-land; and it feels like I'm shamefully
slow at accomplishing these things. Creating widgets at runtime and laying
them out dynamically (because I don't know at compile time how many widgets
I'll need and of what type -- I SWEAR IT -- I will kill any man who questions
it) is just _killing_ me. All of the documentation seems to assume I know what
the hell I'm doing much more than I actually do. The response I get from other
beginners when I ask about dynamically creating and laying out views is,
"You're braver than me!" which isn't true. I'm not brave! I'm a shivering,
sniveling noob! I want this to be beginner stuff! But the Interface Builder
learning curve is shaped completely differently. What I'm trying to do follows
naturally from noob tutorials in other GUI frameworks, because it's _really
hard to be a noob_ in other frameworks. In Interface Builder, it's easy to be
a noob. How you get beyond that is still a mystery to me, though.

~~~
sopooneo
Pre-noob question: what do you mean by "NSFooView"? Googling for it revealed
almost nothing, so I take it that you made up the term as a stand-in for some
general case. Yes? If so, does NS mean something? Even something that is just
a joke or related only to your example? And are you using "Foo" as a reference
to the general stand-in phrases "foobar" and "foo = bar"? These questions are
sincere, and if you get a chance to set me straight I would seriously
appreciate it.

~~~
dkarl
NS is the prefix for Cocoa classes on OS X. It dates back to NextStep.
NSFooView is a stand-in for various subclasses of NSView that are the basic UI
components in Cocoa. If you open an OS X nib (see below) in Xcode and select
"Data Views" or "Layout Views" you'll have a choice of NSView subclasses to
add to your UI: NSTableView, NSOutlineView, NSSplitView, and so on. Custom UI
components usually subclass NSView.

A nib is a file created by Interface Builder that contains serialized objects
that can be reconstituted at runtime. An xib is an XML file that compiles to a
nib. An xib is somewhat human-readable and (if you keep the target platform
exactly the same) can be somewhat usefully diffed as you modify the interface.
I'd like to explain more, but my lack of understanding of the precise nature
and use of nibs is part of what makes me a noob.

~~~
sopooneo
Thank you. Understanding what abbreviations stand for has always been an
obsession of mine, and knowing the origin of "NS" may actually make learning
this stuff much easier for me. I really appreciate your taking the time.

~~~
patrickk
A little background to the 'NS' prefix:

<http://en.wikipedia.org/wiki/Cocoa_(API)#Cocoa_history>

------
commanda
"ARC is awesome, but I highly suggest that you don’t use it until you can
manage memory yourself. In other words, don’t rely on ARC until you understand
what it’s doing."

This is not good advice.

ARC is meant to free the programmer from having to think about memory
management and allow us to instead think about what we're trying to express in
our object graphs and algorithms. Deciding where to call retain and release is
an old, tired dance and is where the vast majority of memory leaks and app
crashes come from. With ARC, we can just relax and let the compiler insert all
those pesky retains and releases where it knows they should go.

There is no reason for newcomers to learn the old style. If a newcomer is
reading old-style code, she can skip over the retain/release calls and pretend
they're not even there, because they don't affect the algorithm.

~~~
nupark2
I very strongly disagree. ARC still reveals the underlying nuts and bolts,
necessitating a basic understanding of reference counting systems.

It doesn't solve retain cycles, thus requiring the judicious use of __weak in
cases where a retain cycle may emerge. Determining where such a cycle may
occur requires understanding reference counting. This significantly impacts
your expression of algorithms where the simplest/best implementation may
involve cyclic object graphs.

Additionally, ARC does not handle mixing CoreFoundation and Foundation code
directly, requiring one to manually express bridging rules based on an
understanding of reference counting.

It may be that ARC gradually smooths out its rough edges, and we find
ourselves in a situation similar to GC, where developers need only understand
the difference between weak and strong references, and the opportunities that
exist there for leaks caused by maintaining strong live references.

However, we're still a bit far from that point, and newcomers should remain
well-aware of retain/release and the vagaries of reference counting systems.

~~~
rpwilcox
I agree (with you, nupark) For example, thr other day I was debugging a crash
in my Cocoa (ARC) app. I've been programming Cocoa since 10.1, although I
stepped away for a few years.

Anyway, random crash. My "manage memory manually" training knew it was an
object getting released too early: I know I needed to retain it. Think think
think... Of yes, my @property declaration was missing a retain declaration. Of
_course_ cocoa was releasing that object!

ARC sure helps, and between it and use of the autorelease pool (thanks Brent
Simmons!) I hardly have to worry about memory management at all - except when
I do, then I need to know what ARC is or is not doing behind the scenes.

------
jmonegro
Here's how I learned iOS dev (still not wildly experienced, but I'm familiar
with the beast).

If you're a Rubyist, pick up PeepCode's Objetive-C for Rubyists. You're going
to watch that multiple times.

Then, go and get yourself a subscription at teamtreehouse.com and subscribe to
Stanford's CS193P (a fantastic course taught by Paul Heggarty) on iTunes U.

Treehouse's iOS 4 badges' topics are somewhat aligned with the topics on
CS193P. You should watch the topic on treehouse first, and then watch the
corresponding Stanford lecture, which will be much more detailed and a bit
heavier. Having watched the treehouse videos, though, you'll have a basic
understanding of what Paul is talking about, and the progression will seem
very natural.

Set aside 1-3 hours a day for this. The basic things I learned in a day, the
more complex ones like CoreData took me a bit longer. If you don't fancy the
homework assignments on iTunes U (the first one is rather boring, the other
ones are ok and practical), do something else that uses what you learned.

Two weeks of 2-3 hours a day and you'll be on your way.

------
cageface
XCode is the obvious choice for beginners but even after a short time of using
AppCode I hope I never have to go back: <http://www.jetbrains.com/objc/>

~~~
Volpe
Why?

~~~
cageface
\- Sane tab handling.

\- Much better refactoring support.

\- Excellent code generation.

\- Better project file management.

\- Superior navigation tools.

\- Deeper code analysis.

\- Better stability.

------
yrome78
I came to Objective-C from Java (server side web apps) and it really was quite
a shock. However, once I got past the syntax , I found that it was just
another OO language. Encapsulation, inheritance, interfaces, they were all
there. I will say that while Apple (and the web) provide lots of examples of
specific implementation details, they usually don't get past the simple stage
of that one API. It's a bit more challenging to put all of them together in a
way that is both good form and sensible for your problem.

Re learning: I highly recommend this site:
<http://cocoadevcentral.com/d/learn_objectivec/>

Very helpful for getting your mind around basic concepts.

Re: Interface builder. I think the trick is knowing when to use it and when
not to. Certainly it is incredibly useful for getting your layout exactly as
you want it. (This was a refreshing change from html) But it can be cumbersome
if you're trying to share common interface elements via subclassing or without
wanting to load a nib file every time. Occasionally I would use it just to get
the layout right and then implement the same interface in code.

------
gmcerveny
I'd order the steps 5, 6, 2...

1\. Build an app in Interface Builder. 2\. Learn Cocoa Touch. The breadth of
the library is more intimidating than the complexities of Objective-C. 3\.
Learn C and Objective-C.

Then think about paying apple to develop, releasing products, learning how
memory management works, adding core data...

------
jamieb
I was in a similar situation a few years ago, but I opted for Monotouch [1]. I
still had to learn UIKit, Foundation etc, but I didn't have to learn a "new"
language. I did have to hack together a Visual Studio package to trick it into
loading monotouch project files, but it was like 10 lines of code, and now you
don't have to.

I did spend several months developing (and shipping) two Objective-C apps for
the few months that Apple banned Adobe AIR (and everything else along with
it), and despite having spent 30 years programming, and a good part of that in
C and C++, the full awfulness of ObjC was a surprise. But if all you've ever
done is C#/WPF, ObjectiveC is going to be quite a shock. In fact there'll be a
lot of cognitive dissonance.

[1] <http://xamarin.com/monotouch>

------
jwwest
The biggest complaint I hear about iOS is the somewhat manual memory
management. It's really not that bad, and is nowhere near as tricky as C or
C++.

To be fair, iOS does have a garbage collector (NSPool), but you have to free
up references for it to reclaim space.

~~~
ryanpetrich
NSAutoreleasePool is not a garbage collector, it is merely delayed
deallocation. There is no such API as NSPool.

------
mihaifm
> You need to buy an Apple computer, an iDevice (iPhone, iPad, iPod Touch),
> and pay $99 per year to be in the iOS Developer program.

Is there any way around the "buy an Apple computer" requirement? Like
installing OS X on a PC?

------
userulluipeste
Started reading and here we go: "Apple gives Xcode away FOR FREE, [...] you
can GET IT."

About Apple's this and that: "WONDERFUL" (new compiler service), "which
[...(does miracles)] FOR YOU", "arc is AWESOME"

Long story short - there are a lot of evangelist's marks badly hidden that
convey into "acceptance and humility" - requested, and... oh yeah: "pay
Apple".

