19
votes

I am working on app that can alert users for some critical things. I use local notifications to alert the user. On iOS, I find that the notifications will not ring if the phone is on vibrate. This is a deal-breaker for many users of the app but I have been putting that question off till now since I thought that iOS doesn't allow an app to play a sound if the app is in the background.

Music apps are able to play songs even when the phone is on vibrate by enabling the audio background mode but it doesn't allow you to schedule a song to be played at a certain time.

Lately I have seen that some apps are able to play a sound at a certain time even though the app is in the background. One such app is Alarmy alarm app. I don't think that they are playing the music via the local notification when the alarm expires because the music continues to play even after I clear the notification. From the local notification documentation, I understood that I am can't run any code when local notification fires till the user clicks on the notification. So, I can't start an audio player which may be able to play the sound in vibrate.

How are such apps able to play a sound even though the phone is on vibate and the app is in background in iOS?

2
may be this link will help something : stackoverflow.com/questions/24145386/…Hardik Bar

2 Answers

12
votes

There are few methods to implement this kind of functionality.For reference I recommend this link.

For actually playing the sound while the device’s ringer switch is set to vibrate

First off make sure to include the audio background mode in the capabilities, in order to play audio in the background.

Then,

Swift 4

do {
  try AVAudioSession.sharedInstance().setCategory(AVAudioSessionCategoryPlayAndRecord, with: [.duckOthers, .defaultToSpeaker])
  try AVAudioSession.sharedInstance().setActive(true)
  UIApplication.shared.beginReceivingRemoteControlEvents()
} catch {
  NSLog("Audio Session error: \(error)")
}

Here we set the shared audio session’s category to AVAudioSessionCategoryPlayAndRecord, so that we can play sound, while the device’s ringer switch is set to vibrate.

The .duckOthers is specified to make other audio quieter, if there’s any mixable audio playing, so that our alarm can be heard. You can leave that out or use another option, if you prefer a different behavior.

The .defaultToSpeaker is specified, so that the volume would go to the speaker, where it’ll be much louder and should wake up our user with ease.

beginReceivingRemoteControlEvents makes it so that the app handles the remote control options, like the play/pause buttons on the lock screen, in order to make it easier for our user to mute their alarm, once they wake up.

6
votes

The way this can be done (I have implemented this in my app) is by starting an AVAudioPlayer and specifying a specific time to play. So:

  1. Enable background audio in the app capabilities.

  2. Start and audio session with .playback mode, and start a player at the time you like it to play:

    do {
          //set up audio session
          try AVAudioSession.sharedInstance().setCategory(.playback, options: [.defaultToSpeaker, .duckOthers])
          try AVAudioSession.sharedInstance().setActive(true)
    
          //Start AVAudioPlayer
          player.play(at: time) //time is a TimeInterval after which the audio will start
        }
        catch {
        ...
        }
    

This does not play silence in the background, which violates Apple's rules. It actually starts the player, but the audio will only start at the right time. I think this is probably how Alarmy implemented their alarm, given that it's not a remote notification that triggers the audio nor is the audio played by a local notification (as its not limited to 30 seconds or silenced by the ringer switch).