
The Complete Guide for Starting iPhone and iOS Development - withoutfriction
http://writings.withoutfriction.com/the-complete-guide-for-starting-iphone-and-io
======
flyosity
I wrote Building iOS Apps From Scratch (<http://designthencode.com/scratch>) a
30-page guide for coders just learning Objective-C and Cocoa. Also, for coders
looking to get into UI design, I wrote a 70-page guide as well:
<http://designthencode.com>

Hope it helps!

------
stevederico
The Stanford iTunes U Courses should not be overlooked. They do a great job of
taking you from crawling to running in no time. I enjoyed doing the homework
too, it really increased my learning experience.

Winter 2010- [http://itunes.apple.com/us/itunes-u/iphone-application-
devel...](http://itunes.apple.com/us/itunes-u/iphone-application-
development/id384233225)

Spring 2009-[http://itunes.apple.com/us/itunes-u/iphone-application-
progr...](http://itunes.apple.com/us/itunes-u/iphone-application-
programming/id384233222)

Spring 2011 (Starting Soon)-<http://www.stanford.edu/class/cs193p/cgi-
bin/drupal/>

~~~
rimantas
I think you missed the best one—Fall 2010
[http://itunes.apple.com/itunes-u/developing-apps-for-ios-
hd/...](http://itunes.apple.com/itunes-u/developing-apps-for-ios-
hd/id395605774) Downloads: [http://www.stanford.edu/class/cs193p/cgi-
bin/drupal/download...](http://www.stanford.edu/class/cs193p/cgi-
bin/drupal/downloads-2010-fall)

~~~
Timothee
Why is the one better than the other one?

I've followed parts of CS193P twice (can't remember which one) and both were
pretty good. If this one is really better, I wouldn't like to miss it… :)

Oh I can not say enough good things about that class. Great teachers, great
material.

~~~
totalforge
Winter 2010, taught by Paul Hegarty, is the best introduction I've found. I
have some books, I've watched some Apple videos, but I was still confused. Mr.
Hegarty really explains things the right way. Highly recommended.

~~~
rimantas
I guess you mean the same as me: Fall 2010? These names a tricky, Fall 2010 is
really Fall-Winter 2010, and comes _after_ winter 2010 which was winter-
spring. What Stanford calls "Winter 2010" was taught by Alan Cannistraro and
Josh Shaffer, and what I reffered to as Fall 2010 was indeed by Paul Hegarty.

------
kingofspain
It should be noted you don't _need_ a Mac. I've had 2 apps developed,
submitted and approved from my makeshift vmware player running on W7. I know
others who use Virtual Box. Never ran into any trouble other than wondering
why all the keys behave differently!

Yes, it's technically illegal but isn't that the best kind of illegal?

~~~
withoutfriction
I did add a point about using a Hackintosh, though it is good that you
mentioned about using a VM image of OSX.

------
marksu
Yes – programming is fun to hop into, but just a heads up: the most difficult
process to learn and master is the marketing and promotion part of releasing
an app.

I feel that two blog posts linked in this article touches this subject in an
interesting way: <http://struct.ca/2010/the-story-so-far/> and
[http://blog.endloop.ca/blog/2010/08/12/100k-in-4-months-a-
ni...](http://blog.endloop.ca/blog/2010/08/12/100k-in-4-months-a-niche-apps-
path-to-app-store-success/)

That said, I would recommend Corona - <http://www.anscamobile.com/corona/> \-
for anyone wanting to give iPhone app development a shot. Much easier and fun
to jump into than objective-c, especially if you want to make games, and still
pretty damn powerful!

~~~
transmit101
Really not sure I agree with that. Coding is tough, and in my experience
developing iOS apps _well_ (and Cocoa apps in general to a lesser extent) is
one of the most difficult forms of programming.

And as for marketing and promotion, I'd say even more challenging is coming up
with an idea which doesn't need marketing or promotion :)

~~~
marksu
Yes, fair enough – I basically agree. Just posted that comment as some food
for thought. I think this link was a good read, but perhaps should mention the
marketing part of app production as well, if not just coding for coding's sake
is the purpose. The reality is not really "you build it and they will come",
which is a common mindset that might get people disappointed in the long run.

And yes – the biggest challenge is probably coming up with something original!

------
drpancake
Coming from Python, web development and Android, I found interface Builder to
be the trickiest part of iOS to learn. The way it instantiates some of your
classes requires you to build up a really odd mental model; I still don't
fully understand it after a couple of months.

You're welcome to do it all in code, but it seems to be discouraged by many.

~~~
program
Model View Controller is an odd mental model? It's quite popular right now and
I think that it's the best pattern for decoupling user interfaces from the
underlying code.

~~~
drpancake
MVC is fine. It's the way that your controllers are instantiated by a NIB that
I find odd. It's too magical for me.

~~~
cpr
It's exactly the opposite of magical: you're simply building objects in IB
that are "live" while you're building them and that then are freeze-dried when
you save the file, and reconstituted at runtime.

It's certainly magical in the sense that it's a beautiful way to do things.
;-)

