How can I log each request/response using Alamofire?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Alamofire provides built-in request and response logging through EventMonitor protocol conformance. In Alamofire 5+, you create a class that conforms to EventMonitor, implement the callbacks you care about, and pass it to your Session. For a quick solution, Alamofire 5 includes a built-in ClosureEventMonitor class. For more control, the AlamofireNetworkActivityLogger package or a custom EventMonitor gives you full logging of headers, bodies, status codes, and timing.
Quick Logging with cURLDescription
The simplest approach — print the cURL equivalent of each request:
cURLDescription outputs a copy-pasteable cURL command, useful for reproducing requests outside the app.
Custom EventMonitor (Recommended)
Create a logger that conforms to EventMonitor:
Register it with your session:
Logging Response Bodies
Using ClosureEventMonitor
Alamofire 5 includes ClosureEventMonitor for quick setup without creating a new class:
Conditional Logging (Debug Only)
Logging to OSLog (Unified Logging)
OSLog integrates with Console.app and Instruments for filtering and searching logs on device.
Common Pitfalls
- Logging response bodies in production: Response bodies can contain sensitive data (tokens, personal information) and large payloads. Always wrap verbose logging in
#if DEBUGor use a log level that is disabled in release builds. - Using
printinstead ofos_log/OSLog:printoutputs to stdout which is invisible in production apps. Useos_logor theLoggerAPI for logs that persist on device and are filterable in Console.app. - Blocking the main thread with logging: EventMonitor callbacks run on the
queueyou specify. Use a serial background queue (notDispatchQueue.main) to avoid blocking UI updates while formatting large response bodies. - Forgetting to use the custom Session: Logging only works for requests made through the
Sessionthat has theEventMonitorattached. Requests made through the globalAFsingleton (which is a defaultSession) are not logged unless you replace it. - Logging with Alamofire 4 patterns: Alamofire 4 used
URLProtocolsubclassing orRequestAdapterfor logging. Alamofire 5 replaced these withEventMonitor, which is simpler and officially supported. Old patterns may compile but miss events or cause unexpected behavior.
Summary
- Use
EventMonitorprotocol to create custom request/response loggers in Alamofire 5+ - Register the monitor when creating the
Session:Session(eventMonitors: [logger]) cURLDescriptionprovides a quick copy-pasteable cURL command for any request- Use
#if DEBUGto prevent sensitive data from being logged in release builds - Log to
os_log/Loggerfor production-grade logging that works with Console.app - Truncate large response bodies to avoid memory and performance issues in logging
Related reading
- How can I log SQL statements in Spring Boot?
- How can I log SQL statements in Spring Boot?
- How can I make a timeout for a crushed server
- How can I measure the actual memory usage of an application or process?
- How can I mock requests and the response?
- How can I play sound in Java?
- How can I make a button have a rounded border in Swift?
- How can I make a clickable link in an NSAttributedString?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.