Just a quick heads up to all your iPhone and iPad developers out there. The new version of the 3.2 SDK is now available for download. The Apple developer site is getting a bit slammed right now but it looks like a really exciting new update. Can't wait to start playing with it myself.

As per last time, the new beta SDK is under NDA, so please go check out the details for yourself to get further information about the changes between this beta and the last.

Last week I downloaded (but did not install) the iPhone OS 3.1.3 firmware for my 3GS. I wanted to have a copy of the firmware on hand, but didn't want to upgrade right away. I checked "Do not ask me again" and clicked Download Only. I thought that was the end of the matter.

Unfortunately, this Sunday, I plugged in my iPhone and left the room to grab some tea. When I returned, the iPhone was 50% of the way through the 3.1.3 firmware upgrade procedure. It did something I had no idea that it would do: it upgraded me without asking.

How frustrating! What's more, I didn't have a copy of 3.1.2 on-hand to downgrade to because iTunes automatically deleted the old firmware files and I was using default Time Machine settings; Time Machine does not normally back up ~/Library, the folder that contains the iTunes ipsw files.

Fortunately, I had several resources. First, because I had jailbroken my phone and registered my device signature with Jay Freeman's caching service, I knew I could downgrade my phone. As Jay and I discussed in this LiveChat from a few months back, Apple no longer allows you to freely downgrade your iPhone software. All firmware installations must be verified with Apple's signature servers.

By jailbreaking your phone and registering your device signature with Jay's system, you'll be able to bypass Apple's verification system and return to the firmware you prefer -- or at least to the earliest firmware whose signature you have stored on the caching site. To make this happen, you must both register your device and update your /etc/hosts file. Jay's site has complete instructions on how to comply.

Second, I could grab a copy of old firmware from sites like Felix Bruns' http://www.felixbruns.de/iPod/firmware/ and iClarified's http://www.iclarified.com/entry/index.php?enid=750. These sites provide Apple download links for old firmware releases. I downloaded a fresh copy of the 3.1.2 ipsw (iPhone software archive) and installed it onto my system. Using a standard option-restore trick, I was able to put that firmware onto my iPhone. iTunes verified the upgrade with Jay's server and installed it onto the device.

Note: If you receive the "The iPhone could not be restored. An unknown error occurred (3004)." error, make sure to quit iTunes and flush caches at the command line: sudo dscacheutil -flushcache.

If your device updates properly, you will receive a 1015 error and your unit will now enter a semi-permanent recovery mode, the mode in which your device shows an iTunes logo and will not boot further. To proceed, you'll need to use iRecovery. Download a copy from this site. (It requires libusb, so read the entire post before running.) Run iRecovery from the command line and supply the -s flag. Wait for the "]" prompt, and do not type anything until you see that prompt appear.

Enter the following commands:

] setenv auto-boot true
] saveenv
] /exit

After, you will return to the command line. Reboot your phone by pressing the home and sleep buttons for 10 seconds, per the instructions on the site, and your iPhone should boot back to standard 3.1.2.

Note: Be aware that this method does not downgrade your baseband. It remains at the 3.1.3 setting.

Thanks Jay Freeman, Sjoerd (aka WiFone), and Paul "PhoenixDev" Griffin

So my folks were here this weekend, and as you'd expect my Dad is really curious about the upcoming iPad, or as he likes to put it "his new 3G iPad". I convinced him that he should wait for April so he could get the new postpaid-data-ready iPad, which he could use anywhere, not just with WiFi hotspots.

As we were talking, I began to realize that he didn't really have a clear idea of exactly what this gadget is -- and lots of you probably have parents in similar situations. So I put together this Q&A using actual questions my Dad asked throughout the course of the weekend.