~~~
mckoss
I prefer a programming model that is not so complicated that you need an IDE
to generate the code for you. Even watching the Apple tutorials on using XCode
I was struck by how many magic incantations you have to kearn that seem
totally opaque and unmotivated (just hold down command and drag this thing on
top of that thing and set this property in the pop up - what?).

I think simple programs should be able to be expressed in one file and created
in a simple text editor.

~~~
cpr
You're missing the point: no code is being generated. Objects are being
generated. The real objects you'll have at runtime are being generated. The
real objects that will be freeze-dried to a file and reconstituted at runtime.

You're saving creating the hundreds of lines of codes that would be required
to do this in a "normal" IDE.

~~~
mckoss
_no code is being generated_

This seems a patently false statement. I would count as _code_ any
representation of procedural or configuration information that could be
interpreted or executed in the running of an application.

If the underlying systems requires _hundreds of lines_ to represent a simple
object (like a button, panel, or toolbar), then maybe as a programming
environment designer, you should go back and simplify your underlying
representation, rather than add a layer of UI to generate hundreds of lines of
code.

~~~
neild
Cocoa doesn't require hundreds of lines to represent a simple object. Here's
code to make a button:

    
    
        UIButton *button = [UIButton buttonWithType:UIButtonTypeRoundedRect];
        [button setTitle:@"Button" forState:UIControlStateNormal];
    

That's it. Two lines for a basic button.

Of course, if you want to display the button:

    
    
        button.frame = CGRectMake(10, 10, 80, 20);
        [view addSubview:button];
    

...which is a big part of why Interface Builder is handy, because it saves you
from trying to figure out exactly how large you want the button to be and
where to put it.

Now, when you put together all the objects in a moderately complicated UI, you
will end up with hundreds of lines of code. Some people find it easier to work
with this visually in Interface Builder. Others find it easier to manually
construct the UI in code. Either method works perfectly well. I generally use
a mix of both, depending on the nature of the UI element I'm working with.

~~~
wallflower
> Some people find it easier to work with this visually in Interface Builder.

All of our designers use IB to layout the UI. It works really well - as they
don't have to touch the code and we don't have to touch the layout.

Unfortunately, if you are doing any kind of custom animation (think
sliding/expanding), IB is useless - you'll have to set the frames in code.

In general, IB is great because it helps separate presentation from the code.

When I first started out, I hated IB, but I've come to accept the fact that it
really does help productivity (when working with designers closely). If you
hate IB, consider going Android - there is nothing like IB on Android. All XML
and a simple (nothing like IB) layout editor.

------
Breefield
This is great! I just started going through Programming in Objective-C 2.0,
although I'm not new to programming at all, I am pretty new to C/Obj-C. Good
to see it in this guide, reaffirms that it's a good starting place.

------
xsltuser2010
Is there a similar resource for Android ? I don't currently own one, but this
kind of writeup would be helpful to estimate the effort to get into developing
first things for it..

~~~
withoutfriction
If this guide stays popular on HN for a bit, I will strongly consider (read:
will) research it and write one up.

~~~
xsltuser2010
Oh that's nice. Looking forward to reading it.

------
bricestacey
This is just a bunch of links. Can anyone vouch for the author's credibility?

~~~
jtheory
Are you talking about the linked article, or HN in general? ;)

------
philthy
For anyone who wants to fiddle with development and doesn't know any form of
C, a company called Revolution Media makes a scripting tool called LiveCode.
It is pretty easy to use but I'm not sure how advanced your apps can get.

------
callmeed
I wouldn't call this a "complete guide" ... seems more like pre-reqs.

------
mkramlich
The Apple docs already explain this pretty well. Not too hard. It's weird we
live in a world of hand-holding comfort and plentiful documentation on almost
everything and yet we still create more.

~~~
jodrellblank
_Not too hard._

That's a tautologically pointless thing to say.

 _It's weird we live in a world of hand-holding comfort and plentiful
documentation on almost everything and yet we still create more._

How terrible we are for wanting a world of comfort instead of superior
discomfort and confusion.

------
guelo
The fine print for new iOS devs:

If you succeed in overcoming all of the obstacles ahead of you and actually
create a worthwhile app on Apple's platform their is a good chance they will
screw you over without warning or explanation by blocking your app, yanking
your app, changing the rules, calling you a pornographer, randomly charging
you new fees, prohibiting whatever it is your app does, changing the hardware
you're allowed to use, changing the software you're allowed to use, and many
other ways that seem impossibly outrageous right now until it actually
happens.

Invest your time and money at your own risk. You've been warned.

~~~
cmaggard
Man, there's all these things standing in the way of success! I'd better not
even try.

Come on, seriously? There's risk involved in pretty much every venture, and
you can't exactly control the actions of outside entities. If I kept avoiding
tasks because there was a chance of it being screwed over by someone else, I'd
never get anything done.

~~~
prodigal_erik
This risk can't be mitigated. One guy wakes up on the wrong side of the bed
and bam, 99% of potential customers (everyone who doesn't have a jailbreak,
assuming that remains possible) are out of your reach for no real reason.
Every developer needs to be aware that Apple bargains like Darth Vader.

