Rogue Amoeba:
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.
You may be asking why Apple would want to prevent users from having this functionality. Only Apple can provide a full answer here. We do know that Airfoil Speakers Touch’s ability to receive audio directly from iTunes and iOS enabled some users to forgo purchasing expensive AirPlay hardware, hardware which Apple licenses. It seems Apple has chosen to use their gatekeeper powers to simply prevent competition.
While I sympathize with their plight, I don’t agree with Rogue Amoeba’s conclusion regarding Apple’s motives. I can’t imagine that AirPlay hardware licensing is a big-money business, and a thriving app ecosystem is certainly more important to the long-term success of iOS than AirPlay speakers. All other things equal, I’d usually expect Apple to prioritize third-party apps over third-party hardware.
So, why block Rogue Amoeba’s use of audio streaming? I suspect the reason is contractual. Perhaps the contracts for AirPlay hardware licensing include a clause in which Apple agrees not to implement a “stream to iOS” feature that would make “made for AirPlay” speakers unnecessary. Moreover, it’s reasonable to suggest that Apple might agree to prevent app developers from doing the same thing. In so doing, speaker manufacturers would get a little bit of protection for their investments.
Unfortunately, the folks who aren’t protected are app developers like Rogue Amoeba. If I’m right, then Apple knew all along that it was obligated to keep “stream to iOS” features out of the App Store, and could have made that clear in the App Store Review Guidelines. Doing so would have allowed responsible developers to avoid wasting time building a feature that could never be released. Just like hardware manufacturers, app developers deserve a little clarity and protection as well. Of course, clarity isn’t always possible, but when Apple’s contracts dictate the implementation of a rule, developers deserve to know what that rule is.