OSLog

extension OSLog: Logger

OSLogType Log Level Heirarchy:

• Debug - Use this level to capture information that may be useful during development or while troubleshooting a specific problem. Not for Release.
• Info - Use this level to capture information that may be helpful, but isn’t essential, for troubleshooting errors.
• Default - Use this level to capture information about things that might result in a failure. Not for Release.
• Error - Use this log level to capture process-level information to report errors in the process.
• Fault - Use this level to capture system-level or multi-process information to report system errors.

Each level includes the levels below itself, so setting ‘debug’ will include all logs, while ‘default’ would only include itself, error and fault levels

Usage

We suggest you to create a OSLog instance providing subsytem and category, as per apple naming convention.

static let logger = OSLog(subsystem: "com.example.logger", category: "HTTPClient")

It is advised to provide subsystem value in reverse domain format. Easy way would be to get the bundle identifier of the framework or app in use. The category value must be a valid and thoughtful name of the module that is being logged. The logs can be viewed outside Xcode using Console.app and these values are used for filtering logs messages; makes work easier for devloper.

Implementation details

This extension on OSLog provides useful wrapper inline functions for each OSLogLevel levels in two flavours:

1. Log function accepting StaticString and Variadic CVarArg.
2. Log function accepting Any typed value.

logger.logDebug(...)
logger.logInfo(...)
logger.log(...)
logger.logError(...)
logger.logFault(...)

It is advised to make your custom complex types conform to CustomDebugStringConvertible and CustomStringConvertible and make use of the wrapper functions passing your complex type.

Privacy

The unified logging system considers dynamic strings and complex dynamic objects to be private, and does not collect them automatically. Considering this, the messages needs to be marked with access modifiers. The wrapper functions accepting Any type value as input with this extension marks log message arguments as public with DEBUG and private with RELEASE configurations. It is up to the developer to mark arguments as public/private when using the other log function. Please beware of what you log, you don’t wanna accidently expose confidential data i.e., secret key or anything of that sort.

Customize Log Output

If you wanna provide your own custom formatting while logging your custom type, extend it to conform to CustomOSLogMessageConvertible.