Airfoil Speakers Touch Removed From the App Store
We first heard from Apple about this decision two days ago, and we’ve been discussing the pending removal with them since then. However, we still do not yet have a clear answer on why Apple has chosen to remove Airfoil Speakers Touch.
It’s been in the store since 2009, and the version being rejected now was accepted back in April.
Update (2012-05-25): John Gruber:
Apple doesn’t provide APIs for apps to serve as AirPlay receivers. Rogue Amoeba backwards-engineered the protocol, and coded their own iOS AirPlay receiver implementation using (they claim, and I have no reason to doubt them) only public APIs. I think the bottom line is that Apple is saying that apps are not allowed to act as AirPlay receivers on iOS, but there’s no App Store guideline that explicitly forbids that.
Part of the problem is that Apple is not saying anything except that the app is rejected. There are apparently 5–6 other AirPlay receivers that have been rejected, yet the rules haven’t been updated to forbid this, and Apple has not given Rogue Amoeba any explanation.
Update (2012-05-29): Kafasis has posted a follow-up:
As we’ve stated, to the best of our knowledge we’ve implemented Airfoil Speakers Touch using only publicly-available APIs, and in full accordance with the developer agreement. We’ve continually asked what non-public APIs they believe we’re using and have received no response.
Indeed, there seems to be something of a communications problem with Apple, as we haven’t heard from them since May 23rd. Apple apparently did have time to contact The Verge about this issue on May 25th, however, repeating their claim that we’re using non-public APIs.
First Apple removes the app from the store, then it gives the developer an explanation that’s transparently false, then talks to the media—still without telling the developer the real reason for the rejection.
Unfortunately, both the App Store and the review process are entirely controlled by Apple, so there’s not a lot else we can do at the moment. We’re definitely concerned Apple may just silently stonewall on this, so we’ll keep discussing it here.
Update (2012-06-06): It’s back in the App Store, without the Enhanced Audio Receiving feature:
Regardless, Apple is using the authority they provide themselves in the guidelines and program license agreement to remove apps they don’t like. Specifically, they cited a provision in the App Store Review Guidelines which allows them to reject apps “for any content or behavior [they] believe is over the line”. That’s certainly disappointing, and frustrating, but it’s the nature of the system Apple has created.
If nothing else, we’re gratified to at least have come to an understanding that we didn’t violate the guidelines – Apple simply doesn’t want us providing this functionality in the App Store. Ultimately, if Apple doesn’t want it, we can’t provide it and users can’t have it.
Update (2012-06-08): Phil Schiller:
The story as I understand it is simple, and not accurately recounted on Rogue Amoeba’s website. Rogue Amoeba’s app added a feature that accessed encrypted AirPlay audio streams without using approved APIs or a proper license and in violation of Apple’s agreements.
While Apple licenses the ability for hardware manufacturers to play AirPlay audio, there is no such licensing program for software. When we inquired as to the possibility of this type of licensing being available for software manufacturers in the future, we were informed that it was unlikely. […] We steadfastly stand by our statement that Airfoil Speakers Touch violated no part of our agreements with Apple.
Apple is within its rights to reject whichever applications it chooses. However, it’s scummy that the official reason was the nebulous “over the line” clause, yet for the court of public opinion Schiller chose to cite other reasons, making it sound as though Rogue Amoeba violated an actual rule. The “without using approved APIs” seems meant to imply that there were APIs that Rogue Amoeba should have used, or that they used private APIs, when in fact neither is the case. It’s not clear to me why Apple decided to draw the line with this feature, when the now re-approved Airfoil Speakers Touch and some other approved apps also communicate via reverse-engineered AirPlay protocols.
Schiller also says:
Apple never said that we would pull the rug out from anyone, we in fact worked with this developer to ensure they update their app and remain on the App Store.
Recall that Apple’s first step was to pull the app, and it wasn’t until much later that it communicated with the developer at all. Schiller alleges that Rogue Amoeba violated an agreement, but Kafasis implies that Apple never specified what said violation was.
5 Comments RSS · Twitter
Gruber (unusually) says something insightful:
As I read it, rule 3.3.1 effectively means “You may not use private APIs, and you may not use public APIs to do things we don’t want you to do.”
That’s simultaneously unsurprising, and, a little crazy. Unsurprising because the implicit rule 0 of the App Store has always been that Apple isn’t going to publish an app they don’t want in the store, and that’s that.
As always, the written rules are irrelevant. The unwritten rules, enforced through silent gestures by the bouncer at the velvet rope, are the real rules. As Apple dares to put into writing:
This is a living document, and new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this.
Sticking to the rules is no refuge from the storm.
Heckuva game console they're turning all of their products into.
@Chucky Yes, I think developers should base their decisions on what they think Apple will do, not on what the rules actually say. This means that, near the border, some apps that would have been approved will not be written. Is anyone maintaining a list of the unwritten rules?
"I hope there is no relation between Paul criticizing Siri and Apple rejecting their application."
Well, that's the beauty of the "We don't need to offer no stinkin' explanations" application of the "rules" at the game console store, no? We'll never know in any provable manner. Unlike in the eBooks collusion case, they are smart enough to not leave email trails on stuff like this.
If Apple thinks you're looking at them funny, they can just have the bouncer at the velvet rope motion that you aren't to be allowed past. Hell, maybe they set aside Siri requests from all registered developers, and just sit around listening, drinking beer, and laughing and make their judgments based on that. Maybe they secretly turn on the iSight cameras of developers and base things on a mysterious dress code. Without actual rules to play by, it's a Hobbesian world out there.
In Cupertino's brave new world, developers serve at the pleasure of the King, as the saying goes.
[…] Schiller was already in charge of App Review, which is a disaster in terms of speed, and he has a history of making misleading statements when justifying the haphazard enforcement of the review guidelines. […]
