Learning iOS Logging

New WWDC talk on Logging in Xcode15

New in Xcode 15 the Console receives the OSLog output. So step away from those old-school print statements. Adopt the logging framework.

Trying to figure out the new Xcode 15 OS Logging feature, you should watch the WWDC talk Debugging with Structured Logging

OS Logging

I've decided to take on the meta-task of converting all my code's print statements into 'os_log' messages. Many times my mentor Lance has tried to get me to quit my old-skool practice of littering my code with print statements. But it's just so much fun to delete all those lines when you've solved a problem!

So I thought now that my problem has grown into an asynchronous DB problem - I might need some heavy artillery to zero in on it and shoot to kill. So my first attempt at reading articles has left me wondering - I'm not getting it... So back to WWDC the Explore Logging in Swift video.

The biggest change for me is that the log messages will not be in the Xcode Debug area window (Cmd-Shift-C). They are stored on device (meaning the iPhone simulator... oh damn - yet another Derived Data folder to clean). And to get to and see the log messages I have to use the Console App. Is this correct?

There are a number of changes in mindset to utilize OS logging.

Messages are displayed in Console App
Logging levels - Debug -> Fault
Categories: (kinda like a hash tag)
Performance (it's fast) - way better than print statements.
Persistance - not all levels are stored forever... not that you need forever.

I'm not after performance...

Ravi notes the framework's performance aspects, which are not that interesting to me. The ease of use - is what should drive me to use logger. This makes me think - how do I switch from PRINT to logger... make print harder to use...

Well, maybe I only need some practice with the 3 easy steps of logging.

There it is - 3 steps to use logger, but only ONE step to use print. So I will have to look at the other end of the process for the countless repeated READING of the messages for saving time. Yeah - that's where the payoff happens.

Logging does an optimized form of String Interpretation if the data type is a primary (Int, Double, etc) type or conforms to CustomStringConvertible. How do I perform that miracle of Swift? He doesn't say - I will have to RTFM.

One great benefit is the automatic redaction of user personal data in logs. That is a great reason to use Logger - think about the amount of personal data that escapes control via log messages... no, STOP and think about this. Apple is putting thought into keeping people's data safe, use Logger!

To override this default behavior the coder must do a bit more work to specify that the data is "public" in the privacy optional parameter.

logger.log("Ordered \(smoothie, privacy: .public)" )

Reading the Logs...

This part seems a lot harder and more work than just looking or searching through an Xcode output window. You have to "collect" logs from the device. I think this is the step I always forget... and why I've not seen my logger output in the Console App. It looks like the trick to smooth integration is the file extension " .logarchive" used as the output parameter ...

log collect --device --start '2022-11-8 8:50' --output fruta.logarchive

Ravi didn't mention that one must be ROOT to use the log collect command. So here's another reason -not- to work for a big corporation that must control every aspect of a crafts-persons environment - SUDO might save you. He also didn't say how to target the device.

These stumbling blocks ... are making print statements shiny!

OK... figured out the missing part of Ravi's talk... the secret is in the Simulator Control unix command:

xcrun simctl list | grep "iPhone 11 (16.1)"

iPhone 11 (16.1) (857AA66C-8CC3-4AF9-8D8B-E9D88B9E32FE) (Booted)

That's the name of my favorite simulator on my Mac. Now do I use Simulator Control to run the log collect? How do I specify the device?

Well... that didn't work! OK, Apple, here is where you can make Xcode better... solve this impediment to using os_log instead of print statements in our source code - and we developers will switch to the easier more secure logger.

Ravi - you skipped over the difficult part...

My logs appear empty...

Skipping to the 6:00 minute mark of the video Ravi goes over the Console App aspect of reading log entries. The log entries are for all kinds of apps running on your device - so one must learn the search and filter features of Console App.

All the reasons why I use print statements in one unix command line.

Console.app

This is not hard... I guess you just need to be told to do it. Let me see if I can remember:

Start up your Xcode and Launch Console.app
In Console - click the Play button to Start streaming
In Console's side bar select the Simulator Device you want to attach
Then as the messages start streamming in... filter with the Search menu bar... like shown below.

Don't: log collect...

If you follow the direction of Ravi in the WWDC20 video he will instruct you to copy and export a log file (log collect...). I don't know why - but that leads me to countless dead-end attempts... Don't do it that way. Console.app will open without the sidebar Devices menu and you will not be able to attach to your Simulator or any Devices.

log collect --device --start '2022-11-8 8:50' --output fruta.logarchive

Maybe there was a long ago time when that was the only way... you-know back in 2020?

Drinking from a Firehose

I had assumed there would be other columns... like the Class name and the Function name... right-click on the titles row and see a list of fields you may add. I assume that the Category field is the choice to narrow the firehose of messages <Pro-Tip>. These are configured in the typical Logger() creation.

OSLog and Unified logging as recommended by Apple - SwiftLee

Page updated

Google Sites

Report abuse