If you want to find out how your software will run under 1.1.3 and the SDK, I recommend you test it out under 1.1.2 or 1.1.1 as user "mobile". First, consider where all your resources will be located (in /var/mobile rather than /var/root). Next, start thinking from a ~mobile perspective. Issue a "sudo - mobile" from the command line and...

With iTunes now shipping the first ever iPod touch application (the property list that unlocks the built-in applications and 1.1.3 firmware features), I thought I might take the opportunity to describe the way an iPhone application works. If you're familiar with Macintosh application bundles, you'll find that the iPhone application is similar...yet different.

If you've done iPhone command-line programming, you've probably run into the dreaded Purple app errors. The iPhone complains that it couldn't register with the bootstrap server. This happens when the iPhone attempts to run more than one Purple application from the command line.

Given that the iPhone is all but undocumented at the moment with the SDK not promised until February, I find that it often helps to add the following code to my classes. It allows me to see what methods are being invoked and create those as needed.

No, not Disco, Disc. Disc is dead. The existing iTunes movies and video model may be flawed but digital distribution is the way of the future. If the rumor mill is right, tomorrow Apple will reinvent this space

I'm frequently asked these days about what I expect the upcoming Software Development Kit to look like. The answer is, of course, that I haven't a clue--I have no insider information beyond whatever we'll find out on Tuesday. So here are a few of my guesses, pulled directly from nowhere in particular, which will probably be confirmed or corrected in the upcoming keynote.

Although you do not need to create an application package for purple applications, they work best when added into a properly formatted .app bundle and placed into an iPhone or iPod touch's /Applications folder

You'd think that NSLog would write to stderr, right? Right? Um, no. At least not on the iPhone. This morning I spent way too much time trying to figure out why my freopen([logPath fileSystemRepresentation], "a", stderr); line wasn't working and redirecting NSLog output to my log file.

If you suddenly find that your ftp listings no longer work right, and the BLasted-UnnamEd-HOSTing service won't take responsibility for fixing httpd.conf, you can fix things by adding the variable definitions to .htaccess files yourself.

I'm not saying that I'm an elitist Applecentric snob, no wait, yes, i am. And a lot of the UI decisions made me roll my eyes. The five screens before you can play any game, the mismatched dialog boxes without consistent font usage, the fact that you must pay 5 bucks for a Web browser, the fact that there doesn't seem to be easy third party development for an Internet-savvy device.