Early this week, Google released their Google Mobile Search application on the iPhone, adding Voice Search capability. It can now record your query, pass it to Google's servers to translate, and return results. The voice recognition itself is far from perfect (for instance, my own name "Paul Kafasis" becomes "Polka Foxes", the perfect name for my as-yet-unformed band), but it's pretty good overall, particularly when following the examples Google provides in their overview video.

More impressive, however, is the interaction to start the voice recording. Just lift the phone to your ear, and it begins recording. Bring it back down, and it ends recording and starts your search. It's not overhyped or overdone; it's just polished perfectly. Quite simply, it's exactly how this feature should work.

The problem, however, is that Google "shouldn't" have been able to do this. John Gruber and I chatted about this on Wednesday, prior to his post detailing what's occurring. Erica Sadun then followed up with more in-depth research. You should read those posts for more details, but in short, enabling this feature currently requires that Google use unpublished APIs to access the accelerometer and light sensor in a way that provides a notification. Unpublished APIs are features of the phone that aren't documented or declared "safe" for use by Apple.

Unpublished APIs can change, so using them on any platform can cause breakage when OS updates are released. Of course published APIs change too, and the risk either way is generally low, so developers often use these unpublished APIs. Doing so enables us to provide new features that Apple never imagined. On the iPhone, however, Apple's SDK agreement precludes developers from using unpublished APIs at all. According to the agreement, doing so will prevent your application from being accepted to the App Store.

Obviously, this isn't entirely true. Whether Google received special dispensation from Apple, or Apple missed this, it's clearly possible to get apps into the store that use Unpublished APIs. I'd argue that this is the way things should be, that the burden is on developers to deal with the fallout of their own applications breaking. That's not what the rules say, however.

Instead, if the rules had been followed as written, Google would have been unable to design and provide this feature. If they'd stuck by the rules, the only way to record audio would be via a button process (as is currently available as an alternative). It could be argued that this is a small change, and that's true. However, it would be difficult to argue that having this be the only option would be better.

It's not clear what will happen in the near future with this particular app. It seems unlikely that the application will be pulled, but what will happen if another application attempts to do the same thing Google is doing? Will it be approved or denied? How about applications that use other unpublished APIs?

Google innovated to provide a nice bit of polish, and was lucky or powerful enough to slip it through Apple's rules. On the Mac, Google or any other developer would have been free to innovate and release this, with no restrictions. On the iPhone, however, this nice bit of polish had to slip through Apple's agreements. Just how much innovation are we missing because developers are fearful of having their application rejected?