As posting code on the blog can sometimes can get very cluttered, we have just set up a GitHub account for TUAW to make everything better and easier for everyone. This is where you'll be able to find code for our developer-related posts. We'll try to get some projects hosted in there very soon, so don't worry that it's empty now! If you haven't heard of it, GitHub is a hosting site for git revisions, which makes it a great place to host and interact with code of all kinds.

You can find our profile at http://github.com/tuaw today. What would you like to see on TUAW for iPhone/Mac development? Let us know in the comments below!

Oh, computers. Every time we think we've figured you out, you come up with another number-related disaster for us to fear. This time around, it's the Twitpocalypse -- apparently Twitter decided to use a unique identifier in their API for each separate tweet that goes out, and come sometime this weekend, the number will reach 2,147,483,647 and keep going. Which just happens to be too much for the variable that holds it, and that means that many of your favorite external Twitter clients, from Tweetie to Twitterific, to all of the other magic Twitter apps out there, could go down in a ball of numerically-ignited flame.

The good news is that just like the Year 2K panic, this one is more or less unfounded. We've already spoken to our friend Ged Maheux of Twitterrific, and he says that the problem has already been fixed in the latest version of the software. We'd imagine that most of the really big Twitter apps have already addressed the issue, and taken care to make sure they'll still work (either that, or they'll get on it ASAP). Plus, a Twitter outage wouldn't really be anything that might cause riots in the streets (or different from the usual downtime, actually -- rimshot!).

But it is funny and strange that as long as we have people who can't foresee the future (so, all of us) programming computers, we'll keep running into problems like this. If your favorite Twitter client goes out on Saturday, just find a basement to stay in, stock up on shotgun shells and water, and put your head between your legs -- help is on the way soon.

It's a good day to become an iPhone developer: in addition to the screencast we mentioned, someone near and dear to us at TUAW finally got her book out into the wild ... at least the PDF version. Erica Sadun's* "The iPhone Developer's Cookbook" is available as an electronic download from informIT.

If you want to dig in and start developing native iPhone applications with the SDK, this is a great way to start. The paper version is set for release on October 15th, if that's what you're into, but having the code samples in a cut-and-paste-friendly format is far preferable to me. Coupling that with a complete lack of patience, I bought the PDF this morning and am avidly poring over it for new information.

I'm planning a combination tip calculator/grocery list application with several language translation apps and an ebook reader built in ... although I may consider doing a Pinocchio app that lets people know when I'm joking instead.

So, up-and-coming iPhone developers, head on over to informIT for some SDK development goodness.

Editor's Note: Since Erica has moved on from TUAW to her new home at Ars Technica, we no longer have conflict-of-interest concerns about reviewing her books -- but we still love her & wish her all the best.

Update: Code samples are available here!

Here's a clever utility from the creator of Quicksilver. Secrets (no, not the Van Halen song) is a preference pane that lets you fiddle with the hidden defaults of nearly all your applications. For instance, show the iPhoto toobar in full screen mode and make those iTunes arrows link to your library instead of the store.

There's a huge database available, and adding your own secret preferences is simple. Have fun!

[Via Daring Fireball]

One more reason why we can't wait for the iPhone SDK to drop. GameSetWatch has a short interview up with developer Steve D of Demiforce about his new iPhone game, Trism. It's a Bejeweled-like gem matching puzzle game, but the twist is that after getting matched, the gems fall in the direction that the iPhone's accelerometer tells them to fall. It's wild stuff, and you can see it clearly in the video above.

He's playing the game on a jailbroken iPhone, but it's still a work in progress, so the game isn't available to the public yet. Depending on the terms of the iPhone SDK, he's looking at porting it over to that and releasing it via whatever distribution system Apple comes up with. And he cooked this thing up in about ten days (he wanted to rush it to show it off at GDC last week), so if Apple is able to include smaller developers like Steve in their SDK setup, we'll see some terrific software come off the line in no time at all.

TUAW Reader scw wrote in asking if I could put together the headers for the 1.1.2 Frameworks in a downloadable format. Scw, your wish is our...um...command Number 1 Priority request. I took out some time and zipped up a complete 1.1.2 header bundle for you. TUAW hopes this helps you update your files for 1.1.2.

Listen up, iPhone coders, NSBundle is your friend. It lets you look in your main .app bundle and retrieve files without hardcoding paths. Avoid "/Application/MyProg.app/foo.png" and replace your absolute references with relative ones. This lets your users install your applications wherever they wish.

An NSBundle object locates your app in the local file system so you can access resources and use them in your programs. [NSBundle mainBundle] returns the object for your app. When you use the pathForResource: ofType: inDirectory: method, you can easily find the path to those resources. For example, to find the Default.png file in the top level of an iPhone or iPod touch application, use: [[NSBundle mainBundle] pathForResource:@"Default" ofType:@"png" inDirectory:@""]]. Couldn't be simpler.

Skip the type argument (use @"") for resources without extensions.

A few weeks ago, our Mike Rose posted about my 1.1.1 iPhone header documentation. I'm pleased to say that after a huge amount of work, I've updated those docs up to version 1.1.2. The new documents cover all the Objective-C headers for the iPhone and iPod touch 1.1.2 frameworks including updated keyboards and other system-level modifications. If you're wondering about "Oktoberfest", despite the November release date, that's the Apple internal name for the user bundle. Previous bundles included "Heavenly" (1.0.2) and "Snowbird" (1.1.1).

