The classic iOS way of logging debug messages is to use the built in
The dissadvantage of this method is that when your application is ready for release, you have to manually remove them. Alternatively, you can include them in
An improvement to the above method of debugging is using the following
Then sprinkle them in your code:
If you need granular debug levels, one of the best options is the logging framework CocoaLumberjack. Using Cocoapods, it’s only one line of code (TM):
Then in your code:
Then in your
AppDelegate.m you can set the desired log level:
One powerfull feature of CocoaLumberjack is that you can define your custom log levels, so you can separate logging of different parts of your project:
Which then can be enabled or disabled by by setting the corresponding
So far, so good. When your friends are testing your app, your logs are saved on the device. If you’d like to access them, you can connect the device to your Mac and explore them in the Window > Devices menu (shift + cmd + 2).
One improuvement to the current setup would be send your logs to the net. For that, we’ll be using two more frameworks Antenna and DDAntennaLogger.
Antenna is responsible for shipping the logs to your server,
DDAntennaLogger is a custom logger for
CocoaLumberjack. Once you plug them together, you’ll be able to have your logs automatically sent to your server.
Then in your code:
The server should have this end-point setup. You can save them to file, or db, or forward them to the logger of your choice.
And change the link to the remote logger to:
There is one more bit to change, switch from http to https.
Now, there are two possible scenarios. The trivial one is when you setup the logger on the same server where you already have a SSL certificate setup (e.g. https://api.yourserver.com) or you own a wildcard SSL certificate. Everything up to this point should work great together.
Now let’s try to use a self signed certificate. Generate a SSL self signed certificate for 10 years:
Configure Apache to use that then see what happens.
The other one is when you try to use self-signed certificates, at which point you’ll get the following error message in the logs:
Which pretty much means that your setup is not happy with the self-signed certificate.
Because we’re controlling both the server and the client, we’re able to use SSL pinning to overcome this issue. The basic of SSL pinning is we distribute our public key certificate with the application and configure our logging setup to authenticate using this certificate. TODO: try to add some analogies.
Convert the public key certificate to binary DER:
Configure your request operation manager to use the public key certificate, which you already dragged in your project:
Then you setup your Antenna logger to use a different channel:
If your end-point is using authentication, you can set it up in the request operation manager, after setting up the security policy:
Now, the earlier error message should dissapear and you should see the logs comming to your server.
If you’re asking, why would you like to send the debug logs to a server, there are several reason. First of them is to get debug info from your beta builds, when your testers are not in the same city as you. Second of them is to corelate data coming to your server, with data sent to your iPad with debug messages from your iPad.
- CocoaLumberjack by Robbie Hanson & contributors
- Antenna by Mattt Thompson
- DDAntennaLogger by Giovanni Lodi
- Rack::HTTPLogger by Mattt Thompson
- express-antenna-cocoalumberjack by Marius Ursache
- AFNetworking SSL Pinning With Self-Signed Certificates by Eric Allam
- SSL Pinning with AFNetworking 2 by Dody Rachmat Wicaksono