According to WWDC sessions, the recommended approach for continuing location collection in the background with liveUpdate is by using CLBackgroundActivitySession. In the app I’m currently developing, I call the invalidate function on the backgroundActivitySession instance when the app enters a terminated state. Then, when the app is resurrected due to startMonitoringSignificantLocationChanges, it reinitializes liveUpdate to resume location collection. When initializing CLBackgroundActivitySession, I also reinitialize the liveUpdates object to ensure the CLLocation.Updates instance is refreshed. However, regardless of the order in which I refresh these two instances, location collection does not resume when the app is revived in the background. Should the originally created CLBackgroundActivitySession instance never be invalidated? Any guidance on whether I am implementing this correctly would be greatly appreciated.

I have a Nissan Rogue 2021 and iPhone 14 Pro Max. Carplay was working fine until I decided to update to the new beta program and now my carplay does not seem to want to operate at all. I do the fixes online suggest in rebooting both systems, forgetting entirely and reconnecting. In the process of doing so, I can get the prompts to start with "Allow while unlocked?" But once selecting that I am unable to actually use the Carplay from the phone. It doesn't even give option to switch to it when I attempt to change audio output.

This is a standalone SwiftUI app w/ watchOS 11. To make things simple, I'm using the new concurrent API, like that: for try await update in CLLocationUpdate.liveUpdates() { … } watchOS is supposed to show the auth dialog, but it doesn't show up, even though update.authorizationRequestInProgress is true. What could be the reason? (Note that I also tried with the procedural old CLLocationManager API, it doesn't work that way as well)

Hello, I’m experiencing an issue with my iOS app that uses CoreBluetooth in combination with beacon monitoring. My app is designed to wake via beacon region monitoring and then start scanning for a specific BLE peripheral (with specific service UUIDs). When the device screen is bright (i.e., the device is unlocked, or locked but the screen is active/bright), everything works perfectly—the connection is established and maintained without any issues in both: foreground and background. However, when the device is left alone for a while and the lock-screen dims (sleeps), the app continues to run in the background and range the beacon (I can confirm this via realtime console logs), but the connection attempt fails. Here’s what I observe: The central manager’s delegate method didConnect is called, indicating that the peripheral was connected. Almost immediately afterward, didDisconnect is triggered with the error message: "The specified device has disconnected from us.". The interesting part is (I repeatedly see this error in the console, because the app repeatedly tries to connect to peripheral until a success), when I touch the lockscreen (not unlock, but just touch, which makes the screen to light up brighter), the connection is being established without any further issues! I have the necessary background modes enabled in the app’s capabilities (e.g., bluetooth-central, location-always-mode, etc..). My expectation was that, thanks to beacon monitoring, the app would be awakened when needed, and scanning/connection would work reliably in the background regardless of whether the device is active or dimmed. My questions are: Why might the connection fail with this error when the device is locked/dimmed? Is this behavior expected due to iOS power management policies even if the app remains active in the background? Is there a way to ensure a reliable connection in such cases? Any insights, workarounds, or suggestions would be greatly appreciated. Thank you in advance!

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 am able to fetch the location in foreground and background. I need just confirmation that can we get location apps killed state. If It's possible then how can I do that.

I really need some help. I have been going back and forth with a customer of mine for weeks. Our app is supposed to track location in the background after a user starts it in the foreground. Every time I test it, it works. I can put the app in the background and walk around for hours. Every time he tests it, it doesn't work. He puts the app into the background and about a minute later, it stops tracking him. Then it starts again when the app comes back to the foreground. We have each tried it on two devices with the same results. I'm willing to post the rest of the details if anyone is interested in helping me, but the last couple of times I got no response, so I'm not going to bother unless I can get some help this time. Thanks.

I have a 2010 F-150 with an Alpine iLX-F509 receiver using CarPlay. Intermittently, and currently, the GPS shows me traveling in the opposite direction that I'm heading which makes the directions completely useless. Happens regardless of wired or wireless connection. Once I unplug from the USB or disconnect from Bluetooth, the map and directions in my iPhone 13 work normally. When plugging back in, even if I've removed the car from CarPlay and reinstall it, the problem comes back. This seems to be a problem with communication between my phone and my truck GPS. Is this a software problem with CarPlay or with the Alpine system? The firmware on the Alpine is current. Could this possibly be a problem with compatibility or my GPS antenna? I do not seem to be having the same issue with my wife's 2020 CR-V. All other features of CarPlay seem to be working fine. It's just the map and the GPS. Doesn't matter which map I use either (Apple, Google).

I'm calling .startUpdatingLocation() from the background to detect user's location but the updates stop shortly after they start. The issue seem to also be discussed here: https://developer.apple.com/forums/thread/726945 I wonder if any solution has been found? This is a critical feature for our app. I have: kCLLocationAccuracyBestForNavigation allowsBackgroundLocationUpdates = true pausesLocationUpdatesAutomatically = false Location Updates in background modes distanceFilter not set or kCLDistanceFilterNone

Hello all, I have a food delivery app that I am beginning to implement CarPlay support in. Route picking, navigation, turn-by-turn guidance features all work perfectly on iPhone, and on CarPlay while the iPhone is unlocked, or locked but screen on. However, when the iPhone is locked and the screen is off, the CarPlay map view stops following the user's location and appears to be frozen. When this happens, the other "map buttons" that are part of the CPMapTemplate continue to accept user input (I can enter and exit the map panning mode for example), the user's location continues to update, and the turn-by-turn guidance continues as normal. It appears to be just the map view (which is drawn on the window and is not part of the CPMapTemplate) that stops updating in this state. I've been through every page of Apple documentation on CarPlay but nothing references or addresses how to keep the CarPlay session active while the iPhone is locked. I'm not sure where else to look for answers and I'm out of theories as to why this might happen. Any guidance around this would be greatly appreciated.

hi, When changing the map to Satellite in Apple Maps and centering it on Ōmuta City, Fukuoka Prefecture, Japan (as shown in the image), the app crashes when swiping to the right. This issue also occurs in MapKit, and I confirmed it happens in Apple Maps as well. It seems that either the satellite map tiles are missing or an error is occurring. Our application is experiencing a crash, and this has become a serious issue. Since September 1, crashes have increased significantly. Initially, we suspected that the issue was due to our application’s implementation, but our investigation revealed that the problem lies with the map tiles being called through MapKit. Could you please investigate this issue and provide a fix?

Hey All, Seem to be in a loop and unable to proceed. New app specific for iOS being built on xCode. Project is configured only to deploy and use iOS, not macOS or anything else. Trying to create a new App iD always see it default to all platforms which means "Background Modes" is not visible or available. Automatic signing etc in xcode can't seem to get around this and just continues to flag I'm missing the entitlement for locations.background. Not sure what I am missing as I cannot manually configure the ID for iOS only and xcode is also generating new ID's with the same platform structure and constraints. Any thoughts or insights here please?

While updating my app for iOS 18 I have run into some major issues with how CLMonitor and visit tracking are handled in the background. I have implemented the new CLServiceSession (i think) correctly. In my @main App struct's init method I call CLServiceSession(authorization: .always) to create a session. This is done in the foreground when the app is launched and also in the background. From what i understand this is the intended way to create a session as when the app is relaunched by the system the existing session is terminated a few moments later. What im seeing in iOS 18 vs iOS 17 is drastically less location updates being delivered to the app. i see around the same significant updates being delivered (around 1 per mile - 5 miles) but the CLMonitor.CircularGeographicConditions are being triggered at about 1 per 1 to 2 minutes regardless of the radius. When a zone is left the condition is removed in the background and a new condition is created at the next place it should be tracking. For visit tracking, it only reports a visit correctly about 10% of the time. my guess is the app is getting suspended and/or terminated and the CLServiceSession isn't correctly being reinitialized (or something completely different, i'm really not sure at this point) I would love some guidance as to the correct way to handle these updates in iOS 18. It is unclear if these are intentional limitations imposed in iOS 18, incorrect implementation on my part, or a bug in the betas. Note: startUpdatingLocation is not appropriate for this app as it is way too power hungry.

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.

I have a sample that stop working on IOS 26, using the latest XCode and IOS sdk, the onTapGesture event is no longer happening. Maybe this is no longer the way to drop pins on the map. Also not working on the iPhone 17 sim or iPhone 16 max pro device upgrading to IOS 26 Thanks, any help Sample: import SwiftUI import MapKit import CoreLocation import Foundation struct Pin: Identifiable { let id = UUID() let coordinate: CLLocationCoordinate2D } struct ContentTestPinDropView: View { @State private var pins: [Pin] = [] var body: some View { MapReader { reader in Map(selection: .constant(nil)) { ForEach(pins) { pin in Marker("Pin", coordinate: pin.coordinate) } } .onTapGesture { screenPoint in if let coordinate = reader.convert(screenPoint, from: .local) { pins.append(Pin(coordinate: coordinate)) } } } } }

I have an error issue that I haven’t been able to solve despite doing extensive research. In fact the similar examples I have found so far have been educational but I have not been able to make work. The example below I am hoping will be easy to fix as it is only producing errors with one line of code… import SwiftUI import CoreLocation var currentLon = Double() var currentLat = Double() extension CLLocation { class func distance(from: CLLocationCoordinate2D, to: CLLocationCoordinate2D) -> CLLocationDistance { let from = CLLocation(latitude: from.latitude, longitude: from.longitude) let to = CLLocation(latitude: to.latitude, longitude: to.longitude) return from.distance(from: to) } func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { currentLon = (locations.last?.coordinate.longitude)! currentLat = (locations.last?.coordinate.latitude)! }/*⚠️ Not sure if this function will work? (Update User Location coordinates on the move?)*/ } struct Positions: Identifiable { let id = UUID() let name: String let latitude: Double let longitude: Double var coordinate: CLLocationCoordinate2D { CLLocationCoordinate2D(latitude: latitude, longitude: longitude) } } struct GameMapView: View { let from = CLLocationCoordinate2D(latitude: currentLon, longitude: currentLat) let to = CLLocationCoordinate2D(latitude: thisCardPositionLongitude, longitude: thisCardPositionLongitude) let distanceFrom = from.distance(from: to) /*⚠️ ERRORS: 1. Cannot use instance member 'from' within property initializer; property initializers run before 'self' is available. 2. Cannot use instance member 'to' within property initializer; property initializers run before 'self' is available. 3. Value of type 'CLLocationCoordinate2D' has no member 'distance'. */ @State private var region = MKCoordinateRegion( center: CLLocationCoordinate2D( latitude: thisCardPositionLatitude, longitude: thisCardPositionLongitude), span: MKCoordinateSpan( latitudeDelta: 0.0001, longitudeDelta: 0.0001) ) var body: some View { Map(coordinateRegion: $region, showsUserLocation: true, annotationItems: locations){ place in MapMarker(coordinate: place.coordinate,tint: Color.accentColor) } .edgesIgnoringSafeArea(.all) VStack { Print("Distance from Location: \(distanceFrom)") font(.largeTitle) padding() }

Loading tile overlays is slow even when the raster data is locally available on the device running iOS 18.2 and built with Xcode 16.2. In this video (https://3dtopo.com/superSlowTileLoading.mov) it takes 38 seconds to load tiles readily available on the device. Then, the whole screen flashes when tiles that are already drawn are redrawn, making for a very poor user experience. 38 seconds to load a dozen or so small images (512x512) stored locally on the device is simply unacceptable. I can't release a product like this that I've spent the last 1.5 years building and many years developing the maps themselves. This severe issue is new since I committed to basing my app on MapKit. Note that this issue does not occur with Apple's base map tiles. I created a Feedback Assitant case, FB16110803, for this issue. For the video, I disabled loading any tiles from the network and disabled loading any other data, such as polylines. Essentially all I am doing is loading the tiles stored on the device and returning them, such as: public func loadTile(at path: MKTileOverlayPath, result: @escaping (Data?, Error?) -> Void) { fetchData(forKey: key, failure: {error in result(nil, error)}, success: {data in result(data, nil)}) } open func fetchData(forKey key: String, failure fail: ((Error?) -> ())? = nil, success succeed: @escaping (Data) -> ()) { let path = self.path(forKey: key) do { let data = try Data( contentsOf: URL(fileURLWithPath: path), options: Data.ReadingOptions()) succeed(data) self.updateDiskAccessDate(atPath: path) } catch { if let block = fail { block(error) } } }

I'm working on an app that uses MapKit and CoreLocation. Is there a way to specify what location is simulated for a Preview, or create a preview that behaves as if the user denied location permissions, so that I can easily test my app's behavior in different scenarios? I know that you can simulate different locations in the Simulator, but haven't been able to get the previews within Xcode to have a location other than the center of Apple Park.

Hi everyone! I’m a new developer diving into my first Apple Watch project, and I’m really excited to get started! This app relies heavily on using the most precise location data possible. Could anyone point me to some official documentation or helpful resources on how to achieve high-accuracy location tracking specifically for watchOS? Any tips or best practices would also be greatly appreciated! Thanks in advance for your help!

Description of the Bug: Core Location intermittently reports inaccurate location updates, albeit with a high accuracy value. This problem occurs almost exclusively while travelling in metros underground affecting the ability to rely on the framework effectively. Steps to Reproduce: The user starts travelling on ground level at point A The user continues travelling and, after some time, is now underground at point B. A stationary beacon scanned at point B confirms this. Core Location is observed to deliver a location update with a high-accuracy value but with the coordinates around point A when the user is actually around point B. Expected Behaviour: Accurate locations should be delivered at all times. In other words, Core Location should not report location updates with high accuracy when its certainty is low.