
How to become an iPhone developer in eight easy steps - twampss
http://www.guardian.co.uk/technology/gamesblog/2009/feb/10/gameculture-apple
======
hboon
Several typos in the article and with a CTO quoted as saying things like
"Smalltalk is very similar to C", My alarm rings.

The 8 steps are not wrong, although simplistic. Most importantly, I would
reorder the list and move point 5 "Sign-up as an official developer" to the
very top. Sign up, pay the money and finish the procedure for tax-withholding,
if applicable. Do that from Day ONE. It looks like it takes Apple to finish
the contract paperwork in days for some developers, but up to months for
others. It took me 3 months, with no ETA, with 2 applications approved and me
sitting there like a lame, frustrated duck.

~~~
tlrobinson
I'm guessing he meant "Smalltalk is very similar to Objective-C" and he either
mispoke or was misquoted. He certainly knows that Objective-C was influenced
by Smalltalk.

------
gaius
I love that step 3 _learn objective-c_ is supposedly no more difficult than
step 2 _download the SDK_.

~~~
tlrobinson
Well, the SDK _is_ 1.75GB... so if you're on dialup or something it is pretty
difficult.

Why it's so big, I have no idea. A few months ago it was only 1.25GB. Maybe
they're including complete copies of the iPhone OS.

------
pxlpshr
Here's another side of the story from someone who jumped on board the AppStore
this summer.

<http://appcubby.com/blog/files/the_experiment.html>

Less kool-aid, more reality.

------
wallflower
"4. Start writing something!

Forget theory; forget mastering Objective C with your first attempt. Just set
yourself a project and start working."

A couple days ago I stopped slogging through Kochan's Objective C book (made
it to Chapter 7) and started coding. I think I was kidding myself that I could
learn by reading - I think it was an indirect form of procrastination. For
example, how will you ever learn that you need to use NSMutableString instead
of NSString if you want to modify Strings?

~~~
jemmons
Ummm... Look "mutable" up in a dictionary?

~~~
nonrecursive
I downmodded you because your response is snarky in addition to not being
applicable. If you're new to Objective C and are used to a language like Ruby,
where all strings are mutable, you wouldn't even realize it was necessary to
use a class other than NSString to modify your strings.

~~~
jemmons
If you're expecting a different language, framework, and platform to behave
like a ruby, I would argue _no amount_ of eschewing documentation and getting
down to coding will help you. In fact, I suggest documentation to be even
_more_ vital to you in this instance.

As to my snark, I'm only faithfully transcribing how I figured out I was
supposed to use an NSMutableString instead of an NSString. I was reading the
documentation for NSString (and this was back in the NeXTStep days, so it was
crap. Thanks Scott for making it a joy!) but I came across a line very similar
to what's there now:

"The mutable subclass of NSString is NSMutableString."

"What on earth to they mean by mutable?" I thought. So I looked it up. And
that's when it all made sense.

Note that it is _highly unlikely_ I would have figured this out by coding
alone. Sifting object dumps of NSString or whatever would not have helped
(unless I noticed -mutableCopy and was able to suss out what the
NSMutableCopying protocol was all about) -- esp. coming from C where the
expectation is there are no string conveniences and you have to roll it all
yourself.

 _Point being_ , its idiotic to say "Forget theory; ... Just set yourself a
project and start working." Cocoa and, perhaps to an even greater extent,
Cocoa Touch are hyper-complex frameworks that are made simple and
understandable _through_ the theory behind them. If you never learn the method
to the madness -- all the patterns and best-practices behind Cocoa and why
they're there -- all you will see is madness. You have very little hope of
grokking iPhone development by "just doing it".

~~~
wallflower
> If you're expecting a different language, framework, and platform to behave
> like a ruby, I would argue no amount of eschewing documentation and getting
> down to coding will help you.

I actually learned this lesson the hard way in the past week and basically
consult the iPhone SDK and Objective-C documentation constantly. Thanks.

For example, looking at NSViewController's documentation for loadView, pointed
out the fact that you should override this method if you want to do any
intialization (like initialize instances of custom classes you need to handle
controller interaction).

