approval process
Latest
Skyfire disappears from iTunes App Store due to technical difficulties (update: 'sold out')
Trying to get a copy of the Skyfire browser for your iOS device? You may not have much luck, as the pseudo-Flash-capable browser has just disappeared from iTunes App Stores around the globe, mere hours after its splashy debut. When we try to download it for ourselves in the United States we get the message immediately above, and RazorianFly readers are chiming in with reports that the app is no longer available in Greece, Sweden, Denmark, Germany, Australia, Canada, Switzerland, Norway, Spain and the UK. We just pinged Skyfire for comment and they say it's not Apple's fault; demand for a Flash video workaround is apparently so high that the company's having server issues and decided to pull the app rather than introduce new users to a sub-par experience. Skyfire assures us that it's adding servers as quickly as it can, but didn't provide an ETA on when we might see the app once more. Update: While we're not sure how an digital app can be "sold out," that's exactly what the company says happened to its $2.99 browser today -- after quickly becoming the top grossing app in the iTunes App Store, Skyfire is "temporarily not accepting new purchases" and says it will issue Facebook and Twitter status updates when the next batch of licenses is available. In other words, Skyfire's throttling the flow of purchases from now on. PR after the break. [Thanks to everyone who sent this in]
Dan Stahl talks about Star Trek Online's user-generated content
With its first doses of weekly content a success, Star Trek Online is in a fairly comfortable spot at the moment. But there are still places to expand, including the often-mentioned tools for user-generated content. Although the tool isn't yet in the game, executive producer Dan Stahl has been discussing it for some time, and he goes into a bit more depth in a recent interview. He also discusses some of the upcoming changes scheduled for the game's later major updates, including interior interaction and bridge officer voices. Among the more interesting issues discussed is the impact of user-generated content on the game's licensing. Everything currently in the game required approval from CBS first, which Stahl states has led to some discussion about how the user toolsets will interact with the canonical fiction. He also discusses several improvements planned for season 4, and the possibility of more interaction with ship interiors starting in season 4 or 5. Star Trek Online players are encouraged to take a look at the newest interview for a clearer picture of the game's future.
Google says Phil Schiller himself rejected Google Voice from the App Store
It was always curious that Google's response to the FCC inquiry about Google Voice and the App Store had been redacted, but now we're starting to see why -- El Goog and the FCC have just released the full text of the letter, and it flatly contradicts Apple's take on the matter. If you'll remember, Apple claimed that while Google Voice hadn't been approved, it also hadn't been rejected, and that its status was in limbo while the folks in Cupertino "studied" the matter. Not so, says El Goog: according to its letter, Phil Schiller himself told Google that GV had been rejected on July 7 for duplication of functionality, following a similar conversation on April 10th during which Schiller rejected Google Latitude in part because it might "offer new features not present on the preloaded maps application." Yeah, that's a huge discrepancy, and it makes Apple's version seem even more divorced from reality that it already is. Things are starting to heat up -- we'll see what the FCC makes of all this. Update: And here we go -- Apple just pinged us to say the following: "We do not agree with all of the statements made by Google in their FCC letter. Apple has not rejected the Google Voice application and we continue to discuss it with Google." Update 2: So we've been thinking about it, and here's our question -- if Apple didn't reject GV, and is still studying it, what exactly did Phil Schiller say to Google to make them think it had been rejected? The difference between "rejected" and "on hold pending further discussion" isn't a subtle one, and Google clearly thought GV had been explicitly rejected. For whatever it's worth, reports of GV's "rejection" are how this whole mess got started, so either this is all one huge misunderstanding, or someone here isn't telling the entire truth. Read - Google unredacted FCC filing [Warning: PDF] Read - Google Public Policy Blog explaining decision to release letter
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.
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]
