Hands on I'll admit it. I'm an unashamed fan of the iPhone. I had an unlocked device in the UK running on my cheapskate Vodafone tariff before November's official launch.
From a developer perspective my real interest is in being able to create native iPhone applications. I emphasize native. There's plenty of information around on how to build web-based applications, but I'm talking about native-code executables.
Apple is expected to release an iPhone SDK after this week's Macworld, San Francisco, California, but until then, we have to resort to experimentation that's not officially sanctioned by Apple and relying on knowledge you've gleaned from iPhone-related sites.
In lieu of the full SDK and an open environment, I've taken a look at the first steps you can take building and deploying a native iPhone application.
Under the hood
The Mac has two principal class libraries - Foundation and AppKit. Authored in Objective-C (for the most part) these provide the architectural bedrock on which Cocoa programming is done. On the iPhone, the counterpart libraries are called CoreFoundation and UIKit. There are, in fact, a whole slew of other frameworks present on both platforms. This includes the recently introduced LayerKit.framework, also known as Core Animation on Leopard. In fact the UIView class - the equivalent of NSView - has layer support built right into it.
Before you can start creating iPhone applications, you need an appropriate toolchain. If you're not familiar with the concept, suffice to say that a toolchain encompasses the compiler, linker, assembler, header files, and the static and shared libraries needed to build an executable for a particular platform. The unofficial iPhone toolchain is based around the GNU tools, and it's a certainty that whatever Apple come ups with, the same will be true there. This is because Apple's development tools already use the GNU stuff.
You can configure xCode for iPhone development but I decided against that. Instead, I used the Cygwin tools; a Linux-style environment, based around the GNU toolset, but running under Windows. This might seem an eclectic way of doing things, but there's method in my madness.