Support for logical call-site with OSLog-backed handlers

[lyzkov]

Summary

swift-log allows callers to pass explicit file, function, and line into Logger APIs, but OSLog / unified logging ignores these as call-site metadata when used via an OSLog-backed LogHandler. This creates a mismatch between swift-log's abstraction (which can carry a “logical call site”) and what unified logging actually exposes in tools like Xcode and Console.

I’d like to request that this gap be addressed, either by:

• defining a way for an OSLog-backed handler to use the logical call site as true call-site metadata, or
• coordinating with the unified logging team to introduce the necessary OS feature/API,
• and then surfacing that capability in swift-log as appropriate.

Current behavior

• Logger.log and the convenience methods accept file, function, and line parameters (defaulting to #fileID, #function, #line) and pass them through to the configured LogHandler. This makes it possible for many backends (stdout, custom sinks, etc.) to treat those as the “logical call site.” [web:6][web:23]

• For a backend that uses OSLog/unified logging, the OS determines the call site from the actual frame where os_log / OSLog.Logger is invoked. There is no public API to override that with the file/line values provided to swift-log; those values can only be encoded as payload/metadata. [web:34][web:36]

• As a result, in Xcode / Console:

  • Logs are attributed to the internal logging frame (often inside a library or backend), not to the original caller that invoked Logger.
  • “Jump to source” and other tooling cannot point to the logical origin that swift-log already knows about.

Use case

A typical flow:

1. User code emits a domain event and logs it via Logger, optionally passing custom file/function/line to describe the logical origin.
2. The event/log travels through multiple layers and third-party libraries that I do not control.
3. A logging/analytics layer at the bottom uses an OSLog-based LogHandler to write into unified logging.
4. In Xcode/Console, I would like to see the event attributed to the logical call site in my module, not to the internal logging code in a dependency.

swift-log already gives me a way to represent that logical call site (the parameters), but unified logging currently does not let an OSLog backend treat those as the real call-site metadata.

Why this seems like a mismatch

• From a swift-log perspective, the API clearly models call-site information as data that can be passed around and potentially used by backends.
• From a unified logging perspective, the call site is effectively fixed to the physical os_log / OSLog.Logger call frame, and cannot be influenced by higher-level abstractions such as swift-log.
• This means that the most capable and recommended logging backend on Apple platforms (unified logging) cannot fully leverage the call-site information that swift-log is already designed to carry.

Requested feature / questions

I understand that swift-log itself cannot modify unified logging behavior, but given that this is an Apple-owned package that is meant to integrate well with Apple platforms, I’d like to ask:

1. Would you consider it in scope for swift-log to support an OSLog-based backend that can preserve or set the logical call site, provided unified logging exposes an appropriate API?

2. If this requires new OS / compiler support (e.g. a way for OSLog to accept an explicit logical call site separate from the physical frame), is this something the swift-log maintainers could raise or coordinate with the relevant Apple internal teams?

Motivation

• Align the capabilities of swift-log (carrying call-site info as data) with the capabilities of the primary Apple logging backend (OSLog).
• Make it possible for developers to build layered architectures (events flowing through multiple modules/libraries) while still having unified logging tooling point back to the logical origin in their own code.
• Provide a clearer and more powerful story for using swift-log as the abstraction layer on top of unified logging on Apple platforms.

I realize that fulfilling this request likely requires work outside this repository, but having this mismatch documented and tracked here would help clarify expectations and potentially guide future integration between swift-log and unified logging.

[czechboy0]

@lyzkov This is a good idea, but it's not really something that the Swift Log maintainers can fix unilaterally.

Could you file a Feedback on OSLog through Feedback Assistant and post the FB number here please? That'll be a good start to getting this addressed.

[lyzkov]

Are you not associated anyhow with Apple Inc.?

Feedback Assistant feels opaque, archaic and extremely unresponsive. I've reported few issues and never got any update. :(

[czechboy0]

As you pointed out, OSLog does not appear to have the necessary API to fulfill your request, and that's not something the Swift Log contributors can change. The way to report feature requests for OSLog is through Feedback Assistant. If you post the FB number here, it'll help.

[lyzkov]

I've sent issue: FB21908565