My app needs to track background location for a period of several hours while the user is using it, and we want to allow the user to switch apps or lock their phone while this is happening. We don't need to track location permanently and because of this, we don't want to request the "Always allow" permission. The app requests "While in use" permission and it has the "Location updates" background mode enabled. The CLLocationManager has 'allowsBackgroundLocationUpdates' set to true, 'pausesLocationUpdatesAutomatically' false, kCLLocationAccuracyBest, kCLDistanceFilterNone, and .fitness for the activity type (we expect the user to be walking). The app also initializes a CLBackgroundActivitySession while it is tracking location and invalidates it when done. When I test this combination on my iPhone, it works fine. I get location tracking in the background for as long as I need it, regardless of what else I do with the phone. However, my customer says it doesn't work for him. He is using a Wifi-only iPad with an external GPS receiver called "BadElf GPS Pro". He says that the external GPS receiver works fine with other apps on his iPad. With my app, he gets background location tracking only for a short time, and then it stops. The app does monitor the "locationManagerDidPauseLocationUpdates" callback and posts a local notification if it gets called, but it doesn't get called. I've also confirmed with him that he is not force-quitting the app and the app is not otherwise being terminated by iOS. Is there something I'm missing?

I'm doing a weather app, users can search locations for getting weather, but the problem is, the results only shows locations in my country, not in global. For example, I'm in China, I can't search New York, it just shows nothing. Here's my code: @Observable class SearchPlaceManager: NSObject { var searchText: String = "" let searchCompleter = MKLocalSearchCompleter() var searchResults: [MKLocalSearchCompletion] = [] override init() { super.init() searchCompleter.resultTypes = .address searchCompleter.delegate = self } @MainActor func seachLocation() { if !searchText.isEmpty { searchCompleter.queryFragment = searchText } } } extension SearchPlaceManager: MKLocalSearchCompleterDelegate { func completerDidUpdateResults(_ completer: MKLocalSearchCompleter) { withAnimation { self.searchResults = completer.results } } } Also, I've tried to set searchCompleter.region = MKCoordinateRegion( center: CLLocationCoordinate2D(latitude: 0, longitude: 0), span: MKCoordinateSpan(latitudeDelta: 180, longitudeDelta: 360) ), but it doesn't work.

Hello, I'm currently migrating my app location service to use the new CLLocationUpdate.Updates. I'm trying to understand what can fail in this AsyncSequence. Based on the previous CLError, I thought authorisation was one of them for example but it turns out that this is handled by the CLLocationUpdate where we can check different properties. So, is there a list of errors available somewhere? Thanks Axel, @alpennec

Hello I started using CLMonitor on my App, and I am noticing the following crash on Xcode Organizer for dozens of my app users: Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000001 Exception Codes: 0x0000000000000001, 0x0000000000000001 VM Region Info: 0x1 is not in any region. Bytes before following region: …………. REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT ………-…….. [ 176K] r-x/r-x SM=COW /var/containers/Bundle/Application/.........../MyApp Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler […..] Thread 4 name: Thread 4 Crashed: 0 libswiftCoreLocation.dylib 0x000000021680b4c8 @objc completion handler block implementation for @escaping @callee_unowned @convention(block) (@unowned CLMonitor) -> () with result type CLMonitor + 44 (<compiler-generated>:0) 1 CoreLocation 0x0000000196cdddd4 __76-[CLMonitorConfiguration vendMonitorWithIdentityAndAuthorizationAttributes:]_block_invoke + 216 (CLMonitorConfiguration.m:195) 2 libdispatch.dylib 0x0000000191138370 _dispatch_call_block_and_release + 32 (init.c:1549) 3 libdispatch.dylib 0x000000019113a0d0 _dispatch_client_callout + 20 (object.m:576) 4 libdispatch.dylib 0x00000001911416d8 _dispatch_lane_serial_drain + 744 (queue.c:3934) 5 libdispatch.dylib 0x00000001911421e0 _dispatch_lane_invoke + 380 (queue.c:4025) 6 libdispatch.dylib 0x000000019114d258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 7 libdispatch.dylib 0x000000019114caa4 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 8 libsystem_pthread.dylib 0x0000000211933c7c _pthread_wqthread + 288 (pthread.c:2696) 9 libsystem_pthread.dylib 0x0000000211930488 start_wqthread + 8 Does anyone have similar issue when using CLMonitor? How can I debug / fix this issue? Is it an CLMonitor API bug? Should I file a bug report?

