Hacker News new | past | comments | ask | show | jobs | submit login
The Complete Guide for Starting iPhone and iOS Development (withoutfriction.com)
225 points by withoutfriction on March 11, 2011 | hide | past | favorite | 49 comments



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!


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

Spring 2009-http://itunes.apple.com/us/itunes-u/iphone-application-progr...

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



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.


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.


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.


Where did you find the homework? I've downloaded all of the classes, and slides, but I wondered if I could find the assignments someplace. Of course, I'm assuming that you didn't actually take the course at Stanford...


These are some of the best tutorials around as long as you have the time to watch them and act like you are actually in the class. Greatly helped me while designing an iPhone app my senior year.


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?


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


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

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!


It should be noted that the Corona SDK uses Lua on top of Objective-C and is geared for Game apps. If you already have some Objective-C or C knowledge I'd recommend Cocos2d-iphone, which is nearly pure Objective-C, with a little pure C in the rough parts.

Going the Cocos2d route will also help you learn some of the peculiarities of the platform, like memory management and object lifecycle, while giving you enough skills to jump right into pure CocoaTouch.

Nothing against Corona, it has it's place. Bubble Ball[1] was developed with Corona for example.

[1] http://www.pcworld.com/article/216880/8th_graders_iphone_gam...


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 :)


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!


Amen to that! It's creating a killer app, by coding, which makes an app worthwhile enough where marketing and promotion almost become moot. I'm currently trying to update my own app after outsourcing most of the code. It's good, but I need other things that people want to talk about. That's what separates apps that sell, and those who don't.


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.


The nib is a data file - XML while developing, binary when shipping - that defines a bunch of views and how to connect them to a particular controller. That's it, that's all. You usually write the controller first, in code, and define certain "outlet" pointers in the interface of that controller.

Now in the nib you say "here are three buttons, connect them to outlets a, b, c." Now when Someone asks the controller for it's view it will create the views and connect the pointers in the manner you requested.

There is "magic" taking place, but no more so than the interaction between HTML and JavaScript in a web page. It may be unfamiliar at first, but not unfathomable.


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.


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.


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


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.


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.


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.


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.


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


Very helpful. Thanks!


This is what blew my mind when I actually understood what IB was doing in a class. It just made so much sense.


Serialization, marshaling, pickling...whatever your favorite terminology, that's all a nib is: archived object instances. If you don't have a mental model for that then you've got bigger problems than interface builder.


Personally, I don't agree with that.

I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on.

I suppose I could have gotten over those mental hurdles eventually, but I chose not to. I prefer thinking about objects that I make myself, and I avoid Interface Builder whenever possible.


Here's a pretty good overview of the various objects you mentioned: http://developer.apple.com/library/ios/#documentation/Cocoa/...

Even if you just wrap your head around File's Owner, you're 80% of the way there. Essentially, what it boils down to is this: it's a proxy object that gets set when NSBundle's loadNibNamed:owner:options: is called (which is called behind-the-scenes by UIViewController, which is where you'll usually be interacting with nibs). So, in Interface Builder, you change the class of File's Owner to whatever class should be managing the nib and it will give you access to all of that class's IBOutlets.

Like you, I prefer to create a lot of my UI programatically. But in a lot of cases it's just so much more efficient (from a time management perspective) to lay everything out in Interface Builder.


Wow. That's a lot of jargon for someone who's not seen iOS programming before.


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.


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


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


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


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


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


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.


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


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.


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.


What works for you may or may not work for someone else. I don't think I'm alone when I say that more quality resources on a subject is never a bad thing.


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.


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.


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.


Been doing iOS dev for a few years, friends with many others who have been doing the same. Sometimes things suck. But, not usually. How is this any different from relying on Google to "guarantee" a base minimum to dev against… that seems to be ignored by handset makers

All platforms have downsides.


"Good chance"? Come on.

In most of your cases it's pretty clear going into it how much risk you run of any of those things happening to you. And for most people that risk is almost 0.

And as others have already responded: there's always risk.


There's a greater chance that Apple won't block your app, but feature it instead, given that your app is GREAT. How about that?


Do you actually have an app currently on the app store? I've run into none of those problems. In fact, any time I have an issue with anything, they are very accomodating. Especially, expedient considering how many questions they get daily from developers. If it's as you say, what reason would there be to ever develop on their platform? It simply would make sense!




Consider applying for YC's first-ever Fall batch! Applications are open till Aug 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: