In my app, I want to launch Apple Maps and start turn-by-turn navigation when the user taps a button. I referred to Apple’s documentation and sample projects and implemented the following code: if let url = URL(string: "maps://?t=m&daddr=(addr)") { self.carplayScene?.open(url, options: nil, completionHandler: nil) } This works only if Apple Maps has been launched at least once on the iPhone or in the CarPlay environment. If Apple Maps has never been opened before, it launches the app but does not automatically start navigation. However, once the user has opened Apple Maps at least once — either on the phone or through CarPlay — then navigation starts as expected from that point on. Is this behavior expected? Or is it a bug?

Hi all — I wanted to share an idea I recently submitted through Feedback Assistant that I think could improve safety and usability for drivers using CarPlay: Add an option to overlay live weather radar (rain, snow, storms, etc.) directly onto CarPlay Maps while navigating. Similar to how traffic conditions are shown now, this would allow drivers to visually track incoming weather in real time without switching apps or relying on separate devices. Why this matters: • Enhances driver safety by increasing situational awareness • Helps with trip planning and route adjustments around severe weather • Reduces distractions by integrating everything into one screen • Useful for everyday drivers, long-haul travelers, and first responders I submitted this via Feedback Assistant, but I’d love to know what others think. If you also see value in this feature, consider submitting your own version via Feedback Assistant so Apple sees there’s interest. Let’s push for smarter, safer navigation — thanks for reading!

Their support email is broken and our IMDF is stuck at "Occupants Data in Review" step. Thank you

Summary While parallel testing Core Location on the new iOS 26.1 beta (23B5044i), I observed what I believe to be a regression of the issue described here: https://developer.apple.com/forums/thread/779192 Specifically, user positioning underground subway stations is noticeably inaccurate on the beta, whereas the same scenarios remain accurate on the unupgraded device below. I work with the MTA (New York City) and work with the OP of that thread. Happy to provide additional testing or details if helpful. Please let me know what else you need. Test Info Riding NYCT from Wall St to 34th St Penn Station on the 2 train carrying two iphones Recording: https://limewire.com/d/dpTWi#pDC3GRYIdE Expected: Consistent underground positioning comparable to prior releases. Actual: Degraded/inaccurate underground positioning on iOS 26.1 beta. Test Devices Left Screen: iPhone 15 Pro Max - iOS 26.1 beta (23B5044i) Right Screen: iPhone 11 - iOS 18.6.2 (22G100) Blue dots show location set by CoreLocation. Red dot on iphone 11 shows the actual location of both devices as I was able to manually place while travelling through a station. Placement through tunnels is not easy to verify and not usually indicated. Timestamps Comparison of when train was actually observed in a station vs when 26.1 and 18.6.2 CoreLocation updated to the station Fulton St 1:48 iOS 26.1 correctly updates (correctly) 2:16 iOS 18.6.2 updates (28sec late) Park Place 4:12 train arrives 4:15 iOS 18.6.2 updates to ~near Park Place 5:04 iOS 18.6.2 updates to Park Place (correctly) 6:07 iOS 26.1 update to ~near Park Place (over 2 mins late) Chambers St 6:02 train arrives / iOS 18.6.2 updates (correctly) 6:14 iOS 26.1 updates to ~near Chambers 6:18 iOS 26.1 update to Chambers (correctly) Franklin St 6:52 train arrives 6:55 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Canal St: 7:16 train arrives 7:18 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Houston St 7:54 train arrives 8:00 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Christopher St 8:37 iOS 26.1 presumably between Houston St and Christopher St 8:40 train arrives / iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update 14 St 9:22 train arrives 9:28 iOS 18.6.2 updates (correctly) 11:01 as train departs station iOS 26.1 updates (1.5 mins late)

We are currently experiencing a very interesting issue when accessing the location in the background with CLLocationManager. The user has given our app the "whenInUse" permission for locations and in most cases the app provides location updates even when it's in the background. However, when we started to use other navigation apps in the foreground we saw that the func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) method was called with (kCLErrorDomain error 1.). The user hasn't changed the location permission and we saw that locations were delivered once the user opened the app again. I don't see anything in the documentation explaining this issue, but I chatted with other developers that confirm that specific behavior. Am I missing something here?