And yes - I did spend some time looking without results at NSString object
dumps before stumbling on the NSMutableString tip via google ( _and_ it would
have been much faster to have read the NSString documentation)

------
jemmons
I can top that!

How to write an iPhone app in ONE easy step:

1\. Write an iPhone app.

~~~
albertcardona
Reminds me of Matt Maroon's programming language: "clone eBay".

~~~
patio11
Bah, I _knew_ that guy on RentACoder was overcharging. $100 for one line of
code! Outrageous.

------
sqs
iPhone app development is _not_ , as many people make it out to be, the Gold
Rush. It's very easy to make a small amount of money ($10 a day), but making
$150 a day on the App Store is not any easier than making $150 a day doing
anything else (for somebody with the same skill level). And yes, there are
people making $21,000 a day, but those people exist in every business. We only
hear about the people striking it rich on the App Store because everything
Apple-related gets tons of attention.

I'm a bit torn, actually. I'm making good money on the App Store with 4-5
apps, but I don't learn much making iPhone apps compared to doing other kinds
of programming. So, I'm making a significant trade-off. (That said, I'm open
to doing iPhone contract development, so contact me if you're interested.)

------
jackowayed
_Specialist development hardware? None of it is necessary_

 _1\. Buy a Mac_

It may not be specialized to development, but it still is something special
you have to buy. And it pushes your lower bound for computer price up by a
lot.

------
jgfoot
I'd like to see a breakdown of how many apps never make the $100 back for the
developer (or $100+ if you bought a Mac just to write iPhone apps).

~~~
wallflower
I'm really not sure why we should always focus on the monetary value of taking
on a hobby. Por ejemplo, I have spent thousands over the past two years on
Salsa classes/lessons/DVDs/cover charges/one-beer-for-courage-drinks. Is it
worth it? Perhaps. I'll never be the best - but being above average is
sometimes achievable. A few pretty good dancers ask me to dance now.

Just being able to bang my head on Objective-C after a day with Flex or
something worse (requirements meetings) is worth it. It is something
different. Yes, there is the undeniable Gold Rush mentality, and my
expectations for selling an app will be realistic (e.g. sell it to someone you
don't know/are related to). It's about entertaining yourself intellectually.

~~~
jgfoot
I completely agree, but I will be more entertained intellectually by more
noble programming pursuits, such as continuing to study Haskell or assisting
on an open source project. The only reason for me to turn my back on my Linux
desktop, buy a Mac, and devote my energy to writing for a ridiculously closed
platform would be to make money. If am going to sell my soul, I want to know
what the price is upfront.

------
tocomment
Regarding the learn Objective C part, can anyone reccomend some good tutorials
on memory management? I still need some rules to follow regarding what to
release, what not to, how to release it, and when. Is there a simple model I
could keep in my head while programming so it all makes sense to me?

~~~
hboon
A. It uses reference counting. -retain (+1 now), -release (-1 now),
-autorelease (-1 later).

B. Creation/allocation is +1, thus: +alloc (+1), -copy (+1).

C. Your goal is to keep the count balanced at 0. If you do a +1, make sure you
do a -1 either now (-release) or later (-autorelease).

(C) is the guiding principle, thus in this order:

1\. If you +alloc/-copy something in a function and is done with it, make sure
you have a corresponding -release.

2\. If you +alloc/-copy something in a function and return it, -autorelease
before you return, so that counts are 0 (in the end anyway).

3\. If you didn't +alloc/-copy an object, (1) and (2) don't apply. E.g.
NSMutableString's +string.

4\. If you -retain, make sure you -release or -autorelease to pair it up.
(remember balanced to 0).

5\. If you get an object from calling another function, you shouldn't
-release/-autorelease it because someone else or you should have done (2). But
don't forget (4).

The rest is about memory management in accessors and IB outlets.

PS: I give up on formatting this. Hope it's readable.

------
chengmi
Ha! Generating a provisioning profile is more than eight steps(!) in itself.

------
breck
iShoot made $22k a day! Wow, I remember that game when it came out 10+ years
ago (it was called Scorched Earth back then). Time to go make a PacMan iPhone
app.

