When I receive VoIP push notification while app is removed from the background (using developer APNS), my app wakes up for like 10 minutes.
When I do the same thing, just this time using production APNS, my app wakes up for 8-10 seconds.
What's the trick there? Why production version of the application can't be woken up for at least 30 seconds? Is there any way to extend wake up time, since 10 sec is not eough for all work I have to do?
EDIT
At the end background time wasn't problem. My app was crashing when completely removed form background and woken up by voip notif. I was thinking that it wasn't crash but limited execution time. When I fixed that crash everything was working as it should.
If you want to invoke your app in background while app is in terminated state. Then you can keep Local notification based on pushkit payload.
Also keep sound file in local notification.
So your app will be active in background even if app is been terminated.
App will be active upto local notification sound plays (Max 30 seconds).
Within that duration achieve your things.
Note Your app must have valid category and permissions from Apple to consume pushkit silent notification. Because pushkit is strongly recommended for VOIP based apps only. If your app is not VOIP based then contact Apple for required permission.
Refer pushkit example if you are not aware.
https://github.com/hasyapanchasara/PushKit_SilentPushNotification
Related
I am working on a web view app. I want to do an API call after every 10 seconds. How can I call the API in the background even if the app is killed and it is running in the background?
You can not do any action(can not compile a single line of code) when the app is killed. you have the control only in foreground and background state of the app.
Notifications can be received even after the app is killed, because notifications are not a part of the app. Notification comes through Apple's push notification servers(triggered by the backend of your app which is still online.)
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.
Like many here, I was looking for a reliable way to deliver push notifications to an app for background processing. I finally decided to use PushKit and all works well and the app was accepted into the AppStore, even though it's not a VoIP application. I'm using the AWS SNS (Simple Notification Services) to handle the backend push processing. However, even VoIP notification delivery will be throttled by iOS if you send excessive push notifications. As a simple test, I can send several VoIP notifications over 2 - 3 min and they will deliver promptly and processed by the app in the background. After I wait about 10 minutes (after locking the iPad and waiting for the application to be put to sleep by iOS) a subsequent VoIP push won't be delivered promptly by iOS. AWS is pushing the notification, but iOS is not delivering it to the app. I know this because as soon as I plug in the device, the notification is processed by the application. As an aside, if the device is left plugged in, all notifications deliver and process promptly.
So my question is this: Have others noticed this behavior with VoIP pushes also? Even though the iOS docs indicate that VoIP pushes are delivered immediately, it appears that iOS does throttle them if it considers the pushes "excessive" over some period of time.
I guess, When you keep your app in background then you receives push notification. but when your app is in terminated then don't receive push notification.
Possibly your app gets crash when it is in killed ( terminated ) state.
Pushkit silent notification is always with higher priority and works well all the time.
Try below things to find out cause and solution.
(1) Debug your app in killed ( terminated ) state, like app is crashing or not
(2) Send silent notification with simple php code using pem and certificates ( Both case background and killed ( terminated ) )
(3) Check pushkit integration steps, if your app is not registered for VOIP, then it would not receive silent notification.
Debug pushkit notification in terminated state
Put debug pointer on delegate methods
Go to edit scheme
Select run option then Launch -> Wait for executable to be launched
Send push kit payload from back end
Once you get payload on device
it will automatically invoke and debug pointer will invoke at delegate methods.
Refer some material
I want my iOS app to know when a specific date and time arrives without any failure. Now this time can be in days/weeks/months and my application can be in backgorund Or in terminated state.
So there are following options:
a. Local notification -- but it doesn't notify when my app is in background.
b. Silent Push notification -- it will work but it requires us to built server for same.
Is there any other option with which we can achieve same?
There is no way you can achieve this,
Your options are :
1) By using local notification like schedule notification on particular time and store that time and related activity in userdefaults. whenever app state changes to background to foreground in appdelegates - (void)applicationDidBecomeActive:(UIApplication *)application method write a code to handle desired functionality.
2) Silent push notification, which works only when your app is in background/minimized state. Once your app is Killed(swipe up from multitasking), even silent push notification cannot wake up your app.
3) To overcome the limitations of silent push notifications, Apple introduced Pushkit Notifications in iOS8, for voip apps like whatsapp, Skype, etc, in which push kit notification once received, wakes up your app even it is terminated or not running in background. Again you cannot use Pushkit unless you are actually using voip.
No. Sounds like you have to use push notifications.
This is the only thing that would work if your app is terminated.