Question: Does anyone have experience or documentation on how to get an App Clip to show on Apple Maps for a location? What I've tried: I have tried to associate my App Clip with an Apple Maps location. We are working with a physical restaurant that has an Apple Maps location, our full app is listed there but not the App Clip. I've gone through the steps of setting up the Advanced App Clip Experience and giving it the location we want it associated with, and have gone through Apple Business Connect and done all the setup there to get the full app to show with the location, but the app clip still does not show. I've contacted Apple Support and they gave me the criteria of "The App Clip is hosted within the app" and "The app is associated to the same physical location". When asking for clarification with the first criteria they said they could help and closed the chat.

Trying to use new Swift @Observable to monitor GPS position within SwiftUI content view. But how do I tie the latest locations to the SwiftUI Map's mapCameraPosition? Well ideally the answer could cover: How to fix this error - So get map tracking along with the User Position, but also How to include facility to turn on/off the map moving to track the user position (which I'll need to do next). So could be tracking, then disable, move map around and have a look at things, then click button to start syncing the mapcameraposition to the GPS location again Refer to error I'm embedded in the code below. import SwiftUI import MapKit @Observable final class NewLocationManager : NSObject, CLLocationManagerDelegate { var location: CLLocation? = nil private let locationManager = CLLocationManager() func startCurrentLocationUpdates() async throws { if locationManager.authorizationStatus == .notDetermined { locationManager.requestWhenInUseAuthorization() } for try await locationUpdate in CLLocationUpdate.liveUpdates() { guard let location = locationUpdate.location else { return } self.location = location } } } struct ContentView: View { var newlocationManager = NewLocationManager() @State private var cameraPosition: MapCameraPosition = .region(MKCoordinateRegion( center: newlocationManager.location?.coordinate ?? <#default value#>, span: MKCoordinateSpan(latitudeDelta: 0.25, longitudeDelta: 0.25) )) // GET ERROR: Cannot use instance member 'newlocationManager' within property initializer; property initializers run before 'self' is available var body: some View { ZStack { Map(position: $cameraPosition) Text("New location manager: \(newlocationManager.location?.description ?? "NIL" )") // works } .task { try? await newlocationManager.startCurrentLocationUpdates() } } } #Preview { ContentView() }

Hello everyone, I'm working on a SwiftUI app that requires location services, and I've implemented a LocationManager class to handle location updates and permissions. However, I'm facing an issue where the location permission popup does not appear when the app is launched. Here is my current implementation: LocationManager.swift: import CoreLocation import SwiftUI class LocationManager: NSObject, ObservableObject, CLLocationManagerDelegate { private let locationManager = CLLocationManager() @Published var userLocation: CLLocation? @Published var isAuthorized = false @Published var authorizationStatus: CLAuthorizationStatus = .notDetermined override init() { super.init() locationManager.delegate = self checkAuthorizationStatus() } func startLocationUpdates() { locationManager.startUpdatingLocation() } func stopLocationUpdates() { locationManager.stopUpdatingLocation() } func requestLocationAuthorization() { print("Requesting location authorization") DispatchQueue.main.async { self.locationManager.requestWhenInUseAuthorization() } } private func checkAuthorizationStatus() { print("Checking authorization status") authorizationStatus = locationManager.authorizationStatus print("Initial authorization status: \(authorizationStatus.rawValue)") handleAuthorizationStatus(authorizationStatus) } func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) { print("Authorization status changed") authorizationStatus = manager.authorizationStatus print("New authorization status: \(authorizationStatus.rawValue)") handleAuthorizationStatus(authorizationStatus) } private func handleAuthorizationStatus(_ status: CLAuthorizationStatus) { switch status { case .authorizedAlways, .authorizedWhenInUse: DispatchQueue.main.async { self.isAuthorized = true self.startLocationUpdates() } case .notDetermined: requestLocationAuthorization() case .denied, .restricted: DispatchQueue.main.async { self.isAuthorized = false self.stopLocationUpdates() print("Location access denied or restricted") } @unknown default: DispatchQueue.main.async { self.isAuthorized = false self.stopLocationUpdates() } } } func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { DispatchQueue.main.async { self.userLocation = locations.last } } func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) { print("Location manager error: \(error.localizedDescription)") } } MapzinApp.swift: @main struct MapzinApp: App { @UIApplicationDelegateAdaptor(AppDelegate.self) var delegate @StateObject private var locationManager = LocationManager() var body: some Scene { WindowGroup { Group { if locationManager.authorizationStatus == .notDetermined { Text("Determining location authorization status...") } else if locationManager.isAuthorized { CoordinatorView() .environmentObject(locationManager) } else { Text("Location access is required to use this app. Please enable it in Settings.") } } } } } Log input: Checking authorization status Initial authorization status: 0 Requesting location authorization Authorization status changed New authorization status: 0 Requesting location authorization Despite calling requestWhenInUseAuthorization() when the authorization status is .notDetermined, the permission popup never appears. Here are the specific steps I have taken: Checked the Info.plist to ensure the necessary keys for location usage are present: NSLocationWhenInUseUsageDescription NSLocationAlwaysUsageDescription NSLocationAlwaysAndWhenInUseUsageDescription Verified that the app's target settings include location services capabilities. Tested on a real device to ensure it's not a simulator issue. I'm not sure what I might be missing. Any advice or suggestions to resolve this issue would be greatly appreciated. Thank 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

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)")

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 trying to derive the Apple Place ID from a CLPlacemark (or via a MKMapItem derived from it) created via either CLGeocoder().reverseGeocodeLocation() or CLGeocoder().geocodeAddressString(). In many cases, the placemark returned from these functions contains detailed information (name, address, coordinates, etc), implying that the Apple Place ID is known, but the identifier is not present. The only way I have found to get a Place ID is via MKLocalSearch. Wondering if I am missing something here.

