4

We are developing application which rely on new IOS7 functionality - remote-notification background updates.

According to docs system can "skip" calls to didReceiveRemoteNotification:fetchCompletionHandler: if it finds that background processing power-consuming and lengthy, etc and we see this in practice - user can get push notification on the screen, but calls to didReceiveRemoteNotification:fetchCompletionHandler: are simply not happening at all

The question is - how we can check what happeping in ios with push? is there some ways to see internal system logs with real information from ios services? We need this for debug purposes of course, not in released application. just to double-check and fine tune our background processing. There is should be the way for developer to see what is really happening on device.

I found application "appswitcher" that shows similar stuff, but on ios7 it shows only active application logs (appswitcher itself), not system-wide. so it is useless for us...

To be clear: push notifications are working correctly, they are always received by the program in Debug mode for example. But in release/adhoc build we see that some notifications are sent to applications (waking it from background) and some are not. Documentation stating that fetch callback is used to calculate cpu/data usage and ios reserve right to "skip" notifications when it feels to do so, we just want to find the way to see is this is the case

Any help is welcome

Wain
  • 118,658
  • 15
  • 128
  • 151
IPv6
  • 405
  • 4
  • 17

2 Answers2

2

I've never tried it but I saw this a while back. By looking at it, it seems like it will help your case but unfortunately, you gotta give it a try to find out if its worth it or not.

https://developer.apple.com/downloads/index.action Go to that website, and login using your developer account. Go to page 2 (or find Oct 4, 2013 post Bug Reporter Logging Profiles (iOS)). In the description, Apple has a link that tells you how to use these profiles. As the title of that post suggest that it is used for bug reporting, hopefully it gives you some details so you could fix your bugs.

Try it and see if it works and let other people know if it's useful or not. Since it says 'Logging', my guess is that it will output detail info on the console about push messages and not secretly log and sends the log to apple.

chuthan20
  • 5,389
  • 1
  • 17
  • 21
  • Thanks a lot!!! Seems like this is "right way" to low-profiling this things, intended by Apple... just what i need. https://developer.apple.com/bug-reporting/ios/push-notification/ states that it is not valid for ios7 yet, but i`ll give it a try – IPv6 Nov 22 '13 at 09:16
  • This is great information, but just for the record the instructions on using the test currently say this: "The APNS logging profile currently does not work with iOS 7." There is a note at the bottom of the instructions on yet another resource, TN2265 here: https://developer.apple.com/library/ios/technotes/tn2265/_index.html – David H Nov 22 '13 at 13:32
  • TN2265 has lots of really good info, including another testing profile, PersistentConnection, that also can provide a wealth of info on tracking iOS's success and failure in retrieving notifications. Evidently some networks may block port 5223 in which case no notifications will get delivered. – David H Nov 22 '13 at 13:44
  • In the end: We managed to get usefull info with "Battery life" logging (from https://developer.apple.com/bug-reporting/ios/battery-life/). It contain information about received notifications and what applications were waked up to handle them. in fact all application state switches are logged here too, so it is usefull to track thing down – IPv6 Nov 26 '13 at 10:35
1

Firstable you need to check if your push notification working correctly. What i would do is temporary disable background fetching, and simply check if i get push.

If everything is ok i will turn background fetch back in Capabilities and try to send one in Debug. Even app is in background you can still have a breakpoints. If method is not called try look at the console.

I think you have a problem with push notification other than backgroundFetching.

If you are willing to try what happen when application is not in background mode but wass 9-killed you should put NSLogs in method. If you see NSLog in console then (Xcode -> ⌘⇧2 -> your device (connected) -> Console) you're good to go.

The production console is in background fetching useless to you unless you put NSLogs in your methods. But then you can only check if you successfully enter method and log a parameters.

Jakub
  • 13,712
  • 17
  • 82
  • 139