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 CEO of Theory11 wrote TechCrunch to say that, after Phil Schiller got involved, the Rising Card app was approved and is now on the store. Here's the iTunes link, and it's $2.99.

Just when you thought the App Store approval process could not get any weirder comes word that the developers of magic tricks for the iPhone are coming under increased scrutiny from the gatekeepers at Apple.

According to the iTricks website, developer Chris Kenner's Rising Card app has been sitting in App Store limbo after Apple suggested the app might violate their guidelines.

Which guideline might that be? Consumer confusion of course. The developers respond that many tricks rely on confusing the consumer, that's how people get fooled.

The dust-up is causing many magic trick developers to have second thoughts about the App Store. They may re-do their trick as a web app, or work to find some way around Apple.

One magic developer, Hotrix, is selling so called 'Premier' apps that don't require the App Store at all. It works well, but I'm not at liberty to divulge how they are doing it.

One of my colleagues quite correctly points out that Apple has not been overly long in the approval process, and the apps are likely held up because they mess with some of the strict iPhone interface guidelines. Apple is setting the 'confusion' bar pretty low, but one can understand both sides in this controversy.

Gerald Kirchner, who runs Magic City and has produced some first class magic apps, sees the dilemma. "Apple has a point when they say the spectator would be confused, as the iPhone is not "working correctly". Apple is all about the "Apple experience", in a way, we magicians are taking that "Apple experience" away. There is an app in Cydia that I love that makes it look like your friend breaks your phone and cracks the screen. It is great fun, but does Apple really want to condone software that makes it look like you broke their device. It sucks, because I make a lot of these tricks, but I understand Apples views."

Still, it would be nice if the App Store had consistent guidelines. We've been all over that topic, but the issues remain.

Advice to Apple: Be careful about messing with someone who has a magic wand.

Thanks Harrison for the tip.

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.