Swift Protocol Magic: Designing a Reusable Location Tracking System for iOS

Swift Protocol Magic II: Designing a Reusable Location Tracking System

Salah Nahed developed a protocol-driven architecture for WinchCore to replace scattered CLLocationManager delegate methods. The system allows any view controller to become location-aware through simple protocol conformance, centralizing authorization and UI logic.

Why This Matters

In typical iOS development, location logic is often duplicated across multiple screens, leading to a scattered mess of delegate methods and inconsistent authorization handling. This design pattern addresses the technical reality of scaling location services by moving from manual boilerplate to a declarative system where the compiler enforces the existence of restriction UI and main-thread safety.

Key Insights

• Abstraction of CLLocationManager into a LocationManager protocol enables the use of mock objects in unit tests, removing dependencies on simulator GPS or Info.plist configurations.
• Protocol extensions provide ‘free’ methods such as startTrackingLocation() and startUpdatingLocation(), allowing UIViewControllers to opt-in to complex behaviors without inheritance.
• The LocationRestrictionConfigurable protocol uses a shouldBlock flag to distinguish between mandatory location features like maps and optional ones like profile suggestions.
• Composed types in Swift (e.g., TrackableLocationViewController & LocationRestrictionConfigurable) allow the compiler to prevent instantiation of managers if the UI contract is incomplete.
• The implementation of @MainActor on the AppLocationManager ensures that all location callbacks trigger UI updates on the main thread, preventing common threading crashes.
• A deliberate one-second delay in startTrackingLocation() prevents jarring UI transitions by allowing the screen’s initial skeleton state to render before permission prompts appear.

Working Examples

The TrackableLocationViewController protocol and its extension provide a standard interface for location-aware view controllers.

public protocol TrackableLocationViewController: UIViewController {
func handleLocationUpdate(lat: Double, lng: Double) async
var locationManager: LocationManager { get }
}

public extension TrackableLocationViewController {
func startTrackingLocation() {
locationManager.startTrackingLocation()
}
}

Usage example of a view controller conforming to the trackable protocol.

class MapViewController: NibViewController, TrackableLocationViewController {
private lazy var appLocationManager: AppLocationManager = {
AppLocationManager(locationManager: CLLocationManager(), viewController: self)
}()
var locationManager: LocationManager { appLocationManager }
func handleLocationUpdate(lat: Double, lng: Double) async {
mapView.setCenter(CLLocationCoordinate2D(latitude: lat, longitude: lng), animated: true)
await fetchNearbyPlaces(lat: lat, lng: lng)
}
override func viewDidLoad() {
super.viewDidLoad()
startTrackingLocation()
}
}

Practical Applications

• System Design: WinchCore uses a shared layer to manage location tracking, ensuring that nested routers handle restriction screens within container views rather than just app-wide modals.
• Pitfall: Implementing location logic without a (0,0) coordinate guard can cause apps to incorrectly render the ‘Null Island’ location in the Atlantic Ocean before the GPS acquires a fix.
• UI Configuration: Developers can override titleText and subtitle properties in the LocationRestrictionConfigurable protocol to provide context-specific instructions for re-enabling location services.
• Pitfall: Hardcoding authorization logic inside a base class limits flexibility and makes it difficult to extract specific location behaviors for different app modules.

References:

• https://dev.to/salahamassi/swift-protocol-magic-ii-designing-a-reusable-location-tracking-system-2heh