Man, I wish this Bonjour class wrapper had been around a few weeks ago. The CFBonjour Cocoa class simplifies mDNS/Bonjour programming for the iPhone and iPod touch. iPhone developer Ecume pointed me towards this simple class that allows you to publish and subscribe to Bonjour network services with a minimum of programming. He's using this code to write a DropCopy client for iPhone. Hopefully this new step forward will make it a lot easier for more developers to get on the iPhone/Bonjour wagon--the opportunities go far beyond Zune-like file sharing. (Speaking of Zune-like sharing, my new version of SendSong allows you to squirt your music to anyone using SendFile.)

Thanks to Ecume.

Why settle for out-of-date toolchains when you can build the latest and greatest from scratch. Nicholas "Drudge" Penree put together this handy how-to that walks you through the process.

Be aware that you'll need to be running the gold master version of Leopard with the latest XCode release. These instructions do not work on the prerelease developer builds.

For more information and for peer support, head on over to irc.osx86.hu to the #iphone-dev and #iphone-uikit channels.

Looking to compile software for the iPhone and iPod touch under Leopard? There are two approaches: You can download the latest toolchain svn from Google Code or you can use a legacy toolchain installer that just happens to work under Leopard.

Last night, Nicholas "Drudge" Penree pointed me towards a copy of Elliot Kroo's legacy 0.04 toolchain installer. This installer dates back to the "bad old days" of arm-apple-darwin-cc, before the better gcc version appeared. On the other hand, a working solution is a working solution so I'm not complaining.

After downloading, I mounted the disk image, ran the installer and then the "ooh shiny" program. To make this work, I had to install a copy of the iPhone disk as /usr/local/arm-apple-darwin/heavenly. There are various methods for getting a copy of your 1.1.1 disk floating around the net up to and including decrypting the install dmg from Apple. Google for details if you're unsure how to do this.

Next, since this is a VERY legacy install, I had to edit my .arm-cc-specs and fuss with them until they matched my system.

Finally, I grabbed a copy of my old libarmfp.dylib file and put everywhere I could think of until I got some existing projects to compile. I believe my final places to put it were /usr/local/arm-apple-darwin/heavenly/usr/lib/ and /usr/local/local.toolchain/heavenly/usr/lib but you'll have to hunt around on your own system to see where it fits. You'll be looking to put it in the same folder that has the working gcc_s_v6.1 library.

After this, I ended up with a working--albeit legacy--toolchain running under Leopard. I'll download and compile the new toolchain at some point but this gives me some much-appreciated breathing space before I need to do that.

You don't need to use a lot of fancy routines to subscribe to data generated by the iPhone's built in accelerometer. A single UIApplication delegate lets you know whenever the iPhone has updated its tilt data.

When you add a method for (void)acceleratedInX:(float)xx Y:(float)yy Z:(float)zz to any UIApplication, the iPhone sends regular messages to your application giving you values for X, Y, and Z. These values are not exactly what I first expected:

X = Roll X corresponds to roll, or rotation around the axis that runs from your home button to your earpiece. Values vary from 0.5 (rolled all the way to the left) to -0.5 (rolled all the way to the right).

Y = Pitch. Place your iPhone on the table and mentally draw a horizontal line about half-way down the screen. That's the axis around which the Y value rotates. Values go from 0.5 (the headphone jack straight down) to -0.5 (the headphone jack straight up).

Z = Face up/face down. I expected the Z value to correspond to yaw. And it does not. It refers to whether your iPhone is face up (-0.5) or face down (0.5). When placed on it side, either the side with the volume controls and ringer switch, or the side directly opposite, the Z value equates to 0.0.

The barriers to iPhone-to-iPhone communication are quickly dropping away. Yesterday I put together a push-to-talk developer pack in the spirit of "just add water", or in this case, "just add point-to-point data transfer". It includes a sample app and code for recording and playing back audio as well as a record-time limiter that will override any push behavior if a message goes on for too long.

What it needs is the inter-iPhone technology. I throw this kit into the wild. Let's see what comes back.

In terms of application development, the iPhone's UISlider is pretty standard. It works like nearly every other slider you've ever programmed. It offers a drag-able thumb control that moves between a minimum and maximum value. As its dragged, the slider produces events that you can redirect to your main application.

Multitouch is all the rage lately, but one of the drawbacks is that it's still pretty expensive. Enter this ingenious device-- it's a bag with dye colored water in it. That bag is then laid flat on a glass table, an iSight camera is placed underneath, the computer is coded (it appears, anyway) to look for fingertips pressing through the dye, and just like that, you've got a multitouch interface.

Really incredible. Of course, it's hard to figure out how this could be used for something like the iPhone-- instead of a camera, you'd have to have some kind of light sensors behind the dye, and you'd have to figure out a way to have the dye-colored water stay spread even throughout the bag. In fact, come to think of it, I'm not really sure how most multitouch interfaces work-- maybe this is closer to the real thing than I imagine. Even if not, very cool idea, and I'm almost surprised to see it really works so well.

[via Waxy]

Update: Looks like the video is a little old-- this was posted back in early June, even before the iPhone was released. But it is still really cool, and it's the first I've seen it.