## **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:
| Level | Description |
`.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` implementationsCustom 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: