Last week, TUAW showed you how to sign iPhone applications for informal developer-to-developer distribution. That approach lets you share applications between members of the iPhone developer program by using your signing credentials to authorize the application for use on your development units.

iPhone applications compiled for the Intel-based simulator can also be shared between developers. And, since the free developer program offers access to the simulator, the apps can be distributed even more widely than with the re-signing approach.

Simulator testing does not offer the full suite of device-specific capabilities. You cannot simulate the onboard camera or retrieve proper accelerometer feedback. The simulator does not vibrate or provide general multitouch input. (You can pinch, but that's about it.)

The strength of simulator-based distribution is that it lets you send out applications for early testing and feedback. Sim-only tests strengthen the preliminary design process; this approach helps solicit feedback on user interface and general program layout before the main development push gets underway.

Simulator-based apps are easy to transfer and easy to use, cutting out a layer of overhead that's needed for when you go to a full ad-hoc beta.

To distribute a simulator application, go to the Library/Application Support/iPhone Simulator/User/Applications/ folder in your home directory. There you'll find the application sandbox folders that are currently installed for your simulator. Each folder is named with a unique id (i.e. 56E66CE5...DC028F) that does not reflect the folder's contents.

You'll have to peek inside to determine which folder is which.The folder contains the application, and three sandbox directories: tmp, Library, and Documents.

To share a simulator folder compiled for 2.2.1 and earlier, you must zip up both the folder with the application and the .sb (sandbox) file that shares the same name as the folder. 3.0 and later applications do not use a .sb file. Just zip up and share the folder.

Install the shared app by decompressing its sandbox folder (and, for 2.x, its .sb file). The recipient must have installed the iPhone SDK. Drop it into the simulator's Applications folder on another machine and launch the simulator. The app should appear in the simulator, ready for testing.

At times, iPhone developers might like to test out applications without going through the formality (or challenges) of ad hoc distribution. Ad hoc distribution was introduced by Apple to allow software testing on up to 100 registered devices. It is, admittedly, a bit of a pain.

Developers must collect device information (the "UDID", aka their unique device identifiers), register that device at the iPhone developer portal, create an special provisioning certificate, add a special entitlement, and build an ad-hoc only version of their software to distribute along with that certificate.

If all that seems like a hassle, well, yes it is. It is, however, the proper, authorized, and recommended way to distribute pre-release software, whether for testing or reviews. But there is another way.

If you know for sure that your target audience is another developer, the process becomes way easier. You can simply compile a normal development build of your application and send a copy of that build to another developer.

That's because each registered developer has the ability to sign applications. Although the app was built to work with just the in-house devices you've registered for development, another developer can re-sign that application using the simple command-line script shown here.

#! /bin/bash 
export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform\
/Developer/usr/bin/codesign_allocate
 
codesign -f -s "iPhone Developer" $1.app

This script uses Xcode's codesign utility to sign the already compiled version of the application. Once applied, you can then install the application through Xcode.

So is this a general distribution solution? No. And thank heavens for that; free trading of app binaries would rapidly lead to piracy. This approach allows developer-to-developer testing and collaboration only. The development signing is limited to the units you have personally registered.

If you want to try this out, follow the link at the start of this post. It leads to a testing folder I keep around and occasionally stock with software that I need tested. It also includes a copy of the script, which you must make executable (chmod 755 signit).

Developer Alex Sokirynsky wrote a blog post this morning saying Apple rescinded his authority to provision new ad-hoc licenses for his software, Podcaster.

The blog post has since been removed, possibly because it violated his developer NDA.

Sokirynsky believes that the licenses already provisioned will continue to work, and expressed disappointment -- but not surprise -- that Apple shut him down.

He also said he would continue updating Podcaster, even though it's unclear if he has a means to distribute it. Podcaster users can contact Sokirynsky if they have questions about their device's ad-hoc status.

Sokirynsky did not say how many devices he provisioned, though we do know it's at least 1,300.

In the din of announcements from WWDC on Monday, one of the underreported features for iPhone apps is "ad hoc" app distribution: registering up to 100 iPhones, and distributing your apps yourself.

Macworld's John Welch has a good overview of Ad Hoc and enterprise distribution, and what it means for IT departments. "[H]aving your applications distributed from your own servers on your own network just makes sense," he writes. "It makes security issues simpler, saves on external bandwidth usage, and simplifies the process of adding, updating, and removing applications."

Webmonkey, on the other hand, completely missed this part of the keynote, writing a review of the App Store that omits the ad hoc distribution plan and calls the App Store's exclusivity "yuck." Plus, it neglects to mention the still-thriving jailbreak community, and the legions of Installer.app users.

Ad hoc distribution means great things for proprietary apps for teams, classrooms, and large organizations. Sure, a 100-client limit might be a little small, and it remains to be seen how clients will be certified (that is, if you have to connect to the Mothership).

Do you plan on using ad hoc or enterprise distribution for your organization? Sound off in comments.