bfarrellforever's comments

At first, yes, we were definitely in the wrong. according to this directive we weren't aware of. We didn't have the low bitrate stream. But after we got rejected the first time, we fixed that and continued to be rejected. Once we got a hold of someone real at Apple they admitted the mistake and that's when we found out that they were trying to test our streams and giving us the form-letter rejection.

Here's what happened with an app I was working on: I was working for a startup with another vendor who has some great experience making iOS apps and our client was a TV network. We offered full streaming episodes in the app. Like you'd imagine, the network wanted to protect the streams so nobody can steal the content. So, we encrypted the streams and had an authentication mechanism (which Apple recommends anyway)

Come launch time, the app was solid, clients were happy and we submitted to Apple.

Rejection #1: You must have low bitrate audio only streams for the content.

WTF? Who wants to watch audio only TV? Oh well. Added a new encoding profile.

Rejection #2: You must have low bitrate audio only streams for the content.

What? We did that. We had back and forth with Apple for months. Stakeholders are getting pissed off. One of the higher ups steps in who apparently has enough clout to reach out to a real person at Apple.

The real reason for the rejection was that they watched what streaming URLs were being loaded, tried them out and they didn't work. Yah, they didn't work for them because they were encrypted/protected. As a result we got a form letter rejection complaining about the lack of a low bitrate stream