携帯電話や Wi-Fi 経由でオーディオをストリーミングするアプリをストアに提出する前夜に、アプリが拒否される危険性があることに気付きました。
このアプリは、既存のストリーミング アーキテクチャを持つラジオ局用であり、HTTP ライブ ストリーミング プロトコルをセットアップすると、ミックスに 5 番目と 6 番目のストリームが追加され、非常に複雑なセットアップになる可能性があります。そのため、ステーション側での複雑さを最小限に抑えるために、アプリ コードは現在iphone_radio オープン ソース ライブラリを使用してストリームを機能させています。そのライブラリの作成者によると、ストアにあるアプリRadio Javanで使用されています。
簡単なGoogleは、ビデオストリーミングのさまざまな拒否ケースを見つけましたが、オーディオの場合はほとんどありません. HTTP ライブ ストリーミングに関する Apple のポリシーは、オーディオに関して明確ではありません。
アプリがセルラー ネットワーク経由で動画を配信し、動画の長さが 10 分間または 5 分間で 5 MB を超える場合は、HTTP ライブ ストリーミングを使用する必要があります。(小さなクリップにはプログレッシブ ダウンロードを使用できます。)
アプリがセルラー ネットワーク経由で HTTP ライブ ストリーミングを使用する場合、64 Kbps 以下の帯域幅で少なくとも 1 つのストリームを提供する必要があります (低帯域幅ストリームは、音声のみまたは静止画像付きの音声である可能性があります)。
これらの要件は、Apple 製品で使用するために App Store で配布するために提出された iOS アプリに適用されます。準拠していないアプリは、Apple の裁量により拒否または削除される場合があります。
ただし、飛び出す 1 つの行は 64 Kbps です。現在のストリームは 128 Kbps ですが、それらを 64 Kbps に下げることは、HTTP ライブ ストリーミングに切り替えることに比べれば比較的簡単です。
アプリをそのまま (128 Kbps ストリーム) ストアに送信する価値はありますか? それとも、ライブ ストリーミング プロトコルを使用していないために拒否されることがほぼ保証されていますか? ストリームを 64 Kbps に落とすとどうなりますか?