Core Location: Your App's Sense of Place

WHY IT EXISTS: Apps often need to provide context based on the user's physical surroundings. Core Location was created to give developers a standardized, privacy-focused, and power-efficient way to access location data from hardware like GPS, Wi-Fi, and cellular radios without managing the complex hardware details themselves.

THE MENTAL MODEL: Think of Core Location as your app's personal navigator. You don't tell it how to find its position; you tell it what kind of position you need (e.g., "roughly where am I?") and how often you need it ("just once" or "continuously"). The framework then handles the hardware, permissions, and power management to deliver that information.

HOW IT WORKS: You create a CLLocationManager object and configure its properties, like desiredAccuracy. You must first request authorization from the user, explaining why you need their location in your app's Info.plist file. Once authorized, you call a method like requestLocation() for a one-time fix or startUpdatingLocation() for continuous updates. The manager then delivers location data to your app's delegate methods, intelligently combining signals from GPS, Wi-Fi, and cell towers to balance accuracy and power.

WHEN TO USE IT: Use Core Location for any feature that depends on the user's physical location. Common patterns include: first, getting a single location to tag a photo or find nearby venues; second, continuous tracking for turn-by-turn navigation or recording a run; third, geofencing, where your app is notified when the user enters or leaves a specific area, like triggering a reminder when they get home.

WHEN NOT TO USE IT: Don't use Core Location without a clear user benefit; users are privacy-conscious and will deny permission. Avoid high-accuracy, continuous updates for background tasks unless absolutely essential. The OS will flag your app for high battery usage, leading users to revoke permission. If you just need to find nearby devices without internet, consider the Multipeer Connectivity framework instead.

ONE CANONICAL EXAMPLE: A weather app needs to show the local forecast. It creates a CLLocationManager, requests "When In Use" authorization, and once granted, calls requestLocation(). It receives a single CLLocation object, extracts the coordinates, and sends them to a weather API. It does not need continuous updates, so this one-time request is far more power-efficient than starting and stopping continuous updates.