iPhone development emergency guide

http://mattgemmell.com/2009/07/14/iphone-development-emergency-guide

by sounddust • 17 years ago

100 23 17 years ago

mattgemmell.com

dejb4• 17 years ago

- You have to use a Mac to develop iPhone apps.

- You have to use Xcode as your IDE.

- You have to use the Objective-C language

- You have to manage your memory manually.

- You have to have a certificate in order to sign your code to make it work on a device.

- You have to pay a yearly fee ($99) to get the ability to create such a certificate.

- You’ll have to provide various pieces of information, and enter into a distribution contract with Apple.

- Apple has to approve your app before it goes onto the App Store.

Seems a little restrictive. Imagine the antitrust concerns this would bring up if the platform actually did become dominant.

tptacek2• 17 years ago

It's no more restrictive than any major game console.

dejb4• 17 years ago

Yes. Which is why I think it would be best to view the iPhone platform in a similar light as a game console. Cool and fun, but not something you would seriously be expecting to be the basis of the next wave of personal computing.

TJensen2• 17 years ago

I use Emacs and Make as my IDE (yes, it does call xcode to do the actual compile). There is at least one Ruby and one Javascript compiler you can use.

smikhanov• 17 years ago

Could you please give a little bit more info on how do you do this (and links to Ruby/JS compilers)?

cdr• 17 years ago

Not all of those are strictly true, either.

jlongster• 17 years ago

You don't have to use Objective-C, and you are free to use a language with a garbage collector:

http://jlongster.com/blog/2009/06/17/write-apps-iphone-schem...

jsonscripter• 17 years ago

You still have to have C in the end. The license agreement forces it upon you. That's disgusting.

concretecode• 17 years ago

I'd like to see more of this type of thing. When learning a new language, I don't need an introduction to the if statement or while loops, yet in the interests of completeness many programming books include a thorough (and mind-numbing) guide to them. For some readers that's called for, but many of us are stuck reading about concepts we're already comfortable with. I'm concerned that if I don't read everything, I'll miss out of some bizarre quirk of the language, so I'm reluctant to skim, but this gets in the way of what I'm really trying to achieve - using the language to make cool stuff.

Writers of programming language books take note: I'm generally not interested in the tool. Tools are boring. No really, they are. Making cool stuff and solving hard problems is interesting and fun. Get the tool out of the way so I can get things done.

tptacek2• 17 years ago

Agreed. I wrote a couple-page cheat sheet on Objective C, and since I've made a twice-yearly ritual out of forgetting Objective C, it's come in handy. Repeatedly.

mcav• 17 years ago

If you ever have time or inclination to share it, I could use a good cheat sheet. The closest I have now is "Objective C for C++ programmers", but it's not short enough to be a useful cheat sheet.

einarvollset2• 17 years ago

"The equivalent to Java’s this is pretty much self."

Well no, the difference (inside a class) of:

this.foo = myshinyobject

and

foo = myshinyobject

is nothing in Java. In Objective-C,

self.foo = myshinyobject

and

foo = myshinyobject

are different. Particularly with regards to the @property (retain) magic; if you forget self.foo and use foo, then myshinyobject might get garbage collected. Which is not what you'd expect with a retained property.

tumult• 17 years ago

Well, on iPhone, it would get deallocated with the next pool drain, not garbage collected (since garbage collection does not exist for iPhone as of now.)

foo = myshinyobject is ok if you use instantiate it like [[SomeClassThing alloc] initetc] rather than one of the convenience methods like [SomeClassThing thing] since those are supposed to be returned with a retain count of 0.

I forgot what I was getting at.

einarvollset2• 17 years ago

Well, sort of.

If you do an alloc/init, then you need to release it (or you leak). If you're assigning to self.foo, then you can just release the thing you created after assigning it. If you assigned it to foo, and then release it, then you're in the position I mentioned above.

igorgue• 17 years ago

Too many "have to", you guys know that you can use Mono to develop iPhone apps?

iPhone development emergency guide

Related Stories