TUAW has covered the fine iPhone apps from Tapbots more than once. ConvertBot is a beautifully-designed and functional app to do a myriad of unit conversion calculations, while WeightBot is my personal favorite app for keeping track of my incredible ballooning body.

Tapbots posted an entry on their blog today stating that the most recent version of ConvertBot (1.4) had been rejected by Apple. What was Apple's reason for the rejection? As you can see in the graphic at the top of the page, the ConvertBot icon for time conversions looks very similar to the Phone app icon for recent calls. This is the same icon that has passed Apple's scrutiny in previous versions, so it is ridiculous for the company's eagle-eyed app inspectors to suddenly decide that the icon is unfit for iPhone consumption.

Mark Jardine of Tapbots noted "So what's the plan? I need to redo the icon, I suppose. But Convertbot icons were meant to use as little lines/shapes as possible to identify the category. I feel that our current icon represents time as simply as possible. So how can we make Time different? What if it's set at 9 o'clock instead of 3? Is that acceptable? The big problem here is the only way I can get that answer is by making the change, resubmitting the app, and waiting another week or 2 for Apple's verdict."

What gives, Apple? You release a couple of amazing apps to the world this week (Facebook, Spotify, TUAW, and Yelp), but you hold up the next release of an established app over an icon. I'm giving the App Store approval people the "idiots" tag on this post.

Bad things happen. Despite all your user testing, sometimes an iPhone app release hits the wild with unexpected results. I recently heard about one application upgrade that passed Apple review, but that crashed when run on handsets that had a previously installed version of the app. Another app experienced data corruption when incoming phone calls interrupted file write operations.

So you're a developer, and this happens to you. What do you do?

Developer Emanuele Vulcano issued some recommendations in a recent iPhoneSDK e-mail group post:

• First, brace yourself for user rage. Customers aren't going to be happy even though you're going to treat this situation as proactively as possible.
• Update your application description immediately. Explain what is wrong with the update and why users shouldn't upgrade. Put the word IMPORTANT in capitals.
• Submit your bug fix and then contact the escalation/approval team email from the developer help pages. Explain what happened. If your situation is critical, they can speed up the review process. Just take into account any time they'll spend before looking at your e-mail.

This situation recently cropped up for TUAW reader and iPhone developer Mahmoud and his app BargainBin. "The 3.0 update made BargainBin the only app to monitor App Store price changes and provide push notifications to each user when the apps they care about went on sale. We were so preoccupied with making sure the push notifications and user watch list worked properly, that we overlooked a critical bug. How critical? Well, every time BargainBin was launched to any screen other than the 'Watch List,' the user was presented a screen that said 'no items' rather than the relevant price changes."

Absolutely devastated by this error, Mahmoud and his colleagues immediately worked on a bug fix. "We updated the code in about 15 minutes to fix this critical bug. But now it was back to the submission process." This was an update that affected critical application performance. So after submitting his BargainBin bug fix on August 6th in the afternoon, he sent an e-mail to the escalation team.

And he got results. Apple's iPhone Developer Program expedited the review, making a one-time exception to their normal process. By the evening of August 7th, the update went live in the App Store -- less than 30 hours later, rather than the 7-14 days for a normal upgrade review.

As Mahmoud writes, "Kudos to Apple. This [should make] a nice change from the 'how broken [is] the App Store approval process' articles." TUAW agrees. Way to go, Apple.

Want to read more about the story? Pop over to this write-up over at Mahmoud's company blog.

Update: The official Google app is apparently not going to be released either.

Earlier today, iPhone developer Sean Kovacs posted on his blog that his Google Voice client, GV Mobile, is getting pulled from the App Store due to "duplicating features that the iPhone comes with (Dialer, SMS, etc)." Kovacs says he received a call from an Apple staffer, who "wouldn't send a confirmation email either - too scared I would post it."

The app still appears in the App Store, but when you attempt to purchase it you will be told "The item you tried to buy is no longer available." We've also heard that Voice Central (another Google Voice application) is similarly no longer available for purchase.

There has been speculation that Google is preparing its own iPhone app for Google Voice, however, in light of the news that Apple 'requested' that Google make Latitude a web app instead of a native app "in order to avoid confusion with Maps on the iPhone," I wonder if we are unlikely to see such an application from Google.

