## **Built-in** logging

The Bitmovin Player for iOS/tvOS comes with built-in logging support to aid such use cases.

## **Enabling or Disabling** logging

Logging is enabled by default with level `.warning`, printing entries to the console.

Logging can be disabled by setting the logger to `nil`:

Default logger can be restored by:

## **Configuration**

### Log levels

Our SDK supports [multiple log levels](🔗) to allow gathering insights with fine-grained control:

`.info`Indicates something has happened and is purely informative.
`.warning`Indicates something unexpected happened, however the player can continue to function.
`.error`Indicates an issue that disrupts proper functioning of the player.

Log levels are hierarchical

This means that selecting a certain level also includes logs with higher levels.

For example, choosing the `.info` level will include logs with levels `.info`, `.warning`, and `.error`.

On the other hand, selecting the`.warning` level will only include logs with levels `.warning` and `.error`.

The current logger's log level can be changed by simply assigning a new level:

## **Advanced** logger support

We support custom logger implementations via the [`Logger`](🔗) protocol.

`Logger` instances get [`LogEntry`](🔗) objects delivered by the Bitmovin Player.

Log level support within custom `Logger` implementations

Custom loggers need to respect the set log level themselves.

All produced `LogEntry` objects will be delivered to `Logger` implementations and it is the task of the custom logger itself to filter undesired entries.

### Custom logger example

The below example of a custom logger implementation uses the [Logger](🔗) from Apple's [Logging](🔗) framework:

This logger would produce log messages such as: