It's mainly a developer utility to check iOS console output within your device, without a computer. However many released apps write debug data into console, so occasional users can use it to check what's going on under the iOS hood - even whether some app really crashed or not (check "ReportCrash").
So why did I write it? Because I needed something like that in a real customer project, but couldn't find. Here's the story, without any names:
I was a subcontractor for a big international company's Finnish department, working remotely some 500 km offsite. We sent an ad hoc demo release to customer's customer, who managed to crash it right away. Works for me, of course, so what could we do? Would have loved to travel to warm and sunny southern Europe to debug on-site, but for some reason it wasn't acceptable.
Next step was suggesting live Skype call, but that wasn't possible either due their busy schedule. So I wrote and sent step-by-step instructions how to install and use iPhone Configuration Utility to email console output to me. Response was that it would take 2 weeks to get company permission to install and use that app... Big companies work in slow and steady ways, no surprises to mess up the business. But our app was still crashing!
Next morning customer couldn't reproduce the crash any more. However during the night I had drafted my own "read console and email relevant parts to me" iPhone application. Even though it wasn't needed any more, the idea got stuck in my head. Real world use case, interesting technical problem, challenge whether it can be done. First version was ready and functional next weekend and now mere 8 months later it's available for everyone!
There are a couple similar apps, so what makes Console On Device different?
As an Xcode developer I'm used to see only my app debug output, so I prefer filtering by app as a default. Other apps mostly display the whole console, just like the Mac OS X built-in Console app does. Not a bad idea, might add later to my app, too.
Another vital feature is getting data out from device, so email was obvious choice. Send all messages, send all available details, make it easy. No time to handle single items one at a time. Remote beta tester might not know what is important, busy developer has no time to explain everything, so I chose to keep things easy: send all, send everything, no options.
Console can have lots of details, too much. I tried to help user by using several levels of visibility:
- First level displays only list of apps with minimal important info, like when was last message recorded and how many there are alltogether
- Second level displays most important data per single console message
- Third level display EVERYTHING. Don't leave anything way, since who am I to decide what is important to a fellow developer