A couple of years ago, I bought a nice Danish watch, Skagen 597LSLB. It wasn’t a very expensive watch, but it was a pretty one. At that time, I paid about €120 for it.

Fast forward a couple of years later, some parts of the watch do not seem to be that solid. The leather band started to peel off, like an onion. It’s quite unfortunate that this happened, having in mind that I did not wear this watch every day, since I got it, but only about half of those days. We all know that things are not built as they used to be and that we’re living in a consumerist world, so nothing new so far. One would assume that getting a leather band replaced, shouldn’t be a big deal though. However, it seems that the folks running Skagen could not be bothered to sell any watch accessories anymore. Since they do not offer a replacement on their site, your only option is eBay or a third party company.

A couple of days later, the battery ran out (for the third time since I got the watch). That’s fine, they are not designed to last forever. Let’s check Skagen’s site again, to find out what battery should I buy. Again, I was out of luck, as I could not find that info online.

To save others the trouble of researching this bit, I’ve written this blog post. The Skagen 597LSLB watch model is using a SR616SW/Renata 321/Energizer 321 cell.

Here is a photo of the watch’s internals, in case you’re curious about the built quality.

Which then can be enabled or disabled by by setting the corresponding ddLogLevel:

staticconstintddLogLevel=DDLogFlagDebug|LOG_FLAG_RTS;

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.

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:

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.

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.