iPhone development emergency guide • Hacker News Board

Re: iPhone development emergency guide

#11

Post by dejb » Wed, Jul 22, 2009, 7:34 AM UTC

tptacek wrote: post #4

dejb wrote: post #2

- 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 d…

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

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.

Re: iPhone development emergency guide

#12

Post by smikhanov » Wed, Jul 22, 2009, 10:34 AM UTC

TJensen wrote: post #7

dejb wrote: post #2

- 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 d…

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.

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

Re: iPhone development emergency guide

#13

Post by tumult » Wed, Jul 22, 2009, 12:51 PM UTC

einarvollset wrote: post #9

"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…

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.

Re: iPhone development emergency guide

#14

Post by igorgue » Wed, Jul 22, 2009, 1:43 PM UTC

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

Re: iPhone development emergency guide

#15

Post by jlongster » Wed, Jul 22, 2009, 2:37 PM UTC

dejb wrote: post #2

- 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 d…

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

Re: iPhone development emergency guide

#16

Post by roc » Wed, Jul 22, 2009, 2:37 PM UTC

dejb wrote: post #11

tptacek wrote: post #4

Earlier quoted context omitted.

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

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.

Actually, I think the iPhone's success has practically guaranteed the next wave of personal computing will follow the console model.

It's easier for the user, the development community is willing and it offers larger returns for the platform creator.

Besides, most of the guts of personal computing are being done via protocols and services; platform lock-in isn't really done on the device anymore.

Re: iPhone development emergency guide

#17

Post by einarvollset » Wed, Jul 22, 2009, 3:22 PM UTC

tumult wrote: post #13

einarvollset wrote: post #9

"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…

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.

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.

Re: iPhone development emergency guide

#18

Post by dejb » Wed, Jul 22, 2009, 3:27 PM UTC

roc wrote: post #16

dejb wrote: post #11

Earlier quoted context omitted.

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.

Actually, I think the iPhone's success has practically guaranteed the next wave of personal computing will follow the console model. It's easier for the user, the development community is willing and it offers larger returns for the platform creator. Besides, most of the guts of personal computing are being done via protocols and services; platform lock-in isn't really done on the device anymore.

That would truly be a sad future, worse than the '1984' scenario being played out by Amazon's DRM. What free person would want to rely on a device that required the manufacturers constant consent to allow it to function as that they wanted? Thankfully this seems unlikely. History suggests that there is a significant benefit in choice and freedom and that consumers will eventually follow that path.

> It's easier for the user, the development community is willing and it offers larger returns for the platform creator.

So the lock-in is powerful and effective?

> Besides, most of the guts of personal computing are being done via protocols and services; platform lock-in isn't really done on the device anymore.

So the lock-in doesn't really matter?

Which is it? You can't have it both ways. The answer is that the lock-in acts like friction, wasting value instead of providing returns for participants in the system.

Re: iPhone development emergency guide

#19

Post by jsonscripter » Wed, Jul 22, 2009, 3:40 PM UTC

jlongster wrote: post #15

dejb wrote: post #2

- 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 d…

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

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

Re: iPhone development emergency guide

#20

Post by jcl » Wed, Jul 22, 2009, 3:41 PM UTC

dejb wrote: post #18

roc wrote: post #16

Earlier quoted context omitted.

Actually, I think the iPhone's success has practically guaranteed the next wave of personal computing will follow the console model. It's easier for the user, the development community is willing and it offers larger returns for the platform creator. Besides, most of the guts of personal computing are being done via protocols and services; platform lock-in isn't really done on the device anymore.

That would truly be a sad future, worse than the '1984' scenario being played out by Amazon's DRM. What free person would want to rely on a device that required the manufacturers constant consent to allow it to function as that they wanted? Thankfully this seems unlikely. History suggests that there is a significant benefit in choice and freedom and that consumers will eventually follow that path. > It's easier for t…

The important thing is not the lock-in, and probably not even the pre-screening of applications. The important thing is the streamlining of getting software and updates to the user.

If centralized software distribution scares you, be afraid of Ubuntu.