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.
Related
shortly after this post I managed to convince our team to use push notifications instead of polling! We will use AWS Pinpoint, which uses APNs for IOS. So far everything is amazing, but we are missing a crucial functionality:
We need to make sure that push notification is delivered if the app is in foreground even if user has disabled notification and has disabled background app refresh for our app.
I understand that push notifications would if app is in background and user has disabled background app refresh, but why it affects foreground? Otherwise, polling is still essential, because it does work if user is in foreground...
Perhaps I am mistaken (I hope so), but I have tested various cases and could not solve this particular case.
If the user has disabled notifications, you will not get notifications.
Also, just a caution, push notifications are not a guaranteed quick delivery. If your connections are odd, they can come slowly. Also, if you move from cell to wifi or vice-versa it can make weird things happen with the notifications.
One thing you can try-- don't let your app run if they have disabled notifications. If it is required for your app to function properly, check for enabled notifications in your app delegate at applicationDidBecomeActive
I am trying to implement silent push notification in my application where I need to update some data in the server when silent notification comes. I am using Pushkit and it uses VoIP certificate for silent push notification but the app has been rejectd by Apple saying that "I can't use VoIP" certificate. It seems that apple has rejected it as I don't have any VoIP call functionality in my app. In that case how can I implement silent push notification so that my app gets activated even if it is not runnning(not even in the background) and I can update the server?
From my experience, iOS respects user's choice, so in case the user has killed the app, it will remain killed - no silent push notification will wake this app. VoIP is an exception to that, but as you wrote, it should be used only in VoIP apps. This makes sense, consider it a platform limitation: thanks to that user have some control over what is actually running on the phone, the device consumes less battery and lastly, foreground/system Apps has the most CPU time to utilize.
There are few techniques to work with data in the background:
Content-available push notification: will wake up the application in case it is suspended, or startup it in case it has been killed by the system/crashed. Note, that this only opens a 30-second window and amount of notifications is throttled by APNS.
Background fetch capability will act in a similar manner.
Background task to finish existing task - but this is only used when app is moved to the background.
If you need App to send updates to the server, I believe above should be sufficient (unless your app is spying on a user, it should have all relevant data available once the user finishes interaction with the App).
If you need a server to send data to the App, use silent push notification (or background fetch for periodic pulling), or in case this data is critical to the user, you can present him a remote notification - if the user considers that an important update, he will open the app.
As stated clearly in Apple docs, beacon ranging can be done in background for a short period of time only, say up to 10 seconds by default or up to 3 minutes with the help of background task expiration handler. As per my app's use case, app needs to do beacon ranging for every 15 mins until user exits the region. I am thinking of using background push notification(silent push notification) for this purpose(assuming data connection is available on the device always). So the flow goes like this, upon user entering the region, app calls the server with device token, server sends silent push notification for every 15 minutes. Once app received push notification, it does beacon ranging within allowed period of time if needed. Question I have here is whether using push notification in background mode to do ranging is legal, will I face any issues during app store submission.
Note: Also I need to enable BLE background mode for the app, to read some characteristics from some BLE devices.
Technically you can do it, but Apple mostly rejects such app. One important thing you have to consider is that, if the app is manually killed by the user and not running in the background, then the app won't wake up with silent push notification. There is a workaround if you have VoIP push notifications it will wake the app even from the terminated state. But you might need strong reason while pushing it to AppStore.
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 minutes.
another thing is that silent push notifications are rate limited as described http://asciiwwdc.com/search?q=push+notification, so I'm not sure if they will be sent every few minutes.
Apple says that;
Silent notifications are not meant as a way to keep your app awake in
the background, nor are they meant for high priority updates. APNs
treats silent notifications as low priority and may throttle their
delivery altogether if the total number becomes excessive. The actual
limits are dynamic and can change based on conditions, but try not to
send more than a few notifications per hour.
You might want to see this article. The user talks about apps that use silent notification for triggering location tracking. But eventually it's a hack that Apple may reject some time in the future, so it's best to have a contingency plan. FWIW so far I haven't heard anyone reporting rejection.
So the official answer is don't do it, as for the why you can refer to Ashish's answer. The unofficial answer is if you can't change your business logic then do it at your own risk.
The iOS application I'm working on does the exact same thing with the exception that I'm using recording instead of a Beacon. Recording by iOS standards gives more issues in pushing the app to the app store.
But Apple did not reject this app. Although we still are facing some issues but they don't relate to your problem.
You can follow such a tutorial for further help apart from the answer you were looking for : iOS Push Notification Demysitfied
Also, I've done firing of local notifications, while the application is in the background. BLE even works if the app is killed by the system, when the OS receives some communication from your peripheral or central, iOS wakes your app up and executes the desired function, before putting your app back to sleep.
We need to calculate some numbers and display the calculations in local notification on receiving a silent push message from the server.
This works when the app is active/open in background.
This does not work if the app is killed/not in background.
So is there anyway to perform tasks when app is closed and the silent push arrives?
FYI I have enabled background fetch.
Apple's Documentation states:
Note: The ability of APNs to deliver remote notifications to a nonrunning
app requires the app to have been launched at least once.
On an iOS device, if a user force-quits your app using the app
multitasking UI, the app does not receive remote notifications until
the user relaunches it.
The second sentence pertains directly to your question; likely not the answer you hoped for...
↳ Configuring Remote Notification Support
My app makes use of push notifications to alert the user when they receive a message. Due to the nature of my server and also due to encryption, the server does not know what the message is, only the iPhone is able to decrypt it. However, i would like the message to show in the notification. So i need processing time after a silent push to download and decrypt the message then use a local notification to tell the user
However, iOS doesn't allow processing time for killed apps, only for foreground ones or ones still in the app switcher. How can i workaround this issue?
One solution i have found is PushKit. This seems to relaunch apps even if they've been force quit. However, it only does this for VoIP apps, my app is not a VoIP app and I think App Review will reject it if I use PushKit
It is exactly as you described it and there is nothing to add. If the app is killed, you have no way of processing a silent push notification other than PushKit, but if you use PushKit, your app won't go through the review if it doesn't implement VoIP.
Your best option is to send push notification with a generic text (e.g. "You have a new message") instead of a silent push notification, that will serve as a fallback for the case that the app was killed. If the app was not killed, you can discard/remove the remote notification, download and decrypt the message and show a local notification with the actual message. If the app was killed, the remote notification with the generic text will be shown instead and the user will at least be notified that there is a new message.
Add this behavior to the FAQ of your app to encourage users to not kill the app. There is no reason to do this on iOS anyways, so if a user kills an app, he shouldn't expect that it works as desired.
Addition on misusing PushKit for this:
If you misuse a functionality/service for something it is not intended to be used for, your app will probably be rejected. So if you enable VoIP background mode, but your app doesn't provide any VoIP functionality, it is pretty obvious.
From the App Store Review Guidelines:
2.16 Multitasking Apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion,
local notifications, etc.