My app must be able to play alarm sound no matter what upon receiving push notification.
Is there a way to configure audio session to play sound:
and NOT obey silent switch (route may be respected)
upon arrival of push message (can be silent) and if app is in the background or even if killed by the iOS in the meantime ?
Sound is played even if user uses any other audio app (unconditional mix).
I do not need to publish this app to AppStore (only for my private usage), so private API is an option.
For those who may tempt to propose UILocalNotification: those are not suitable in my case since they must obey silent / ring switch.
If you don't want to use UILocalNotification, there is the option described here:
http://oleb.net/blog/2014/02/alarm-clock-apps-ios/
In brief, if you opt-out of iOS's multi-tasking, and you lock your phone with the app running, you can continue to run custom code:
If you do not want your app to run in the background at all, you can explicitly opt out of background by adding the UIApplicationExitsOnSuspend key (with the value YES) to your app’s Info.plist file. When an app opts out, it cycles between the not-running, inactive, and active states and never enters the background or suspended states.
However, if that isn't appropriate for your use-case, you might be able to use UIBackgroundModes with remote-notification to wake up your app when it receives a push notification, but then you'd have to have your own server infrastructure to keep track of your alarms. Even then, I'm not sure if you could start playing a sound while your app is in the background...
Related
I want my app to be able to run some code every 5 minutes or so when it's inactive/suspended and the user is doing other stuff on the phone. Is there a way to accomplish this?
There is a way you can run code in background, although I would not recommend doing so every 5 minutes:
If your app’s server-based content changes infrequently or at
irregular intervals, you can use background notifications to notify
your app when new content becomes available. A background notification
is a remote notification that doesn’t display an alert, play a sound,
or badge your app’s icon. It wakes your app in the background and
gives it time to initiate downloads from your server and update its
content.
Essentially, you can send push notification that would look like the sample here:
{
"aps" : {
"content-available" : 1
},
"acme1" : "bar",
"acme2" : 42
}
The content-available flag lets the push notification wake the app up in the background.
You cannot include any alert field or anything that would indicate it should be a visible notification or else this flag would essentially be ignored from my experience.
You would then handle this here: application(_:didReceiveRemoteNotification:fetchCompletionHandler:)
Basically got this whole answer straight from the docs here: https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app
the system may throttle the delivery of background notifications if
the total number becomes excessive
The above quote is why I wouldn't recommend doing it every 5 minutes.
I don't know exactly what you are trying to accomplish so I do not know if this would suit your needs or if this is the optimal answer for you without more details.
In a word, no.
Apple is very strict about when and where it lets apps run in the background. Normally you get told when you are being swapped to inactive, and can request background time to finish what you are doing. The time you get is 3 minutes at most, if memory serves. After that you get suspended (in memory but not receiving processor time) and can get terminated at any time without warning once you're suspended.
Apple does allow a tiny subset of apps to run in the background indefinitely, but is very strict about which apps qualify. Turn-by-turn navigation apps, music apps, and VOIP style communications apps are the only categories I remember.
In my app, I used VoIP notification to play a long alarm on app not running state as per suggestion Silent Push, But app got rejected in the following points
Your app is not in compliance with Guideline 4.2.1 using the VoIP API in a manner that it is not intended.
2.5.4 Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. If your app uses location background mode, include a reminder that doing so may dramatically decrease battery life.
Is there any way to rectify these issues or would be good if we get any alternative to play a long alarm on push receive in app not running state?
I beleive, UNNotificationContentExtension would help to show our custom notification on push receives but how to play automatic audio on push receive,
Can we handle in push message sound key?
or
Can we do this by default UNNotificationContentExtension methods in
mediaPlay() mediaPlayPauseButtonFrame()
But there is no way to play automatic audio here. please correct me if am wrong.
My requirement will be, I need to play a long audio in any app state and audio should stop on user click of stop button or notification(it usually launch our app).
You can't use background location/ VOIP for other purposes, so if you are using them just to keep your app active in the background, Apple will reject it.
Use them in your app only when it is directly relevant to the features and services provided by the app. Location-based APIs/VOIP shouldn’t be used to provide emergency services or alarm systems, etc. Ensure that you notify and obtain consent before collecting, transmitting, or using location data. If your app uses background services, be sure to explain the purpose in your app. Refer to the Human Interface Guidelines for best practices on doing so.
You can use sound key in your push but audio can only be played for maximum 30 seconds. There's no way like audio should stop when user taps on notification.
My goal: implement sleep function in my music audio player. If user chooses say 30mins sleep time then the app should wake up and stop the currently played music.
Problem: [self performSelector:#selector (onTimer_sleep) withObject:nil afterDelay:sleepIntervalInSeconds]; does not work once the phone is locked;
My try: use UILocalNotification. This however works only if the app is foremost and visible when the system delivers the notification.
What would you recommend for my use case? Should I implement background mode? Which bg mode would you suggest, "Background fetch"?
Short answer: You can't. Apple severely limits the apps that are allowed to run in the background.
If your app is a music playing app that supports playing from the background then you are all set. That is one of the small list of apps that are allowed to run in the background for more than a couple of minutes. While music is playing in your app you should still get background time.
As you've discovered, local notifications only get delivered if the user taps on them, or if the app is running in the foreground.
You could set up a server to send silent push notifications, but that would require a network connection, and push notifications can't be timed very precisely.
Can I play AVAudioPlayer when in the app is in background using silent push notification ?
My current implementation is like this :
Send silent push notification
didReceiveRemoteNotification:fetchCompletionHandler: is triggered
and create the session then play mp3 from there.
The issue is that the session seems to be taken away when your app is not active for quite a time (like one night) and AVAudioSession is not given if you request it from background mode, so the AVAudioPlayer won't play the mp3.
I'm developing an alarm app for emergency things, so the app need to play an audible sound even if the phone is muted and locked.
Anyone has been encountered any similar implementation?
The solution in your case would be to use "audio" setting from the UIBackgroundModes key, which effectively tells the system that the app's main purpose is to play music in the background: "The app plays audible content to the user or records audio while in the background". See this for details: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
However, it seems that Apple will reject "alarm apps" that use this approach as alarms do not play constantly and do not qualify as "audio apps". See this answer: Why did my app get rejected because "Multitasking apps may only use background"?.
You can try to "play" silence most of the time, but they will reject it either.
To summarize, you can implement this Alarm App technically, by using silent push notifications and UIBackgroundModes key, but this method is against Apple review policies.
Is it possible to keep an iOS app in "Background" state by sending it a silent push notification every few seconds? I want to run background tasks on a regular interval and this seems like a viable solution. If so, is this acceptable under the App Store terms of use?
The app I am planning to build would rely on this functionality and I am concerned that Apple will reject it from the App Store.
Specifically, it’s this section in the guidelines that I am not sure about:
5.1 Apps that send Push Notifications without first obtaining user consent, as well as apps that require Push Notifications to function, will be rejected
Technically my app could be used without allowing push notifications but it wouldn’t serve its primary function of recording data in the background.
In iOS7 additional background modes were added, you can check out the available background modes here.
IMHO, if you misuse one of the background modes, the app will probably be rejected, saying that , i don't think silent push notifications were meant for: keep an iOS app in "Background" state by sending it a silent push notification every few seconds.
another thing is that silent push notifications are rate limited as described here, so i'm not sure if they will be sent every few seconds.
maybe you can use another background service
This is only possible via Cydia. Which means you will need to have a Repository, and jailbroken device for this to work.
The App Store will surely reject this, as it forces other apps to work in the background.