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.

WorldVoice Radio [iTunes link] is a cool little iPhone app that may help do for podcasting what Twitter did for web publishing -- make it easy to send out short, frequent messages. Of course, there's a difference, since WorldVoice Radio does this by letting you publish short podcasts from your iPhone. If you've used Utterli or Audioboo, you have the general idea.

The app, which was created by Kai Cherry and RnSK Softronics, has just arrived in the App Store. Kai is an occasional guest on the TUAW Talkcast, and he asked a few of the TUAW bloggers to join his beta testing team for WorldVoice Radio. (In the unlikely case that you're not familiar with the concept of beta testing, it's about getting a group of users together to make sure that an app is bug-free and functional prior to going to market.) Follow along as I give you a first look at this intriguing app, and as I beta-test WorldVoice Radio.

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).

I didn't really take last week's Twitocalypse that seriously, but as you probably know by now, it turned out a little worse than expected -- we'd been told that Twitterrific (and, we assumed, most other Twitter apps) would be fine, and of course, as Craig Hockenberry explains on his blog, things ended up not-so-fine. Desktop app developers, of course, could publish updates as quickly as they could code them; iPhone developers were in a different situation.

When the Iconfactory's app stopped working, most people (including me) got an API error all weekend. Craig found the bug, then he and his team were able to leverage their contacts at Apple Developer Relations to help expedite the release; in short order, an update was pushed out to the App Store. I downloaded it yesterday, and can tell you that things are fixed... at least until the numerical limit on Twitter's tweet identifier raises its head again (or the Newton flips out, but that's another story).

Hockenberry also has ideas about how to keep issues like this from happening again. Not the actual issue of a variable overflow (that will undoubtedly happen again at some point, on Twitter or any other API that scales way faster than anyone expects it to), but the issue of iPhone apps needing a quick fix. He says that Apple should give every developer a number of "incidents" -- situations rarely used, in which a high priority fix can get sent out to apps in major emergencies. He says, and it's true, that for most developers, it's not a question of if you'll need to send out a critical fix, it's a matter of when. And support by Apple, obviously limited to one or two instances per developer, would help developers, distributors, and consumers.

Of course, it's up to Apple, and it's not like they've smoothed out the approval process so well already that they can start adding wrinkles to it. But clearly, given that the Twitterrific update went through quickly, there's room for exceptions to be made.

[via DF]

This is really neat. The folks at Design Commission have produced a stencil to assist with the iPhone/iPod touch UI prototyping, brainstorming sessions, flows, interaction techniques, etc. that you'll do before you begin coding.

Of course, it includes all the standard iconography and buttons. Doesn't it make you want to just break out a fresh sheet of paper and set to work? If you want one, act fast, as they've only produced 100. Each kit ($16.95US) comes with the stencil and a Zebra mechanical pencil. A matching letter-sized template can be downloaded from the website as a PDF.

Now go and make the next killer app!

It's the first of what should be many videos coming to you straight from San Francisco: Two Apple developers, three opinions! At least that's the way it seemed coming out of the keynote this afternoon at WWDC. We caught up with several attendees and asked them for their thoughts. One of our favorites: "All I wanted was voice dialing, I've wanted it for the last two years... and then they do it, and it's just so much better than you expect it to be."

iPhone-friendly m4v file is here.

The keynote is now complete and the full liveblog is at the link below.

http://www.tuaw.com/2009/06/08/wwdc-2009-keynote-meta-liveblog/

Digg's Kevin Rose, perennial purveyor of information that just "fell off the back of the truck" shared a link early this morning to Google's new, supercharged, Webkit-based browser -- for Mac.

The new browser, Chrome, is clearly marked as a developer preview, and not meant for general browsing. In fact, as a good Mac citizen, it will refuse to set itself as your default browser.

It scores a 100 on the Acid3 test straight out of the box, but doesn't pass: it fails something called the linktest, which involves interacting A tags and IFRAMEs. A little research suggests that it could be a bug with Webkit. If that's true, then it's a bug that Safari 4 beta has fixed.

Chrome appears to have Flash (and other plugin) support disabled as well. JavaScript support, however, is fully functional. While Chrome performed much better than Firefox on this cursory test, it still didn't beat Safari 4 by a long shot. While only a beta, its performance is respectable and sure to improve.

Again, Google Chrome isn't for everyone, but if you're a web developer who needs to keep up with the bleeding edge of browser development, then this preview should be stable and reliable enough for you to test what you need to.

Read through for the full JavaScript test details.

Thanks to everyone who sent this in!

It's that time of year again. In the US, schools are emptying, weather is heating up and all sorts of developers are readying to wend their way to San Francisco for Apple's annual Worldwide Developer Conference, or WWDC.

Sure, the noncoding masses are expecting a hardware announcement (new iPhone, anyone?), but developers are really salivating over improvements to OS X in the upcoming Snow Leopard (10.6) release, and iPhone OS 3.0. After all, with great hardware comes awesome software. Apple might even have some surprises in store for us.

TUAW will be at WWDC during the week, and if you're a developer for iPhone or the Mac, we want to talk to you! Be sure to polish your elevator pitch, as we'd like to shoot as many demos as possible. Plus, we're attending the Parallels party (RSVP here), the iPhone Launch Party and maybe a few others, so there will be plenty of chances for your shot at fame. If you'd like to get in touch with us before the event, you can email us at wwdc at tuaw (dot com). See you in San Francisco! You can also join us online and on the phone during Sunday night's talkcast, where we'll be talking about the final round of preconference rumors and expected announcements.

For those you not attending, stay tuned to TUAW as we liveblog the keynote, dig into the announcements, and show the newest of the new apps being demoed at the event.

Apple has offered developers a glimpse as crash reporting since the iPhone 2.0 firmware was released, however, it was a kludge to get users to email you the crash reports from their ~/Library/Logs/CrashReporter/MobileDevice directory. Apple has a solution that will make this a lot easier.

Enter iTunes Connect, where Apple recently added the ability for developers to view crash reports from users. iTunes connect is where developers can manage applications they have on the App Store, check their sales, and get promotional codes for their apps. When you log into iTunes Connect you will be presented with the following information regarding crash logs:

Crash logs for applications are now available. To view them, go the Manage Your Applications Module below, click to view the desired application's details, then click View Crash Report.

When you navigate to Manage Your Applications > your app details > View Crash Report, you will be presented with a few items that could help you debug apps. Namely, developers can view most frequent crashes, timeouts, and memory usage right from iTunes Connect. You can find out more about crash logs on the iPhone by going to Apple's Developer tech note.

Thanks to everyone who sent this in!

Last year, the limited number of registrations to the Apple Worldwide Developer Conference (WWDC) sold out on May 14th. This year, the seats at Moscone Center didn't even last until May.

A tweet from @polarbearfarm alerted TUAW to the sad/happy news that WWDC sold out today. It's sad news, because there are a lot of procrastinating developers who didn't even have a chance to register. But it's also happy news, because this once again shows the vibrant and active life in the Apple development community.

As with last year's non-attendees, you'll be able to purchase session videos shortly after the conclusion of WWDC on June 12th, 2009. Next year, when you see our post saying that WWDC 2010 has opened for registration, get out there and get registered ASAP!

In the last iPhone Dev 101 post, I told you a little about creating your first project using Xcode; however, in this post, I want to show you how to create your first application that will run in the iPhone simulator. In honor of staying with the classic way of teaching programming, we'll create a "Hello World!" application as our first one.

Creating the new project
If you have installed the iPhone SDK/Xcode, then you can launch Xcode by navigating to /Developer/Applications. Once there, you can double click on the Xcode application (you may also find it handy to just drag the icon to the dock if you will be using it a lot).

Once Xcode launches, click File > New Project. Under the iPhone OS section on the left side of the resulting window, select "Application." Select "View-based Application" from the templates that show up on the right side, and then click the "Choose" button. You will then be prompted to specify a project save name -- this will also be the name of your resulting application, so choose your project name wisely.

You're project has now been created, and the Xcode window that is displayed will contain all of your code, resources, etc. There isn't much there now, but the application is fully functional at this point. You can click the "Build & Go" button in the toolbar, and the application will be compiled and launched in the iPhone Simulator. Again, this is a fully functional application, but it doesn't do anything useful at this point -- the usefulness of the app is up to your coding, but Apple supplies you with the base code and dependencies.

This is only slightly Mac-related but it is really cool. We've posted about two of Illusion Labs' popular iPhone games here on the site: Touchgrind is a 3D simulation of a touchboard, and Sway is a really fun little platformer-esque swingathon that has you swinging from side-to-side using the touchscreen. Both games are pretty original in how they use multitouch controls, and so when Illusion Labs got their hands on a big tabletop touchscreen, there was only one thing to do: blow the games up and play them in a big way.

You can see how it looks above -- seems like a lot of fun. And it makes you think, too -- multitouch seems to be where its at for the future of user interfaces, and the iPhone is really a breeding ground for testing out the technology and coming up with new ways to use it. It may be a long time before we all have huge multitouch screens like this in our kitches and living rooms, but considering how ubiquitous the iPhone already is (and the fact that almost anyone with some time, $100, and an idea can publish an app on the App Store), we can start seeing the kinds of applications that will live on those screens right now.

Earlier today, iPhone OS 3.0 beta 2 was released to developers. The big news is that push notifications and in-app purchasing followed this release, giving developers a chance to try them out. Engadget has reported on significant instability with beta 1, so here's hoping that's been improved.

There's also good and bad news with this release. The good is that MMS and tethering are supported in beta 2. The bad news is that Apple asks developers not use them. It's like owning a Ferrari without wheels.

If you're a developer, you know how to get this. Let us know how it goes, and have fun.

Spring is in the air, although we're in the midst of a blizzard here in the Denver area. That means one thing -- the Apple Worldwide Developer Conference (WWDC) is coming soon!

Eric over at coreiphone.com sent us a tip this morning that shows that the WWDC is scheduled for June 8 - 12 at Moscone Center in San Francisco, and that the WWDC website is up and running. Purchasing your registration by April 25, 2009 saves you a cool US$300 and you'll only shell out US$1,295. After April 25th, the price goes up to $1,595.

If you're planning on attending this year's premier Apple development event, be sure to register as soon as possible. Last year's WWDC sold out early, leaving many frustrated iPhone and Mac developers standing outside Moscone weeping uncontrollably.

Act now -- operators are standing by!