Legacy
SwiftNetworkRouting
Library · Networking
Lightweight Swift networking library standardizing endpoints, logging, and error handling.
- Library
- Networking
- Swift
- Alamofire
- CocoaPods

Summary
A small Swift networking layer on top of Alamofire. It standardizes how endpoints are described, how requests are built (JSON + multipart), how responses are logged, and how errors are mapped into consistent messages. Designed to reduce repeated “glue code” across apps while keeping customization points explicit. Key highlights:
- Single EndPoint contract for URL, params, headers, and content type
- Router that supports JSON requests and multipart uploads
- Pluggable logging and error handling without app-level coupling
Quick facts
- Role: Author / iOS Developer
- Timeframe: Internal reusable library (ongoing)
- Platform: iOS (Swift)
- Status: Active (open-source)
- Team: Solo
Problem
- Networking code tends to sprawl: endpoints, headers, encoding, decoding, logging, and errors end up duplicated per feature.
- Multipart uploads are easy to implement inconsistently (file metadata, mixed parameter types, boundary handling).
- Error surfaces are often noisy or vague, making debugging and UX messaging inconsistent.
Solution
I built a lightweight library that enforces an explicit endpoint definition (EndPoint) and a single request executor (Router). The router chooses request behavior based on content type, logs requests/responses via a NetworkLogger, and delegates status-code evaluation to an ErrorHandler. Successful responses decode into a generic Codable model with a standard JSONDecoder, while failure paths return human-readable error messages.
- Includes a multipart builder that supports files, data, URLs, and strings in one place
Architecture
- EndPoint protocol defines baseURL, path, method, headers, params, and content type
- EndPoint extensions build merged headers, full URL with query items, and multipart form-data append logic
- Router<EP> orchestrates requests using Alamofire (AF.request / AF.upload)
- NetworkLogger protocol + DefaultNetworkLogger for cURL-style request logs and response summaries
- ErrorHandler protocol + DefaultErrorHandler to map status codes into consistent results/messages
- Generic response decoding into Codable models with consistent error messages for missing/invalid payloads
Tech stack
- iOS: Swift, Alamofire
- Architecture: Protocol-driven design, Generic Router, Codable decoding
- Backend/Infra: REST/JSON, Multipart form-data uploads
- Tooling: CocoaPods, GitHub
Hard problems solved
- Unified JSON and multipart flows under one API without leaking Alamofire details into feature code
- Built a multipart encoder that accepts mixed payload types (file, data, URL, string) safely and predictably
- Made logging swappable so apps can move from print-based debugging to structured logging later
- Centralized HTTP status handling to prevent “per-call” error mapping drift across the codebase
- Kept the surface area small while still allowing overrides (custom error messages, custom error mapping)
- Identified and isolated a method-mapping edge case (HTTP method mapping bug) to prevent silent request failures
Impact / Results
- Reduced networking boilerplate across projects by standardizing endpoint + router patterns
- Improved debugging speed with consistent request/response logs and stable error messaging
- Made multipart uploads safer to implement and easier to review