app store approval
Latest
Apple rejects Macworld iPhone Superguide from App Store... for using the word 'iPhone'
The iPhone App Store's arbitrary and inconsistent approval process continues to baffle and annoy on every level, as Macworld Editor-in-Chief Jason Snell just had his iPhone book rejected... for using the word "iPhone" in the title. Apparently Apple doesn't like app names or icons to include the word iPhone or images of the iPhone -- which arguably makes sense on some level -- but you'd think a freaking iPhone reference manual would warrant an exception, wouldn't you? Making matters worse, it appears that one Mr. David Pogue didn't have this problem, as his iPhone: The Missing Manual was approved with title and icon intact. Sigh. Phil Schiller -- deploy! Update: And just like that, Apple has reversed its stance and approved the app unchanged. Internet high-fives all around. [Warning: iTunes link]
Rejected, 'politically charged' iSinglePayer app gets the green light
True to form, Apple has rethought its strategy on an App Store rejection, and has granted the "politically charged" iSinglePayer rights to terrorize potential buyers with its alarming messages. If you'll recall, the application tackles the hot-button healthcare issue in America by offering spending advice for consumers and a GPS lookup for local Congress members' and their healthcare-related donations. As we mentioned in our original post, it's a pretty tame set of functionality, and certainly nothing that seems outwardly offensive (at least not any more offensive than lots of apps you can purchase). Just as with our previous complaints about Apple's way of doing business, it's not so much the rejections that bother us, but the unclear set of circumstances by which the company arrives at those decisions. Regardless, some firebrand app reviewer has seen fit to allow this townhall-rattling piece of software into the Store, so now you can go see what all the fuss was about for yourself. [Via Daring Fireball]
First Palm App Catalog rejection: NaNplayer
Palm's App Catalog isn't exactly bursting with titles yet, but that isn't stopping the company from rejecting apps -- and the dubious honor of First App Rejected goes to NaNplayer, a music player app. Apparently NaNPlayer made use of an undocumented webOS API call, so it makes sense that Palm wouldn't approve it, but there's a somewhat less-sensible flipside: it was using the same API the built-in music player uses to index files so it could make playlists. That's pretty basic functionality, so we're hoping this all gets resolved with a future webOS update -- and in the meantime, NaNplayer will be released to the burgeoning Pre homebrew community when it's complete.
C64 emulator un-approved again
The first thing I thought when I saw that the C64 emulator we posted about the other day still had the BASIC interpreter hidden in it was, "Well that won't last." And unfortunately for fans of software emulation on the iPhone, I was right: the software got pulled from the App Store but quick. You can't really blame Apple here -- they've made it pretty clear that they don't actually want people running unlicensed, emulated code on the iPhone, so it's not hard to see why, when it was discovered you could still activate the interpreter, they cleared it out of the store. The good news is that the emulator has been updated to delete the interpreter completely, and the owners of the software have resubmitted it yet again to the App Store. But as much as I enjoy seeing emulators on the iPhone (I've made it very clear I'd love to see an official NES arcade app), I can't say I'd blame Apple for just passing on this one outright. They've had to go through this app at least twice now, and especially since app approval is already taking so long, that's pretty much a waste of time. Mistakes like leaving the BASIC in the app (Edit: My mistake -- they intentionally left it in and hidden, with the expectation that Apple would later allow it. Doesn't seem very likely.) are making it much easier at this point for Apple to just say "no emulators, period," and move on. Hopefully this app will get re-approved, and that'll be the end of it.
C64 emulator approved for iPhone
Well how about that. A Commodore 64 emulator for iPhone is nothing new -- we covered the fact that one had been developed a little while ago. Here's what is new (and a little surprising, to be honest): Apple approved it. In an environment where Apple seems intent on rejecting anything that might encroach on their platform, even just a little bit, they have apparently allowed an emulator right there on the App Store. There are catches, of course -- the emulator comes bundled with five officially licensed titles: Dragons Den, Le Mans, Jupiter Lander, Arctic Shipwreck and Jack Attack, and more will be available to purchase soon, so it'll all be above board and legit (and the flip side is that if you want to play classic titles like Elite or Ultima, you'll have to hope that whoever owns the rights to those will let them see release). The biggest catch is that the emulator doesn't come with BASIC support enabled by default (although, via Daring Fireball and the iPhone Blog, it's possible to get to it via a backdoor), so it's more of a C64 arcade emulator rather than an actual software emulator. But of course this is a step in the right direction -- someday we may finally see official SNES or NES emulators running in full glory on the iPhone and approved and available to purchase on the App Store. This emulator, simply called C64, is available right now on the App Store for $4.99.Update: This app has been removed from the App Store because it was possible to enable the BASIC program. Look for it to return without that functionality.
Apple approves officially-licensed Commodore 64 emulator for iPhone
Well, it's almost certainly not a signal that Apple is opening the door to emulators of all sorts on the iPhone, but the newly (and finally) approved Commodore 64 emulator is still a fairly notable first for the platform -- representing not only the first officially-available emulator, but perhaps the first app that actually runs code (even if it is a couple of decades old). In this case, that first bit apparently wasn't too big a point of contention for Apple, considering that the app had all the necessary licensing rights lined up, but the second issue was, and ran right up against a clause in the iPhone 2.0 SDK that prevented apps from containing their own executable runtimes. As it happens, the key to bridging that divide around that was none other than iPhone 3.0, which contains a new feature for in-app purchases that the C64 emulator will take advantage of to let folks purchase additional games, rather than load arbitrary game code downloads. Interestingly, while this newly-approved version of the emulator also no longer exposes a BASIC interpreter, Manomio has added a note to the app that it "should be resolved in a future update," although it's not quite clear if that's just wishful thinking or not. In the meantime, you can grab the app right now with five bundled games for $4.99.
Stupid and unjustified App Store rejection letter of the day
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.
Spotify for iPhone gets thumbs up from Apple, subscription music with offline playlists is a go
Streaming and subscription music services are a dime a dozen on iPhone, and they seem to get past Apple's app store approval hurdles with relative ease. But Spotify was one whose fate wasn't so clear cut, given its offline playlist function -- which as the name suggests downloads songs ahead of time for you to listen to when there's no WiFi or phone service to stream from -- could very easily fall into the category of "duplication of core iPhone functionality" and get deep-sixed at the drop of a hat. Turns out that's not the case here, as an Apple spokesperson has told paidContent UK that the app's been given the metaphorical stamp of approval and would be hitting the store "very soon." A premium subscription will run about £9.99 ($16.20) per month, with an option to pay annually coming at a later date. Of course, there's a catch, as Spotify's service is only available in Sweden, Norway, Finland, the UK, France and Spain for now. The company expects to invade America sometime later this year, but that means another round of app store approvals -- and with Apple's track record on consistency, there's no telling how that'll turn out.
App Store Lessons: App Emergencies
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.
Magic trick developers find the trick is on them
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.
Phil Schiller says Apple didn't censor a dictionary
Yesterday's story about Apple censoring the Ninjawords dictionary seems to have made some waves in Cupertino -- none other than Phil Schiller followed up with Daring Fireball's John Gruber to provide Apple's perspective on the situation. According to Phil, Apple's objection to Ninjawords was that by using the free Wiktionary.org dictionary, it "provided access to other more vulgar terms than those found in traditional and common dictionaries," and that the App Store reviewer initially suggested the developer resubmit when iPhone OS 3.0 was launched with parental controls. Since 3.0 hadn't been released yet, the developer censored some of the words in an effort to get onto the store early, and that's how Ninjawords ended up both censored and rated 17+. Sure, okay, except that Gruber points out that the App Store reviewer flagged some pretty generic swear words, not the smack-your-momma vulgarities Phil claims are the issue. Still, the larger message remains the same -- the App Store review process is maddeningly inconsistent and in dire need of reform -- and on that note Phil says Apple intends to "learn and quickly improve," so it sounds like there's hope yet. Check the read link for more of Phil's response, it's an interesting read.
App Store Rejections: Apple rejects iKaraoke app, patent filed published for a karaoke player
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.
Apple's App Store approves first explicit content, Anita Bryant races to Cincinnati
After all the cases of benign apps being rejected on grounds of "objectionable content," the first outright application featuring jiggly bits has made it to the App Store. How could this happen? Easy, Apple's shift in policy is made possible by the parental controls included in the iPhone OS 3.0 -- you know, so you can parent instead of Apple. Hopefully this brings an end to arbitrary App Store rejections and begins a new era of fire and brimstone threats of eternal damnation.[Via MacRumors] Read [Warning: not safe for work]
Twitpocalypse aftermath and "incident" fixes on the App Store
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]
Apple rejects Bittorrent control app from App Store because it might be used to infringe copyrights
Sigh. Just as we thought Apple's ridiculous App Store approval process was about to get better with the advent of parental controls in iPhone OS 3.0, it goes and pulls another boneheaded move that makes us wonder if the entire system isn't hopelessly broken forever. This time the company's rejected Maza's Drivetrain, an app that allows users to remotely control the Transmission Bittorrent app, because "this category of applications is often used for the purpose of infringing third party rights." Right, "this category of applications," apparently meaning any app that has anything to do with Bittorrent at all -- Drivetrain doesn't actually upload or download anything, it's just used to manage Transmission running on your desktop. That's an awfully paranoid and restrictive stance towards one of the most popular file-transfer protocols around, especially since there are millions of legit torrents available, but somehow we're just not surprised -- this type of foolish, petty, and capricious behavior from Apple has sadly become par for the course with the App Store.[Via iLounge]
iPhone OS 3.0 now being used for App Store admission reviews (updated)
So this is interesting -- we were just forwarded an email from Apple informing iPhone developers that all future App Store testing and review will occur on iPhone OS 3.0 to prepare for a smooth transition this summer, and that incompatible applications won't be approved. Seeing as we're already on beta 5, we're guessing most devs shouldn't find this too much of a burden, but we're wondering if the recent string of bad publicity over App Store approval guidelines has forced Apple's hand here, since 3.0's parental control features will ostensibly relax Apple's currently asinine content restrictions and allow non-kiddie-apps to get through without any hoopla. Let's hope. Update: Looks like our guess was spot-on. The iPhone Blog's noticed a new set of parental controls in beta 5 (and possibly earlier) that suggests some sort of app rating system is in the works. Sure, it's a promising idea, but let's just hope the current broken process is also getting an overhaul -- simply slapping a 17+ rating on, say, Tweetie doesn't actually fix the problem.
iPhone OS 3.0's parental controls to assuage some app submission woes?
Here's something that should help Trent reach a level of moderate contentment. Although we already knew that Apple was expanding its parental controls with iPhone OS 3.0 into the realm of TV shows, movies and App Store apps, a report today about the rejection of Makayama's Newspaper(s) app provides a good example at the ramifications of such alterations. According to iLounge, it was rejected due to a picture of a topless woman under the section for UK-based tabloid The Sun. The accompanying letter suggested a resubmission once 3.0 (and subsequently the parental controls) go public, which we take to mean that the questionable content will suddenly be okay for the App Store once it's behind the appropriate age gate. We won't know for sure until everything falls into place, but sounds like this is one part of the submission approval process that'll soon end up much less frustrating for developers. [Via 9 to 5 Mac]
AMBER Alert appmaker not happy with submission process
Jonathan Zdziarski, who has appeared on this pages before for other iPhone-related hijinx, has written an open letter to Apple about the AMBER Alert iPhone app he's written. Apparently he's worked in conjunction with government agencies to set up an iPhone app that can easily and quickly send sighting reports of children gone missing in the United States. And he's unhappy with Apple, because they haven't yet approved it.His letter, which you can read in full over here, complains that we've got tons of fart apps already approved on the store, but his app still sits in approval purgatory. He actually sounds kind of selfish in the letter to me -- he says he doesn't care about how the App Store works, and that he just wants someone to "pick up the phone" and push his app, which could save children's lives, through.We've got nothing against the AMBER Alert system, of course, and if it's true that this app can get more reports in and possibly help kids who are in danger, then great. But do we really want Apple picking and choosing which apps get kicked to the front of the line?Update: looks like the app has been approved. The question remains: what was the holdup?
