Go native with iPhone development
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.
Chances are that when the official SDK is released it will need a reasonably virginal xCode setup to work with and I didn't want to mess up my existing system, which I use for regular Mac development. Conveniently, I use VMWare Fusion to run Windows XP under Leopard. It's dead easy to set up - a set of instructions can be found here.
You'll also need the xCode 2.5 Developer Tools disk to extract a file called Archive.pax.gz. This contains important Apple header files that will form part of the toolchain.
It is possible to "get at" this file from Windows, but it's much easier with a Mac. You mount the DMG, go to the \Packages\Packages directory, and when you find MacOSX10.4.Universal.pkg, right-click and choose "Show Package Contents" to drill down further.
You'll also need to install the iPhone root file system as part of the toolchain. Again, this is explained in the weblink. It's easiest doing this via a wireless connection to iPhone where you've installed the sshd daemon.
Installation the iPhone
Assuming you've installed the Cygwin toolchain - or other preferred option - you're ready to try building an iPhone application. Here again, there are plenty of examples around to get you started. The simplest thing is to download the inevitably named "Hello World" project and try building it. An example can be found here.
The exact details will depend on the precise toolchain you're working with. Once you've built the application (in my case by typing "make" from the Cygwin prompt within the project directory) you should end up with a file called Hello that is the actual ARM executable.
If you know much about Mac programming - and you'll certainly need to know something, if you're getting into iPhone development - you'll appreciate that Mac applications are made of bundles. You can find more on this here.
For consistency, you should deploy your application as a bundle. Create a folder called Hello.app and move the executable inside. You'll also need to copy the Info.plist file into the folder. It's important that the CFBundleIdentifier field inside this file is set to the program name, in this case "Hello".
There are various ways of getting the application bundle across to your iPhone. I use a freeware Secure FTP (SFTP) client called Cyberduck but you could do the same job with - for example - a command-line SSL connection from a PC or Mac. Place your application bundle into the /Applications directory on the iPhone.
There's one other important step: before launching the application, set the execute bit on the executable itself, not on the bundle folder. From the command line - there's even a tiny terminal emulator for the iPhone - you'd just type "chmod +x Hello". Cyberduck has a GUI interface for doing this.
If you now go to Springboard - the iPhone's icon-based Finder application - you'll hopefully see the icon for your new application. Click it and with any luck, you'll see the Hello World application in all its glory.
There are a couple more things you should know. Firstly, to get Springboard to display a nice custom icon for your application, place a 60x60 pixel image, icon.png, in your application bundle. Restart Springboard, and it should appear.
Finally, you'll notice that when your program starts, you momentarily see an unpleasant, blurred image similar to the OS X default application icon. This is Springboard's way of saying: "You need a Default.png file!"
Whenever Springboard launches an application, it looks for this inside the application's bundle. If found, the image is slapped onto the iPhone screen before the new application starts to run. It feels as if the application starts much faster than it actually did, because the expected program background appears almost immediately. Sneaky, huh?
To exploit this feature, create an image (320x460 pixels) appropriate for your application, name it Default.png and place it in your bundle. If you simply want to disable the blurred default image, even a one pixel high, one pixel wide image will suffice.
Wrapping It up
That is iPhone development at its simplest. What I haven't covered, of course, is the nitty gritty of building a native iPhone application. Coming ahead of full tooling and a properly supported, Apple-backed development environment, though, this should give you the basics and get you thinking.®