Thanks!

I've been looking for a starting point for developing for my iPod Touch. AFAIK its a totally identical platform except for the phone and SMS elements of course - you can even run most iPhone applications on the iTouch including Maps which is awesome!

All I find when googling are a bunch of pages like that Wiki page you linked to, where there aren't any straight forward instructions, rather just a whole lot of wiki discussions from the multitude of people trying to get the toolchain working initially on their setups. Frustrating to say the least.

Now it would be great if you could do a 'part 2' covering the basics of GUI development. Given a lot of people will have no clue as to Macintosh style development at all. I come from a Windows API + Visual Basic + Visual C++ and lately the .NET environment, and this is totally foreign to me (Cocoa is a stupid name for a development kit!), it would be great to see some GUI basics, even if its only for the simplest of controls.

Thanks again!

For those who aren't so much into hardcore programming, you might also like to check out "Jiggy", which is a Javascript application development environment for the iPhone and iPod touch.

Once installed on your device, you can start programming real Springboard-driven applications in Javascript, with access to a variety of toolchains. Programming can be done through a web browser. It can allow those without so much proper-language experience a chance to make simple little applications for their own use.

http://www.jiggyapp.com/

sektah - Thanks for the heads-up. I've checked the website and it does indeed look very cool. Will be interesting to see how much of this stuff survives the 1.1.3 update.... <nervous laugh>

Dave

Hi Stu - thanks for the comment: I'm glad you liked the piece.

I'm planning a follow-on article which looks at how to build a small app using the classes in the UIKit framework. Just waiting for Apple to bring out the official SDK in case there are any huge changes.

ps: Cocoa is indeed an odd name for a development framework - nothing to do with chocolate. But then, I guess Java hasn't got much to do with coffee... ;-)

Dave

"Cocoa is indeed an odd name for a development framework - nothing to do with chocolate. But then, I guess Java hasn't got much to do with coffee... ;-)"

Though oddly enough Cocoa has a lot to do with Java. Cocoa is only named as such due to the Java bridge that existed from 10.0 to 10.4 (you can still write new apps but they don't offer any new features, though why you'd want to code in Java when you can use Obj-C I don't know). Though I don't really see how the name Cocoa is stupid for a development environment when you also have names like Swing, Rails etc. Half of names for products are a bit silly, the other half are boring ;)

I'm also interested to know how the GUI development will work. It would be pretty bad if Apple expected you to write code to generate your UIs. Do existing iPod/iPhone apps have NIB files? This could point to the use of Interface Builder for creating the UIs. Also, are you sure that they're using CoreFoundation, as that is the C based API. I was under the impression the iPod/iPhone used the bog standard Foundation.framework (which is the Obj-C layer built upon CoreFoundation) and replaced AppKit with UIKit on the GUI side

Firstly, yes you're right about CoreFoundation / Foundation. That was a typo: I was thinking about the layer kit and Core Animation while writing Foundation! As you say, iPhone apps primarily use Foundation and UIKit, although CoreFoundation is present, at least on 1.1.2.

The NIB thing is more interesting. I've pulled apart several iPhone apps, and not found a NIB yet. As far as I can tell, most apps hard-code the position of each UI element. Calculator, for example, has a method called [CalculatorController init] which laboriously lays out all the buttons used by the calculator in their hard-wired positions. This, I suspect, is the reason you can't just rotate your iPhone and get a landscape-oriented calculator. It's just a major hassle doing this once, let alone twice! Hopefully, the official SDK will have some sort of GUI design tool which lets you lay out a window graphically, and then at least spit out a chunk of Objective-C which you can then paste into your app. But then again, maybe we won't have that, at least initially....

So why no NIBs? I guess the short answer is reducing the code footprint. The business of bringing in a NIB, parsing it, auto-generating the various controls and then linking up the actions, etc, is a lot of code. Maybe in iPhone 2.0 ?

Dave