MailWrangler, a native Gmail client for the iPhone was also rejected from the App Store because the "application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion."

As a heavy duty user of Gmail, I've wished for MailWrangler from the beginning. Sure you can use Gmail through Mobile Safari -- as you can use Google Voice -- but as Apple soon learned after trying to convince users and developers that web apps were all we needed, there are certain things which a native application makes much easier.

GV Mobile is a very popular application for using Google Voice on the iPhone. Apple's own phone application is great, but for Google Voice users, a native application was a nice thing to have.

I'm not sure why Apple keeps insisting that users would be confused by apps which do similar things (How many different applications are there which duplicate "Notes" functionality?), but a greater concern is the idea that a developer can work on an application, have it released to huge success, and then have Apple turn around and yank it from the App Store.

This in loco parentis attitude from Apple hurts iPhone users and developers alike. Developers like Fraser Speirs have stopped developing new applications for the iPhone and he's not the only one. (Fraser's post on Twitter was how I heard how I heard about GV Mobile being pulled from the App Store.)

I hope these are growing pains that Apple and the App Store will leave behind. Users who seek out, find, download, and install 3rd party applications are unlikely to be "confused" by the "duplication" of functionality. The fact that they sought them out is evidence that they found something lacking from the applications that Apple offers.

The App Store is wonderful, except for the parts of it which are terrible; namely, the review process (which takes too long and rejects too many apps) and the removal of applications which do no harm and which have been released for some time to great success.

UPDATE: The developers of Voice Central had an interesting conversation with Apple. Mostly involving the word "can't."

As if the waters surrounding the App Store approval process weren't murky enough, one developer has just hit an unprecedented wall. Apple rejected his app, iKaraoke, citing that it duplicated functionality of the iPod application. Of course, the "duplicate functionality" reason is nothing new, but Apple's next step is: just a few weeks after rejecting the application, they have filed a patent for including karaoke functionality into the iPod app.

A brief look at the demo iKaraoke's website will quickly tell you that, while the app does bear a light resemblance to some of the menus found in the iPod application, the actual interface that the user interacts with to select and download a song is far from duplicating the iPod's polished interface. Another key point is that the file format used by iKaraoke is known as the .kar format -- an unofficial extension of the MIDI specification that enables lyrics to appear in time with music. The lyrics are then displayed on the screen, and highlighted as the song is played. Does any of this sound like functionality found in the iPod app? We didn't think so.

So what exactly was duplicated then? According to apple, iKaraoke "duplicates the functionality of the built-in iPhone application, iPod, without providing sufficient differentiation or added functionality." But they didn't just stop there. The reviewer went on to say that the application "downloads media files that are not managed by the iTunes application, which also manages media files, we believe this would be confusing to the user." Now, hold on a minute here... it's fine for several other apps to stream and download media files that are supported by the iPod without being managed by iTunes, but it's not OK for an app to download media that isn't natively supported, and provide functionality that isn't natively provided by the iPod?

This wouldn't be much different from your typical app rejection if the story stopped there, but it doesn't. This morning, Apple filed a patent [application here] which details built-in Karaoke functionality being added as part of the iPod application, with some additional bells and whistles such as monitoring the pitch of the user's voice. So it seems the functionality that was duplicated is functionality that Apple has not yet released, and possibly not yet even begun to develop. Maybe the $99 iPhone Developer Program fee should include a crystal ball for testing apps before submitting them.

As with the many other patents Apple has filed, this feature may never see the light of day. But is it really acceptable to reject an application, based solely on what appears to be a duplication of a feature that may or may not even be released in the future? Let us know your thoughts in the comments.

Update: As a few of you have pointed out in the comments, although the patent application was published today, it actually was originally filed back in April of 2008. While this does indicate that the patent was indeed filed long before the SDK was even released, questions still remain about whether or not Apple may choose to reject applications based on functionality found in unreleased features.

Similar rejections have occurred with apps that offered podcast downloads prior to the inclusion of podcasting functionality in iTunes, for example. Essentially, what needs to happen is that Apple needs to clear the air on what exactly is considered a duplication of functionality, and to be clear with the developer on exactly what aspects of their application are in violation of this requirement, rather than sending a vague form letter and ignoring inquiries for additional information from the developer.