When I set the values of notifyOnExit and notifyOnEnter to true when registering CLCircularRegion, I checked that the didExitRegion and didEnterRegion functions are called well. However, there is a problem that they are called twice in a row every time they are called. I was wondering if this is an internal bug in the API. There is also a stackoverflow report related to the above issue. I would appreciate your confirmation. stackoverflow - why the didEnterRegion called twice? Thank you.

On IOS 18, starting October this year, the location is not syncing in real time.You might drive for several kilometers and the location displayed on Waze will remain on the same position.This might put in position to miss the exit on the highway and have to drive another 40/50 km, lose time and energy, to get back in the original track. Reinstall the application twice is not correcting the behavior, as well as changing the device, the same issue is present on iPhone 16. Waze support team shared the following: ”Hey there! We'd like to apologize for any hassle that this has caused you. This article: https://tinyurl.com/3fu88jwj might help solve your issue. If you still need help, please open a support ticket by copying and pasting this link: https://tinyurl.com/mrx77ukz in a web browser, and someone from the team will get back to you soon." Based on the above facts, this is clearly an IOS 18 issue, that needs to be prioritized.

I am using CLServiceSession(authorization: .always) to start a service session for tracking Zone entry and exit in the background in my app. It has been working fine on iOS 18 until recently when we added some BGProcessingTasks. The task runs when the user is not moving and the device is on charge, this task runs fro a bit in the background, however we are seeing that even though we are reinitializing then session upon app launch. We have even tried to just explicitly reinitialize a session within the background task callback, but the zone tracking still continues to fail. Significant location changes are unaffected. Timeline of events: User Opens App, CLServiceSession(authorization: .always) is called (assume permissions have already been granted.) App is backgrounded User moves outside zone and app captures the data correctly (this can happen any amount of times) User plugs in Phone BGProcessingTask callback is run, it may or may not be terminated early. The service session is recreated as the first action in the callback. (we have also tried putting it in the main init() function for the app, same outcome) User moves outside zone later and app does NOT capture the data. User is sad :( The session seems to be reinitialized correctly when the app is launched due to CoreLocation updates. Is this expected behaviour or a bug? Is there a good way to debug what is happening with the sessions? Unfortunately, the WWDC sessions on this have not enlightened us about the cause of this behaviour.

I have the following code in my ObservableObject class and recently XCode started giving purple coloured runtime issues with it (probably in iOS 18): Issue 1: Performing I/O on the main thread can cause slow launches. Issue 2: Interprocess communication on the main thread can cause non-deterministic delays. Issue 3: Interprocess communication on the main thread can cause non-deterministic delays. Here is the code: @Published var cameraAuthorization:AVAuthorizationStatus @Published var micAuthorization:AVAuthorizationStatus @Published var photoLibAuthorization:PHAuthorizationStatus @Published var locationAuthorization:CLAuthorizationStatus var locationManager:CLLocationManager override init() { // Issue 1 (Performing I/O on the main thread can cause slow launches.) cameraAuthorization = AVCaptureDevice.authorizationStatus(for: AVMediaType.video) micAuthorization = AVCaptureDevice.authorizationStatus(for: AVMediaType.audio) photoLibAuthorization = PHPhotoLibrary.authorizationStatus(for: .addOnly) //Issue 1: Performing I/O on the main thread can cause slow launches. locationManager = CLLocationManager() locationAuthorization = locationManager.authorizationStatus super.init() //Issue 2: Interprocess communication on the main thread can cause non-deterministic delays. locationManager.delegate = self } And also in route Change notification handler of AVAudioSession.routeChangeNotification, //Issue 3: Hangs - Interprocess communication on the main thread can cause non-deterministic delays. let categoryPlayback = (AVAudioSession.sharedInstance().category == .playback) I wonder how checking authorisation status can give these issues? What is the fix here?

I have implemented geofencing using CLMonitor. The implementation follows this general structure: private var monitorTask: Task<Void, Never>? private var backgroundSession: CLBackgroundActivitySession? func start() async { backgroundSession = CLBackgroundActivitySession() monitorTask = Task { do { let monitor = await CLMonitor("monitor") for try await event in await monitor.events { handleEvent(event: event) } } catch {} } } func addSpot() async { let monitor = await CLMonitor("monitor") let center = CLLocationCoordinate2D(latitude: 0, longitude: 0) let condition = CLMonitor.CircularGeographicCondition(center: center, radius: 100) await monitor.add(condition, identifier: "sample-1") } When the app is not task-killed, the code inside handleEvent executes as expected. However, after a user-initiated task kill, the functionality does not work properly.

Hi everyone, I've implemented geofencing in my app, and it works well when the device is connected to the internet. The app successfully triggers region entry and exit events, even when it's in a terminated state, and sends the details to the server. However, I'm facing an issue with offline functionality. I attempted to cache geofence events (region entry/exit) when the device is offline and send them to the server once the device comes back online. I’ve tried using both UserDefaults and Core Data for caching these events, but the offline events are not being stored or processed correctly. Here’s the code that triggers the region events: func locationManager(_ manager: CLLocationManager, didEnterRegion region: CLRegion) { if let region = region as? CLCircularRegion { handleRegionEvent(region: region, eventType: "enter") } } func locationManager(_ manager: CLLocationManager, didExitRegion region: CLRegion) { if let region = region as? CLCircularRegion { handleRegionEvent(region: region, eventType: "exit") } } The region entry/exit triggers correctly, and I even receive notifications. However, nothing is being saved to storage. To cache events, I'm using this method: private func cacheEvent(_ event: GeofenceEvent) { var cachedEvents = getCachedEvents() cachedEvents.append(event) if let encoded = try? JSONEncoder().encode(cachedEvents) { UserDefaults.standard.set(encoded, forKey: cachedEventsKey) } } For UserDefaults, we've added the app group and suite name, but it's still not working as expected. Has anyone encountered similar issues or have any suggestions on how to reliably cache and sync geofence events during offline scenarios? Any help would be greatly appreciated!

According to the following article, the CLCircularGeographicCondition has a limit whereby only 20 conditions can be monitored by any single app. Monitoring the user’s proximity to geographic regions While I understand the rationale behind this limit, 20 conditions seems quite low for some apps. It would be good if an app could request that the user opt-in to allowing more conditions if they understand the impact this might have on the battery etc. I'm migrating an app presently to use CLCircularGeographicCondition instead of the now deprecated CLCircularRegion. It would be good if there were more guidance on how to use the new Core Location API's to monitor how many conditions are in use within an app and how they can be deactivated when no longer required, allowing the app to free up more of the 20 conditions available.

I'm wondering if setting the correct activityType after initializing CLLocationManager will make the location results more accurate. locationManager = CLLocationManager() locationManager.distanceFilter = 20 locationManager.activityType = .fitness

In my app, I am using geofencing to perform an action when the user enter or leaves a specified location. The geofencing (CLMonitor) is active permanently, and should work across multiple app sessions or after the device is restarted. It should also work after the app was minimized or terminated. This worked perfectly with iOS 17 and prior, but with iOS 18, things changed. As soon as iOS 18 dropped, users were informing me that the app does no longer perform the entry/exit action reliably (without me making any changes to the app). Most of the times, events are missed entirely. Sometimes, after the user opens or resumes the app, duplicate events are delivered and/or events with the current time instead of the correct time of entry/exit. I am making sure that the app has the "Always" location permission before geofencing is enabled The gefocence radius is between 20 and 500m, but even with the max. radius specified, the geofencing is unreliable For the same user and geofence, the entry/exit event is delivered occasionally, but not always I am currently not using CLLocationManager.allowsBackgroundLocationUpdates (even though it's documented as "Apps that receive location updates when running in the background must include the UIBackgroundModes key (with the location value) in their app’s Info.plist file") because it wasn't necessary on iOS 17 and in my tests, using it didn't yield any improvements In my search for what could have caused this change, I found this WWDC video about location authorization: . It appears that with iOS 18, it is now required to have an active CLServiceSession to ensure that location updates are delivered to my app. Even though the video is long (and I've watched it multiple times), some things are still unclear. For example, the docs state: If your app actively receives and processes location updates and terminates, it should restart those APIs upon launch in order to continue receiving updates. Also, in the video it is stated that: ... So your job, ..., is to make sure that your process launch logic knows what features it has been tasked with pursuing, and re-takes session objects... But on the other hand it's also said that: you can only start holding one (a CLServiceSession) when your app is in the foreground and also ... CLMonitor.events won’t yield results when it is not in use, unless a session which was started in the foreground, .... To summarize my questions, for the geofencing to work as described above: when exactly do I need to create a CLServiceSession if the app is launched into the backgorund? Immediately in the applicationDidFinishLaunching method, even though the app is still in the background (applicationState is background)? Or later on, when the app is opened again by the user, e.g. in applicationDidBecomeActive (and applicationState is active)? do I need to specify the background mode capability as noted in the Handling location updates in the background article? do I need to create a CLBackgroundActivitySession as noted in the Handling location updates in the background article? does it matter, which of the four initializer methods I am using to create the CLServiceSession (with CLServiceSessionAuthorizationRequirementAlways)? does it matter if I specify NSLocationRequireExplicitServiceSession in the Info.plist or not when I already do ensure that the app has the "Always" location permission when the feature is being enabled Does a CLServiceSession last indefinitely and should it only be invalidated once the user disables the feature?

I started getting a location error recently. I've never seen this error before and it began happeing randomly. Here is the breakpoint. (if let locationManager........) var currentLocation: Result<CLLocation, Error> { get { #if DEBUG return .success(CLLocation(latitude: CLLocationDegrees(exactly: 0)!, longitude: CLLocationDegrees(exactly: 0)!)) #else if let locationManager = self.locationManager { return locationManager.currentLocation } return .failure(LocationError.unknown) #endif } } I've tried everything I can think of to fix the issue. It has an issue getting the users location when logging in. I've made no changes to the code and everything has worked for years. The bug reports show nothing. I've tried re-installing Xcode, rebuilding the pods etc. I've tried everything that you would normally do in this situation.

We’re implementing a feature in our app that allows a certified MFi GPS device to act as the default location source for user positioning, replacing the internal GPS when connected. However, we’re noticing a significant discrepancy between the accuracy values reported by iOS and those directly available from the GPS device. Here’s the issue: When the MFi GPS is in use, it transmits standard NMEA messages (GGA, GSA, RMC, etc.) to the iOS device (providing HDOP and VDOP). However, the accuracy reported by iOS for this “location-system” seems to be less precise than what the GPS device itself reports. For example, here are the readings we observe: Location from iOS device (systemLocation): Position: <+41.4, +1.8> +/- 5.00m (speed 0.05 m/s / course 329.40) Timestamp: 6/11/24, 12:01:50 Central European Standard Time Horizontal Accuracy (from systemLocation): 5.0 meters (16 ft) Vertical Accuracy (from systemLocation): 9.5 meters (31 ft) Location from GPS device directly: Horizontal Accuracy: 9.1 ft Vertical Accuracy: 10.3 ft It’s evident that the accuracy values displayed by iOS differ from the values available from the GPS device, especially in terms of horizontal and vertical accuracy. Question: Is there a known reason for this discrepancy in accuracy values? Is there a way to obtain the GPS device’s native accuracy values in iOS, or is iOS applying additional filtering or adjustments that might explain this difference? If additional filtering is applied can be disabled? Any insights would be greatly appreciated, as accurate location reporting is critical for our app’s functionality.

Can I integrate Timer along with liveUpdates(_:) in order to manipulate the frequency. Let say for example I need the user location ever 1 min. Is it possible to do so?

I encountered a crash in iOS 17 related to CLBackgroundActivitySession, which appears to be due to misleading guidance in an Apple’s WWDC video. Crash sample code: https://github.com/steve-ham/AppleLocationCrash Simplified Reproduction Steps: 1. Open the GitHub sample app. 2. Archive and export (Distribute App -> Custom -> (Release Testing, Enterprise, or Debugging) -> Export). 3. Open the app. 4. Tap enableBackgroundLocation -> select Allow While Using App on the system popup. 5. Tap disableBackgroundLocation. 6. Go to the iOS home screen. 7. Wait for 10 seconds. 8. Reopen the app -> crash occurs. The crash happens because setting CLBackgroundActivitySession to nil does not end the session, despite Apple’s guidance suggesting it should. Below is the exact quote from WWDC 2023, which explicitly states that both calling invalidate() or letting the object get destroyed (i.e., setting to nil) would end the session: WWDC 2023 Discover Streamlined Location Updates (https://developer.apple.com/videos/play/wwdc2023/10180/) “Before starting the updates, you should instantiate a CLBackgroundActivitySession object to start a new session. Note, we are assigning the session to self.backgroundActivity, which is a property and not to a local variable. And this is important because if we used a local variable, then when it goes out of scope, the object it holds would be deallocated, invalidating the session and potentially ending your app’s access to location. Then when we want to end our session, we can do that by sending the invalidate message or by letting the object be destroyed.” I’ve submitted this to Apple for resolution but wanted to share this with the community. This misguidance has caused issues in my app’s release. If Apple could reply to confirm or provide clarification, it would be greatly appreciated. P.S. Even a minimal implementation in viewDidLoad triggers the crash: let session = CLBackgroundActivitySession() print("session (session)")

I am working with the CLBackgroundActivitySession and CLServiceSession to figure out why our app is sometimes terminated in the background. I am unable to understand what "insufficientlyInUse" corresponds to, it could be understood as The location data is not being used enough the "While in use" permission is not enough It will be very helpful if the entire enum can be explained, I am attaching the one for CLServiceSession since it is a superset of CLBackgroundActivitySession from CoreLocation extension CLServiceSession { public struct Diagnostic { public var authorizationDenied: Bool { get } public var authorizationDeniedGlobally: Bool { get } public var authorizationRestricted: Bool { get } public var insufficientlyInUse: Bool { get } public var fullAccuracyDenied: Bool { get } public var alwaysAuthorizationDenied: Bool { get } public var serviceSessionRequired: Bool { get } public var authorizationRequestInProgress: Bool { get } } ... } Looking forward to hearing from you

We have to draw polygons inside a MKMapView based on coordinates retrieved from external source. It seems that MapKit does not behave correctly where polygons have single-vertex self-intersection. Here it's a simple point list example (every element is a pair of latitude and longitude values): [(0, 0), (20, 0), (10, 10), (20, 20), (0, 20), (10, 10), (0, 0)] The next image shows the rendering issue. But if the list is slightly changed in this way [(0, 0), (20, 0), (10, 10), (20, 20), (0, 20), (15, 10), (0, 0)] the issue disappears. The next image shows it. So it's not a self-intersection and self-tangency problem, but we think single-vertex self-intersection is a buggy edge case for MapKit. Right now we fixed this problem by finding the duplicated coordinates and applying a small offset (1e-8) to one of them, but it's a temporary solution and adds rendering delay. The problem is not due to iOS versions, since iOS 17 and 18 have the same issue. Also it happens on simulators and real devices. Here is the playground example, based mostly on the "Map Playground" template Xcode offers. If you run it without modifying it, the playground shows the "bugged" polygon. If you use notBugPoints instead of the default bugPoints for the polygon, the playground shows the "not-bugged" polygon. import MapKit import PlaygroundSupport // Create an MKMapViewDelegate to provide a renderer for our overlay class MapViewDelegate: NSObject, MKMapViewDelegate { func mapView(_ mapView: MKMapView, rendererFor overlay: MKOverlay) -> MKOverlayRenderer { if let overlay = overlay as? MKPolygon { let polygonRenderer = MKPolygonRenderer(overlay: overlay) polygonRenderer.fillColor = .red return polygonRenderer } return MKOverlayRenderer(overlay: overlay) } } // Create a strong reference to a delegate let delegate = MapViewDelegate() // Create an MKMapView let mapView = MKMapView(frame: CGRect(x: 0, y: 0, width: 800, height: 800)) mapView.delegate = delegate // Configure The Map elevation and emphasis style let configuration = MKStandardMapConfiguration(elevationStyle: .realistic, emphasisStyle: .default) mapView.preferredConfiguration = configuration // Create an overlay let bugPoints = [ MKMapPoint(CLLocationCoordinate2DMake(0, 0)), MKMapPoint(CLLocationCoordinate2DMake(20, 0)), MKMapPoint(CLLocationCoordinate2DMake(10, 10)), MKMapPoint(CLLocationCoordinate2DMake(20, 20)), MKMapPoint(CLLocationCoordinate2DMake(0, 20)), MKMapPoint(CLLocationCoordinate2DMake(10, 10)), MKMapPoint(CLLocationCoordinate2DMake(0, 0)) ] let notBugPoints = [ MKMapPoint(CLLocationCoordinate2DMake(0, 0)), MKMapPoint(CLLocationCoordinate2DMake(20, 0)), MKMapPoint(CLLocationCoordinate2DMake(10, 10)), MKMapPoint(CLLocationCoordinate2DMake(20, 20)), MKMapPoint(CLLocationCoordinate2DMake(0, 20)), MKMapPoint(CLLocationCoordinate2DMake(15, 10)), MKMapPoint(CLLocationCoordinate2DMake(0, 0)) ] let polygon = MKPolygon(points: bugPoints, count: notBugPoints.count) mapView.addOverlay(polygon) // Frame our annotation and overlay mapView.camera = MKMapCamera(lookingAtCenter: CLLocationCoordinate2DMake(10, 10), fromDistance: 5000000, pitch: 0, heading: 0) // Add the created mapView to our Playground Live View PlaygroundPage.current.liveView = mapView

After upgrading to 15.1, SSIDs can no longer be scanned. In my main application, there is a wifiAccess.app in the LaunchService folder that is killed by embbed. This app is the root process that is placed under launchDaemon and loaded by launchd CLLocationManager *locationManager = [[CLLocationManager alloc] init]; if (@available(macOS 10.15, *)) { [locationManager requestAlwaysAuthorization]; } else { // erlier version do not need localtion permission } NSError *error; NSData *ssidStrData = [ssid dataUsingEncoding:NSUTF8StringEncoding]; CWInterface *interface = [[CWWiFiClient sharedWiFiClient] interface]; NSSet<CWNetwork *> *networks = [interface scanForNetworksWithSSID:ssidStrData error:nil]; However, the obtained networks do not have ssid. {(<CWNetwork: 0x600000368680> [ssid=(null), bssid=(null), security=WPA2 Enterprise, rssi=-49, channel=<CWChannel: 0x600000370bd0> [channelNumber=44(5GHz), channelWidth={20MHz}], ibss=0], <CWNetwork: 0x600000370b30> [ssid=(null), bssid=(null), security=WPA2 Enterprise, rssi=-73, channel=<CWChannel: 0x600000370b00> [channelNumber=6(2GHz), channelWidth={20MHz}], ibss=0], <CWNetwork: 0x600000370be0> [ssid=(null), bssid=(null), security=WPA2 Enterprise, rssi=-44, channel=<CWChannel: 0x600000370c60> [channelNumber=165(5GHz), channelWidth={20MHz}], ibss=0] }, the main program has granted the location permission, but the location authorization has not responded in this wifiaccess process. And (lldb) po [locationManager authorizationStatus] kCLAuthorizationStatusNotDetermined. The output authorization is always unauthorized, but only the authorization option of the main application can be seen in the system Settings location permissions setting, wifiaccess.app is not present on the list