"So I can use it instead of my normal computer, right?"
The iPad isn't going to replace your home computer. In fact, it's supposed to be like an iPod -- a mobile device you bring along but not a primary system. You manage your music and movies and everything over on your main machine (a Windows unit in my Dad's case) and then synchronize that data to your iPad using iTunes.

"But what about Microsoft Works? Can I load that on?"
Afraid not. The iPad is more like a mobile phone than it is like a computer. You won't be able to run Windows on it, or even the Macintosh operating system OS X. It has its own private system and can only run apps that you buy at the App Store. (Trust me, my Dad does not want to know from jailbreaking or Cydia.)

Read more →

TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on signing already-compiled and already-signed applications with a new custom signature.

A while back, I posted about a way to sign already-compiled applications with your personal credentials in order to better allow developer-to-developer distribution. By re-signing an application, it allows you to install it on any of the devices you have registered to your account at Apple without having to go through the fuss and bother of normal ad-hoc distribution. In addition, it makes it easier to develop applications on a contractor's machines, to ship them to a client, and then have them signed and shipped to App Store using the client's identity.

A basic command-line solution is as follows. It calls codesign (found in /usr/bin) to sign the application, using the default keychain item that matches "iPhone Developer". It's a handy script, especially for informal beta distributions.

#! /bin/bash

export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate

codesign -f -s "iPhone Developer" $1

There are, however, several problems with this approach. First, it assumes you only want to sign with development (typically "Debug build") credentials. That's not going to work if you need to re-sign for distribution. (Solution? Change iPhone Developer to iPhone Distribution). Second, it assumes you only have one developer or distribution profile in your keychain. (Solution? Change iPhone Developer, for example, to iPhone Developer: Company Name to exactly match just one keychain entry.) Third, it assumes the person doing the re-signing knows how to use a command line. For that, the solution is a little more complicated.

Recently, this topic came up on a developer e-mail list that I moderate: how do you make it easier for a non-technical client to re-sign an application, normally for distribution. As a solution, I put forth the proposal that one could embed the above shell script behavior into an AppleScript droplet. After consulting with a few colleagues, and gathering their requirements, I decided to give the project a try. I built an AppleScript application that signs any application dropped onto it.

You can find a working copy of the application at my website. App Signer iterates through any apps dropped onto it, checks to ensure whether each file (or bundle, really) ends with an ".app" extension, and then attempts to sign those files using /usr/bin/codesign.

Users can choose to sign with Developer credentials, Distribution credentials, or select Other to open a prompt and enter text for keychain disambiguation. (See the screen shot at the top of this post for an example of the disambiguation dialog.) The application displays results for each application, one at a time.

Please note the following caveats:

• I make no attempt to guarantee that the app dropped onto this utility is actually an iPhone app (rather than, say a Macintosh application).
• When working with on-device keychains, the identity used to sign the application has to match the application id set forth in the Info.plist file for the application, otherwise keychain access will fail.
• This is a free application. It is offered under the BSD license. Use it at your own risk. Credit always appreciated. The open source github repository for App Signer can be found here.
• To create the application, open the AppleScript source in Script Editor and choose File > Save As > File Format: Application.

Dear Auntie T.,

I have the best idea for an iPhone app, well, modestly speaking, ever! So how do I sell this great idea? Is there a forum for discussing how to get an idea sold? Any help you can offer will be appreciated.

Love and kissies and hugs,

Your nephew,

Mike (who isn't Max)

Read Auntie's answer below!

Read more →

TUAW reader Gabby tipped us off this morning that Apple has expanded its new browser-based iTunes previews to include App Store offerings. Sure enough, I pasted a standard App Store URL for Apple's Remote application into Safari and was treated to the preview shown just above.

This new preview option is just one of many App Store URL tricks you may want to take advantage of. You can find some of the most useful tricks right after the break on this post. Got another URL trick for App Store? Let us know in the comments.

Read more →

Are you doing production work and beta work at the same time? Need to install more than one SDK at once? If you've downloaded the 3.1.3 SDK and need to install it on the same system as the 3.2 beta SDK, you'll want to use the Xcode installer's destination chooser.

When given the option of where to install, click on the Developer folder to reveal the pop-up shown here to the right. To create a new folder/location choose "Other..." and use the standard file browser to create and select that location.

I personally use a named folder for all beta installs. My 3.2 beta is located in /Developer32 and I used the standard /Developer path for my 3.1.3 SDK update. Both SDKs coexist in peace with each other, although I did have to assign separate key macros (I'm a Quickeys addict) for normal Xcode and Interface Builder (in /Developer/Applications) and the beta versions of the same (in /Developer32/Applications for me). Having both SDKs available and separate will help you make sure you can test and code in both environments quickly and easily.

In pixel-terms, the iPad offers a much larger workspace to develop on than the iPhone but in terms of the human experience, it's not that very far away from iPhone programming. The two share an underlying operating system and a large overlap in human interaction realities. Here are just three of those overlapping iPhone development realities. Consider taking these ideas into account as you're building your new and updated applications for the iPad.

Human fingers are big. Although the iPhone has a much smaller screen than the iPad, the size and shape of the typical human finger does not change between the two devices. Do not design interaction elements for the iPad smaller than, say 40-by-40 pixels in size.

When in doubt, design larger rather than smaller. The iPad with its larger screen is more likely to be held further away during use than the iPhone, which is often raised fairly close in during use. Build your on-screen objects accordingly. With its 1024x768-pixel screen, the iPad has the room for clean, large interaction elements. Use that space to better compliment the human finger.

Attention spans are short. Like the iPhone, expect your users to approach the iPad in a sporadic netbook-style fashion. Design your applications around short interaction periods and prepare for your application to be cut off as a user stands up to grab his next Orange-Cranberry Frapaccino.

Always save your application state between sessions, as much as you possibly can. A well designed app should relaunch quickly and, upon relaunching, approximate the same task your user was performing the last time the program was run. This can demand diligence on the part of the programmer, but is worth the time investment due to the payoff in user satisfaction.

One more tip after the break!

Thanks Scott Lawrence, |Agent

Read more →

Sonic at the Olympic Winter Games [iTunes link] brings a mobile version of the Sonic franchise to the iPhone for this timely-themed product. It is officially licensed by the Vancouver Olympic games. With it, you can try your hand at curling, figure skating, snowboard cross, and skeleton, i.e. sports you probably never thought you'd actually be playing on an iPhone.

If you're a big fan of Sega's Sonic the Hedgehog, and you like the way the Sonic games play on other devices, you'll be pleased that a lot of the same feel and gameflow have been ported quite successfully to the iPhone. As with other Sonic games, you select the character you want to portray and you are randomly matched against other characters in the Sonicverse. You can choose from single player one-sport events, multiplayer, and circuit mode, where you play all four events.

The graphics are superb and the user interface development is top notch. A lot of care and programming have gone into the tiny details that make up this game. Between the animated icons (info is a book with flipping pages, settings are a rotating gear on top of a building, game selection is a happily bouncing stadium), sound design, and small interface details like how menus slide onscreen, I was really impressed; congratulations to Sega for developing an interface that really matches and works with the iPhone platform.

I wish the actual game play could match the overall look and feel. Unfortunately, I found playing the events to be less thrilling and poorly conceptualized. Take the figure skating, for example. It was easily my favorite sport in the game, but the way the game you focus on tapping the right spot at the right time (you have to synchronize your tap to a shrinking circle) or tracing your finger along a given design (so you can perform spins and jumps), totally took away from actually enjoying the event.

Great iPhone interactive sport apps put you right into the middle of the action. You submerse yourself into experiencing the game play and your device interaction gets outsourced to your motor control as your eyes drink in the visuals . With figure skating, I could barely see the (beautiful!) graphics, let alone enjoy the music, because the game mandates that my eyes and fingers had to be working on locating, tapping, and drawing in just the right place and at the right time. There was a big disconnect. And because of that disconnect, the actual skating seemed to be taking place somewhere else -- somewhere I couldn't really enjoy.

The skeleton and snowboard cross events better offered submersive interaction. They more or less mimic every downhill iPhone game you've ever played. You ride downhill and collect gold rings. The controls are based on tilting the iPhone both side to side and front to back. For snowboard cross, you also get to ride through Mario-style cubes with question marks for special power ups. Both downhill events were pleasant enough to play.

At the bottom of the pack, I found curling tedious to the extreme, which is a shame. Because if Sega had designed this event with faster gameplay and the ability to keep playing over and over in one go, it could have been quite fun. The problem isn't pushing the stone and sweeping (those parts are actually enjoyable), the problem was waiting and waiting for a turn, as the opponent operated in real time, and in all the setup/take down time for each match. The fun bits are simply lost within the administrative overhead.

Sonic at the Olympic Winter Games offers a reasonable value for the money (it's a slightly hefty $4.99) but while the games were pleasant but none of them really made me want to play them again. I admired the work that went into creating the product but I can't really recommend it to anyone who isn't a big Sonic fan to begin with.

Do you use a bottom-connector battery extender? Have you been bothered by the awkward phone geometry that involves? For me, I've found it really hard to deal with the added length, especially with the (tiny!) storage compartment on the top handle of my Jeep stroller. For me, the longer phone-plus-battery length simply doesn't work, which means I can't fit the phone in.

That's awkward because I like to use TrailGuru as I walk to go pick up my youngest from school in the afternoon. After a bit of hunting, I've located a way to detach the battery from the phone to create a bending solution that does fit.

I recently picked up a Male-to-Female dock extender from DealExtreme for under four bucks (with shipping included). The cable lets me "fold" the battery into place for afternoon walks or stick it into my pocket while using the iPhone on a tether.

As far as stroller and backpack use goes, it seems to be working quite well. As for tethering, it's a fairly thick cable, and brings with it all the standard tethered irritations. Frankly, I'm not a big fan of tethered use but when you need that extra battery charge, it's a slight improvement over having the battery pack stuck directly into the bottom of the unit.

DealExtreme ships from HongKong, so it generally takes a week or so for packages to arrive. I've bought lots of things from them and they've been reliable shippers. When purchasing from Chinese suppliers, do keep in mind that the individual item fail rate is going to be higher than you might expect: not a constant issue, but something you should factor into your purchases, and something I've certainly experienced.