How does the unified logging system work: Logger, levels, subsystems and categories, privacy, and how do you read logs back?

print writes to standard output, which exists only under Xcode and is lost on a user’s device. Unified logging (os.Logger, import OSLog) writes structured entries to a system-wide log that is fast (strings are formatted lazily, only if someone reads the entry, and stored compactly) and can be collected from devices. Create a Logger(subsystem:category:), with the subsystem usually your bundle identifier and the category a feature (“network”, “sync”), then call debug, info, notice, error or fault. Levels control retention: debug entries are not kept unless debug logging is enabled, info is kept only briefly in memory unless the system is told to keep it, and notice (the default), error and fault are persisted to disk, with fault meaning a bug or broken assumption. In the check below the debug line never reaches the store, while info, notice and error do.

Privacy is built in. Interpolated values are redacted in logs collected without a debugger unless you mark them: \(name, privacy: .public) to show it, .private to hide it (the check shows <private>), or .sensitive; numbers and constant strings are public by default, while dynamic strings are private (Q347). Use categories and subsystems so you can filter: Xcode’s console and Console.app filter by them; the log show and log stream commands accept predicates such as --predicate 'subsystem == "com.example.app"'; and the app can read its own entries with OSLogStore(scope: .currentProcessIdentifier), which is how an in-app “send diagnostics” feature gathers recent logs. Log what you will need at 3 a.m.: state transitions, decisions, identifiers and error details, not every loop iteration; avoid logging secrets and personal data, and remember logs flow to sysdiagnoses and crash reports.