didReceiveRemoteNotification:fetchCompletionHandler not being called when app is in background and not connected to Xcode
Issue have been fixed in iOS 7.1 Beta 3.
I double checked and I confirm it's working just fine.
application:didReceiveRemoteNotification:fetch
CompletionHandler Not Called
application:didReceiveRemoteNotification:fetchCompletionHandler:
gets called even if the app is suspended, not running at all, backgrounded, or active. Also worth noting that the method is iOS 7 only. Here is the apple documentation.
HOWEVER if the app was forcibly closed (i.e. by killing with the app switcher), the app will not be launched. (see SO answer)
EDIT: I checked this again on iOS 7.1 to see if they fixed this, but it still remains the case that if the app is killed manually, app will NOT be woken up and application:didReceiveRemoteNotification:fetchCompletionHandler:
will not be called
When receiving the push, the app is only woken up only "if needed" to call the application:didReceiveRemoteNotification:fetchCompletionHandler:
method (i.e. you have to set the "content-available" flag within the push notification payload. See SO answer). The method will be called again if the user then opens the app by tapping the notification.
EDIT: haven't checked this on iOS 8. Has anyone else?
Why is didReceiveRemoteNotification not called but didReceiveRemoteNotification:fetchCompletionHandler called when my app is in the foreground?
You should use the callback version unless you need to support ios<7 (when it was introduced). As you are using Swift I expect that is not the case.
The older method goes back to ios3 and is deprecated in all but name:
Implement the
application:didReceiveRemoteNotification:fetchCompletionHandler:
method instead of this one whenever possible. If your delegate implements both methods, the app object calls theapplication:didReceiveRemoteNotification:fetchCompletionHandler:
method.
The older version will also give different results depending on whether the app is live (foreground or background) or launches from a cold start. In the latter case, it will not get called, and you will need to intercept the launchOptions
dict on didFinishLaunchingWithOptions
to get at the infoDict:
If the app is not running when a remote notification arrives, the method launches the app and provides the appropriate information in the launch options dictionary. The app does not call this method to handle that remote notification.
Use the callback version. It works for all cases. You don't have to use the completion handler/block, in which case the effect is the same (well, more consistent with the newer method).
update
sorry, Apple says you do have to call the completion block "as soon as possible" - you have 30 seconds to do so before the OS gives up on you. This might be the source of your warning.
As soon as you finish processing the notification, you must call the block in the handler parameter or your app will be terminated. Your app has up to 30 seconds of wall-clock time to process the notification and call the specified completion handler block. In practice, you should call the handler block as soon as you are done processing the notification.
So call the completion block:
completionHandler(UIBackgroundFetchResult.NoData)
I have been using this method without calling that completion block and haven't experienced any problems, but i will add one now just to be safe. Apple suggests that if you don't, your app won't get foregrounded but I have not seen that in practice.
Related Topics
Dateformatter Returns Unexpected Date for Timezone
Xcode 8.3/Xcode 9.0 Refresh Provisioning Profile Devices
Is There a Public Way to Force Mpnowplayinginfocenter to Show Podcast Controls
Maskstobounds VS. Clipstobounds
Format Uitextfield Text Without Having Cursor Move to the End
Navigation Bar Under Status Bar After Video Playback in Landscape Mode
Writing an iOS 8 Share Extension Without a Storyboard
Scrolling Slow on Mobile/iOS When Using Overflow:Scroll
iPhone iOS Will Not Display Box-Shadow Properly
iOS Safari Memory Usage with "-Webkit-Transform"
How to Prevent iOS 13 Dark Mode from Breaking Emails
iOS 9 '-Webkit-Overflow-Scrolling:Touch' and 'Overflow: Scroll' Breaks Scrolling Capability
Adding Convenience Initializers in Swift Subclass
Storing Authentication Tokens on iOS - Nsuserdefaults VS Keychain