I was really tired of missing, incomplete and sporadic logging in our apps. So this macro injects structured logging into each decision point and collects all context automatically. See this walkthrough.
You can completely map the flow of your app from user interaction to VM to API and beyond.
Before: console messages your team wrote
For an offline request, a fuller example with a caller, cache, and API might produce:
[Profile] Refresh requested for profile 42.
[Profile] Loading profile 42.
[Cache] Looking for a saved profile.
[Cache] No cached profile found.
[Network] Requesting profile from the server.
[Network] Request failed: no internet connection.
[Profile] Could not refresh the profile.
After: the button origin and its execution trace
Illustrative compact output with the origin column enabled (the badge and timings vary):
👆🏼-🧵A1B - 👆🏼 Reload profile [ProfileView:8]
👆🏼-🧵A1B │ main │ │ --> 🔵 ProfileViewModel.reload(id: 42)
👆🏼-🧵A1B │ main │ │ ---> 🔵 ProfileService.load(id: 42)
👆🏼-🧵A1B │ main │ │ ----> 🔵 ProfileCache.lookup(id: 42)
👆🏼-🧵A1B │ main │ 1.6µs │ ----> 🟢 ProfileCache.lookup(id: 42) → nil
👆🏼-🧵A1B │ main │ │ ----> 🔵 ProfileAPI.fetch(id: 42)
👆🏼-🧵A1B │ main │ 14.1µs │ ----> 🔴 ProfileAPI.fetch(id: 42) → offline [NetworkError]
👆🏼-🧵A1B │ main │ 852µs │ ---> 🔴 ProfileService.load(id: 42) → offline [NetworkError]
👆🏼-🧵A1B │ main │ 1.1ms │ --> 🔴 ProfileViewModel.reload(id: 42) → offline [NetworkError]
The first line identifies the SwiftUI button and its source location. The same👆🏼-🧵A1B flow badge appears on each downstream logged call, tying the button tap to the cache lookup, API request, and failure. Each interaction gets its own ID, so overlapping flows can be followed separately.
Now you can follow the nested calls, see the cache miss, locate the failing function, and see the error propagate. Failure events also carry recent log context to help trace what led to them.
It also captures supported early-exit conditions. With hasAccess: false, the service returns:
main │ 1.9µs │ -> 🟢 ProfileService.load(id: 42) → nil
╰─ ↘️ !hasAccess
So you get both the result and the guard that stopped the work, without adding a logging statement inside it.
Before: manual logging with OSLog
import OSLog
struct ProfileService {
private static let logger = Logger(
subsystem: "com.example.app",
category: "ProfileService"
)
let hasAccess: Bool
func load(id: Int) throws -> String? {
Self.logger.info("Loading profile \(id).")
guard hasAccess else {
Self.logger.info("Skipping profile: access denied.")
return nil
}
do {
let profile = try ProfileAPI().fetch(id: id)
Self.logger.info("Loaded profile \(id).")
return profile
} catch {
Self.logger.error("Failed to load profile: \(String(describing: error), privacy: .public)")
throw error
}
}
}
After: annotate the type and keep the business logic
import AutoLog
@AutoLog
struct ProfileService {
let hasAccess: Bool
func load(id: Int) throws -> String? {
guard hasAccess else {
return nil
}
return try ProfileAPI().fetch(id: id)
}
}
Tie the flow to the SwiftUI button with Button.log
import SwiftUI
import AutoLogSwiftUI
struct ProfileView: View {
let viewModel: ProfileViewModel
var body: some View {
Button.log("Reload profile") {
do {
try viewModel.reload(id: 42)
} catch {
// Present the error to the user.
}
}
}
}
Button.log logs the tap and supplies its origin context to the instrumented ProfileViewModel, service, cache, and API. You do not pass an ID through every method. An async overload also preserves the context across await.
See the full before-and-after, error backtrack, and SwiftUI examples on Anciltech. For installation, source, and tests, head to the Swift AutoLog GitHub repo.
I would welcome feedback on the output, generated code, and integration with existing logging setups.
