One of the biggest problems with creating a network-based app is debugging issues that only show up in the field. While you can and should test your app in a wide variety of network environments, it’s impossible to test in all of them. Thus, your users will inevitably report problems that you can’t reproduce yourself.
If you’re working with a user who is both technically capable and willing to invest their time helping you debug the problem, you can ask them to run complex diagnostics on your behalf. For example, you could have them take a packet trace or set up a debugging proxy (both covered in QA1176) so that you can see exactly what’s happening on the wire. However, you may not always be this lucky.
The alternative is to add debugging infrastructure to your app. That is, log the network requests you make, the responses you get, detailed information about errors, and so on. You will then need a mechanism for the user to extract that log and send it to you.
As you design this infrastructure, keep in mind the following:
It’s a very bad idea to log secret information, like passwords, authentication tokens, and so on. Keep in mind that the user might send you the log over an insecure channel (like email).
Be very careful about logging private information. That can be the right thing to do in some circumstances, but make sure you’re users are aware of what you’re doing.
Note For advice on privacy best practices, see WWDC 2016 Session 709 Engineering Privacy for Your Users.
Is it appropriate to log all the time? Or do you want a preference to enable logging? The former is more useful if the problem is hard to reproduce; the latter is less code and generally more efficient. Perhaps a combined approach (limited logging by default, with a preference to enable more) might work best for you.
Do you want to make it really easy for users to return a log by, for example, adding a Report button to any error dialogs? Or do you want to provide a UI that’s less obvious, so it’s mainly used by folks who’ve contacted you for support?
On iOS, in-app email (MFMailComposeViewController) is a great way to allow the user to send you a log, but there are other approaches you might use.
Do you want to encrypt the log? That’s good if the log is sent to you over an insecure channel, but users may have concerns about what’s actually included in that encrypted log.
Do you want to log to disk? Or just to memory? The former tends to be more expensive but it’s helpful when debugging a crashing problem.
If you do log to disk, make sure to put a limit on the amount of disk space you use.
Apple has recently introduced a new logging architecture. See WWDC 2016 Session 721 Unified Logging and Activity Tracing for an overview of its capabilities. You’ll have to evaluate for yourself whether this is sufficient for your requirements, or whether you want to write or acquire a custom logging library.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = “eskimo” + “1” + “@apple.com”