From Apple:
9.4
We found that your app does not use the HTTP Live Streaming protocol,
with a baseline stream of 64 kbps, to broadcast streaming video, as
required by the App Store Review Guidelines.
This is not the first time we had this error. The first time we had this they mentioned the url that was giving the error and pointed us towards their mediastreamvalidator tool.
We fixed our .m3u8's, added a low bitrate stream, have run through all our url's with that tool, and they have all passed.
Upon resubmitting they gave us the error above, with no details. We've replied in the resolution center with the validation output attached and are currently waiting for a reply. Does anyone have any ideas of things we've missed that would not be caught by their validation tool?
Thanks.
You must include 64kbps or lower bitrate stream (usually audio-only or audio with still images) in your streaming contents.
Check the guide: HTTP Live Streaming Overview
Requirements for Apps
Warning: iOS apps submitted for distribution in the App Store must
conform to these requirements.
If your app delivers video over
cellular networks, and the video exceeds either 10 minutes duration or
5 MB of data in a five minute period, you are required to use HTTP
Live Streaming. (Progressive download may be used for smaller clips.)
If your app uses HTTP Live Streaming over cellular networks, you are
required to provide at least one stream at 64 Kbps or lower bandwidth
(the low-bandwidth stream may be audio-only or audio with a still
image).
These requirements apply to iOS apps submitted for distribution in the
App Store for use on Apple products. Non-compliant apps may be
rejected or removed, at the discretion of Apple.
Well, after finally getting through to someone at apple on the phone we got a case number and our app flagged for a fast tracked review. It was approved and is now available, despite there being no change whatsoever in the binary between the last rejection and this approval.
Related
OK, so I specified a UIRequiresPersistentWiFi key of my App's plist to YES so the iOS won't stop fetching the data when my app is in the background.
However, when the user uses cellular connection (not wifi) and my app is in the background, the download of the data is stopped after several minutes.
I double checked the docs and it seems there is no equivalent of UIRequiresPersistentWiFi for cellular network that I could set.
Is there any way I can make the connections over cellular network survive while the app is in the background? Any hints?
Cheers!
Updates:
I am making an Internet radio app. Stream is combined with mp3s which I request one after another (can't request them in advance, can't change server side). It works when my app is in the background and uses wifi. However, when using cellular connection the network requests are not performed after some time spent in the background. There is no place for changing the strategy. The app is in the AppStore and it had worked before. I guess they changed something in the new version of the system.
What is more I do not need throttling. My radio app has been already approved and is in the AppStore. The stream is sent with 128kb/s (that is the maximum) so that is not a problem. It looks like system silences my network requests (when on cellular network) after some time in the background. However, this only happens when I try to start the connection in the background.
Description:
App is in the background playing a mp3 streamed over cellular
network.
Mp3 ends
I request the URL to another mp3
The request is not performed*.
*works when using WiFi.
I'm fairly certain there isn't something like this for Cell networks. Here is my reasoning:
Cell service costs money. A LOT of money. Per minute. Wifi service does not cost money, in comparison.
AT&T does not have very much bandwidth, and charges users extra for extra bandwidth usage.
Apple is a company that wants to make the user experience as clean and nice as possible.
When costs are exorbitant through no fault of their own, users are angry and their experience is not nice.
If Apple lets you have a constant connection to the web outside of wifi range, the user's cost of service would skyrocket and they wouldn't know why. And if Apple gives programmers this ability, somebody would abuse it. So, I'm sure that Apple won't allow you to do that.
Why do you need a constant internet connection when your app is in the background anyway (unless, I guess, you're making an internet radio app)? Keep in mind that, when in the background, your app can be terminated without warning at any time. You may want to rethink your strategy if you can't find a way to do this. :/
I think there is no equivalent of UIRequiresPersistentWiFi, there reasons probably include the ones pointed out by Tusting2121.
But please note that UIRequiresPersistentWiFi is connected with energy saving. The wifi module consumes energy, so normally it is shut down after some time to save some energy unless UIRequiresPersistentWiFi is set.
Such enrgy saving, I believe, is not a case in cellular case.
And the fact that your connection disappears after certain minutes in cellular mode may be caused by something completely different that the copy of wifi energy saving mechanism you claim. See for example this article which suggests that you are obliged to throttle your 3G data flow.
Add audio to your UIBackgroundModes entry in Info.plist.
According to the Apple Docs: In your callbacks, though, you should do only the work necessary to provide data for playback. For example, a streaming audio app would need to download the music stream data from its server and push the current audio samples out for playback. You should not perform any extraneous tasks that are unrelated to playback.
You may also get some value out of the voip entry - you can setKeepAliveTimeout:handler: to have your handler called on a periodic basis to populate your data stream.
My app was rejected because one of the features is streaming Podcast audio from a website. Apparently, it may stream over 5MB/5 minutes which is against section 9.3 of the App Store Review Guidelines (https://developer.apple.com/appstore/resources/approval/guidelines.html).
Their suggestion would be to use Reachability to restrict that feature to WiFi. My question is, is there any other way to get around this? Perhaps to only let the user stream 5Mb worth of audio before displaying an alert to switch to WiFi? I don't see anything in Reachability about data usage... is there any other Framework that could keep track of data usage?
ASIHTTPRequest has inbuilt code to throttle bandwidth when the user is on 3G. This uses a modified version of the Reachability sample. The source is available, so take a peek if you want to try doing this yourself. It dodges the 5mb/5min limit by slowing down the download speed to a rate at which that limit won't be hit.
I think Apple's guideline is a reasonable one. It's not only to prevent users running up big data bills, but also to help reduce congestion on data networks.
As for your idea of letting user stream over cellular for 5 minutes, then prompting them to switch to wifi -- I think this would make a for a poor/annoying user experience, as opposed to just prompting them from the start to use wifi. If they use wifi from the start, they will:
1) have less probability of having choppy audio
2) waste less of their cellular data allowance/cost
3) not have a break in service after 5 minutes which might interrupt their flow, at which point they have to fiddle with their phone
I don't think any framework tracks the data usage for you (you get to do that yourself), Reachability is used to find out if you are on WiFi or 3G.
The docs don't seem to offer any guarantees - I'm just wondering if anyone's had any experience of uploading a large amount data after a user 'backgrounds' an iPhone app.
E.g., recording some audio or video and uploading it while there's the possibility that the user will start another app. Is is reasonable to expect to be able to be able to upload several MB of data in the background, perhaps using the VOPI UIBackgroundMode, which should keep sockets active?
First, uploading anything that is not VoIP data in a VoIP background mode violates Apple's guidelines and will probably get your app rejected. But you still have the option of using the normal background task completion API that gives your app another 10 minutes (at the moment, the amount might change in a future release) to finish a task like an upload.
If a foreground app uses a large amount of bandwidth, it is likely that the OS will give it priority over the background task.
Of course, you cannot rely on your upload being finished. If you run out of time, the system will notify you and you should try to resume the upload when the user reactivates your app. But you can't rely on a stable internet connection anyway, even if your app is in the foreground, so I don't really see the difference.
NO, this is not possible. i agree that it creates problems when you have a long operation to make but it is defiantly not possible.
I know nothing about iPhone development, but I am drafting a proposal for other people to do the work of creating an App that interfaces with existing systems and data.
I need to know if the 20MB cellular data download limit present on all apple produced apps is enforced by the SDK for 3rd party apps - i.e. If i develop an app that tried to download a larger file will it fail?
Context:
The data file we use is approximately 50MB and many of our customers work on the road and have no access to wifi. If the limit is enforced I need to be enable HTTP Range header support on our server and add this to the requirements for the App so that the file can be downloaded in 20MB chunks.
Thanks
No. The 20MB limit is one imposed by the App Store itself. The only restrictions seen in third-party apps are ones that the cellular provider wishes to enforce (which typically just means bandwidth caps or overage fees if you go over a download cap). That said, it may be useful to support HTTP Range anyway, in case the download is interrupted and you wish to resume it.
It is enforced; I did not understand your other points.
The limit exists for downloading both apps and media files (videos, podcasts, etc.), so I'd imagine it's limited for downloads within each app as well.
Our lovely app that downloads mp3s from our server into a local file on the phone then plays from that file was rejected for using too much bandwidth.
I understand the rejection (we are downloading rather than streaming) and don't quibble with their decision... our first priority was quality of user experience.
I am just wondering... what do I do now?
There are no hard and fast rules... Apple just says, "Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth".
Anyone have data on what Apple considers reasonable data transfer rates?
Should I fill up the buffer file in short spurts? Should stream the file at a constant rate (and how would I limit the transfer rate from within the app?)
Any and all suggestions are welcome.
Thanks
I have talked with Apple Developer support, and just FYI. You are only allowed to stream 1 MB per minute over the Cellular network. Support suggest that you test your app in the following way:
"The basic measurement methodology is to turn off all background updating (particularly Mail's automatic mail downloads and Calendar updates), reset the transfer statistics in "Settings:General:Usage:", and then launch your application. Let it run for a fixed amount of time (five minutes is reasonable), and then exit your application. Once you've finished the test, the numbers listed under "Cellular Network Data" in "Settings:General:Usage:" are what you should focus on reducing.
Using what I just described, I'd suggest 4.8 MB every 5 minutes as the guideline you use to ensure your application stays within our bandwidth requirements."
Hope that helps at least a little.
Have you considered HTTP Live Streaming? It's built into OS 3.0.
Basically, you split your media into small (say, 10 second) snippets and put it on a standard web-server. Then you create little text 'meta-descriptor' files in EXTM3U format that point out where the bits are. The interesting thing is that you can create multiple versions of each snippet at different bit-rates. So if your bandwidth is good, the iPhone player dynamically chooses the higher bit-rates but when it's low it automatically switches to the lower bit-rate version of the snippet. It does this on-the-fly to adapt to changing conditions.
So if you split your MP3 into multiple 10-second bits at say, 3 different bit-rates then when the user is connected through WiFi they get the high-quality stuff but if they're on 3G or EDGE they get progressively lower-quality (and smaller sized) content.
If this violates your downloadable media concept, then perhaps you can use the same trick and keep multiple size files for each connection type. Then if you're on WiFi (or get a fast turnaround on a heartbeat ping to the server) download the big file vs. medium or small size ones.
Here's a decent step-by-step on segmenting content. They focus on video but it should work with audio content as well.
I would suggest throttling the bandwidth on the network/http request when connected to cellular, and having no throttle on wifi.
A combo of using Reachability to detect the network status, and implementing your http request using CFNetwork with a sleep until the next second whenever you have already downloaded as much as allowed per second should get you there.
You should check out this project, either to use, or just to see an example of how to code this well:
http://allseeing-i.com/ASIHTTPRequest
The ASIHTTPRequest class implements this, using either the old or 2.0 version of Reachability, and also provides a class level throttle, so even if you have multiple concurrent downloads and uploads, so long as all of them go through ASIHTTPRequest, they will be properly taken together and throttled properly.
A bit more on how to use this here:
http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
Lots of good stuff in this (and no, I am not the author of any of it).
On a more serious note, what is it trying to do? There are many markets for iPhone outside of the US which don't have good download rates for phones, nor are the download cap sizes good, so having an app do lots of downloading isn't a good thing.
Could you possibly drop the data rate on your mp3 or some such? Make it optional to do the downloading with a warning that it will use your download?
YOu could not download the mp3 unless you are on wireless, and inform them of that. If you the mp3 are too important, then just tell them it only works on wireless, or include a few mp3 on the device. But 30min of mp3 is ridiculous, that is about what, 30meg.... think about it, 30 meg is just too much.