I've been pouring over all documentation regarding background states and permissions for playing audio in iOS and I can't figure out how a particular app is able to seemingly wake itself at a specific time in the future and play non-bundled sounds. I'm looking into the issue because I'd like to add this functionality (like many others I've seen) to an app I'm building.
The app in question is "Alarmy" -- formerly "Sleep if you can." It's an alarm clock. Unlike most other alarm clocks in the app store, it is able to play an iTunes song as an alarm sound without being in the foreground at all. It can bypass the ring/silent switch, increase volume to max, and play a preselected song from a local iTunes library when it is seemingly (or should be) in a background state.
I don't know of any way to investigate what Alarmy is doing while waiting for an alarm time, but I can see that it does have location services enabled, cellular data enabled, and background refresh enabled. However, even with all of these turned off in settings, the alarm still works and plays an iTunes song! I have to assume as well that Alarmy isn't playing silence until the alarm time since it wouldn't have gotten through Apple's submission process (or could they just have missed this, and the playing field is now totally uneven).
It does have a feature that seems a little out of place -- the app displays weather information. This isn't necessarily complete fluff -- I can see some value in that for an alarm app -- but is it possible that they're querying some weather API at short enough intervals to keep the app awake in the background until the alarm time? If they are, what would that look like? Furthermore, weather APIs are free to use up to a certain number of queries, but they have a lot of downloads and I assume a lot of queries. For a fixed price paid app with no IAPs, that doesn't seem like a great business model.
So, to wrap up, IMHO, this feature can't come from any Background Audio permissions since the app isn't actively playing audio when it enters the background (unless its silence and they simply got lucky and slipped through the submission process); it may come from continually refreshing the app in the background for location/weather services (and then via a simple timer counting down to the alarm fire time) but the feature still works when background refresh and location services are disabled for the alarm. Could it be that the permissions are there, so even though the app isn't allowed to access the location information, the iOS still allows it to be active in the background?
One last thought: is there a silent push technique whereby they may be pushing a notification to the app at the time of the event and checking to see if it is time for the alarm tone to play? Shot in the dark there...
Any insight into the matter would help a ton! I'm pulling my hair out! I can edit this post and add more information -- i.e. what resources I've already looked at -- if you like, but I'm fairly certain that I've looked at every possible resource out there. Again, tremendous thanks for any help.