Hi all, I have a delivery app that requires the user's location on start up. For example to determine the list of services available to the user. So on start up the app asks for location permission. While the app does have a concept of creating addresses, we still require location services so that the user can only select an address close to their current GPS. This is done to prevent fake orders, many apps with similar functionality allow you to pick any location on the map even if you decline location services, which in turn causes a lot of trouble since there are constantly fake orders being created. So to counter that we're asking for the user's location. Now my question is: will apple force me to absolutely never require location access or will explaining to them the problem of fake orders allow me to pass the review? Another feature I have is a driving mode, it's a map for drivers to see routes to a specific order. Obviously I need location services for that to function, or will Apple's review team also cling to that and force me to implement some weird way of letting the user choose their current location? Because there are a lot of trolls that create fake orders, and then have 20 delivery drivers come to a place in a middle of a road. This is a serious issue and will literally kill our business if not countered somehow.

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.

Hi, I have develop the application in the react native. Now this application is related to truck drivers. So we have added load and when they accept the load then we fetch the location to firebase. Now issue is its not working when app close (background) on physical device. We tried on simulator and its working perfectly in the background. But when i make the build and test on physical device its not working for background task.

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.

Hi, I'm building an aftermarket solution to enable Apple Maps to support EV routing for any EV. I am going through the documentation and found some gaps - does anyone know how the following properties work? INGetCarPowerLevelStatusIntentResponse - consumptionFormulaArguments INGetCarPowerLevelStatusIntentResponse - chargingFormulaArguments Is there a working example that anyone has seen? Many thanks

Could anybody give me an example how to set the „NSLocationRequireExplicitServiceSession“ in the info.plist correctly? Thank you

Issue Summary After calling startRangingBeacons, the didRangeBeacons delegate method does not receive iBeacon scan data when the device display is turned off in the background. Expected Behavior On iOS 17.2.1 (iPhone 14), beacon ranging continues in the background even when the display is turned off. The same behavior is expected on iOS 18, but it is not working as intended. Observed Behavior On iOS 18, once the display turns off, beacon ranging stops, and the didRangeBeacons method is not triggered until the display is turned back on. • Location permission is set to “Always Allow.” • Background Modes are correctly configured (Location Updates enabled). Steps to Reproduce Ensure location permission is set to Always Allow. Enable Background Modes → Location Updates in Xcode settings. Call startRangingBeacons(in:) in the app. Put the app in the background and turn off the display. Observe that didRangeBeacons is not triggered while the display is off. Additional Notes • The issue does not occur on iOS 17.2.1 (iPhone 14), where beacon ranging continues even with the display off. • This behavior change is observed on iOS 18 across multiple devices. Could you confirm if this is an intended change in behavior or a bug? If this is expected behavior, what alternative approach is recommended to maintain continuous beacon ranging when the display is off in the background?

Hello forum, I want to keep my app running in the background after user swaps up, for the purpose of workout tracking. start up the task and continuously receipt GPS updates process the location data show the data on a live activity Two examples Strava paddlelogger Question: Does this mean, these two apps would just pause when the .backgroundTimeRemaining becomes 0? How does a workout app "work" in background mode, do I need to handle budget running out?