I am able to get location in for ground and back ground but Now I need to get location when user killed app.

There is no official documentation specifying the exact criteria for determining a CLVisit. For example, if a user starts at a target location, will the following method be called? func locationManager(_ manager: CLLocationManager, didVisit visit: CLVisit) This did not work during my testing. It was only successfully triggered when starting from a distant location and arriving at the target point. It would be helpful to know the exact conditions, such as how long a user must stay at a location for it to be considered a visit. Are there any specific thresholds (e.g., minimum duration, distance moved) that determine when this method is triggered?

It seems like find my mac is able to fetch the device location even if the device is in locked state. Why can’t other apps do the same.

We are currently testing the implementation of our Location Push Service Extension (LPSE) in both Ad Hoc and Release environments. We have encountered an issue where LPSE notifications, which were previously working correctly, suddenly fail to be delivered on some devices. After a period of several hours, the notifications resume arriving, but the issue remains intermittent. Notably, during these periods of suspected delivery restriction, regular push notifications (e.g., those using apns-push-type: alert) are delivered and displayed without any problem. [Detailed Situation] Test Environment and Scope We are testing LPSE after obtaining the necessary entitlements, in both Ad Hoc and Release environments. The issue is not observed on all test devices; only certain devices are affected. Observed Behavior Under normal circumstances, LPSE notifications are received and the extension is activated; however, on some devices the notifications suddenly stop arriving. During these periods, even when sending notifications with apns-push-type: location directly via the CloudKit Push Notification Console, no response is observed on the affected devices. The APNs server (api.push.apple.com) always returns a 200 OK response via HTTP/2, and our server-side logs and configurations (DNS resolution performed on every request, using the same JWT token for 59 minutes per session, communication via HTTP/2 with ALPN Protocol: h2) show no issues. Other app functionalities (network communication, UI responsiveness, etc.) work normally. Sending content When sending notifications from our server to APNs (api.push.apple.com), we use the following configuration (over HTTP/2): const payload = { aps: { 'content-available': 1 } }; const headers = { ':method': 'POST', ':path': /3/device/${apnsToken}, 'Authorization': bearer ${jwtToken}, 'apns-topic': 'ot.Here.location-query', 'apns-priority': '10', 'apns-push-type': 'location', 'Content-Type': 'application/json' }; We perform DNS resolution for every request, use the same JWT token for a 59-minute period per session, and communicate via HTTP/2 with ALPN Protocol: h2. Hypothesis on the Cause We suspect that due to an implementation issue, silent push notifications (using content-available: 1) were being sent every few minutes concurrently, which may have triggered an APNs delivery restriction (rate limiting). As a countermeasure, we have completely stopped sending silent pushes and any other background notifications aside from LPSE; however, the issue persists. Additionally, even after resetting affected devices, the delivery problem continues to occur. [Questions for Diagnosis] Given the above situation, is it reasonable to suspect that excessive silent push notifications have triggered an APNs delivery restriction? Does such a silent push restriction affect LPSE notifications (i.e., those sent with apns-push-type: location)? Do APNs delivery restrictions persist even after a device has been reset? Can a high volume of LPSE notifications alone (without silent pushes) also trigger a delivery restriction? → This is our primary concern since it poses a significant implementation challenge. Please let us know if any additional information is required for diagnosis.

Greetings, I recently submitted a request for the Location Push Service Extension Entitlement. Does anybody have insight into how long I would have to wait until Apple responds? Thanks

We’re building a new subway/bus app at the MTA. Our system includes roughly 300 underground stations, around 150 elevated stations (i.e., above street level), and about 5 at-grade stations (i.e., at street level). We serve roughly 5 million riders a day. We’re diving deep into Core Location on iOS and have found that the altitude values returned from two fields we’re testing aren’t accurate enough for our use case: CLLocation.altitude CMAbsoluteAltitudeData.altitude We need to reliably distinguish whether a user is: At street level On an elevated platform (see attached picture) On any platform in an underground station — most have a single platform level, but some, like 59 St (see attached), have multiple platforms at different elevations. These levels typically differ by at least 15 feet, which should in theory be well within the precision range of a properly calibrated barometric pressure sensor. However, the absolute altitude values we’re seeing from these APIs are often inaccurate and inconsistent — not only compared to ground truth, but also across devices. For example, holding two phones side-by-side frequently yields altitude readings that differ by more than 15 feet. That level of variation makes the data unreliable for our needs. Please see the below photos for more context. URLs.md

Dear Apple Developer Support, I am reaching out for guidance on implementing continuous directional and location updates in a watchOS app designed as part of a mapping/navigation solution. Current Scenario: We send continuous location and direction updates from our iOS app to the watchOS companion app. When viewing directions on the Apple Watch, the screen dims after a short period, and the live data stops updating consistently, even though the user is actively looking at the screen. This negatively impacts the usability of real-time navigation on watchOS. Our Objective: Prevent screen dimming (or extend screen-on time) while the user is viewing navigation directions. Ensure reliable, continuous data updates on the watch screen during active navigation sessions. Request: We would appreciate your guidance on: The recommended method to keep the watchOS screen active while displaying real-time navigation data. Proper use of APIs such as WKExtendedRuntimeSession, WorkoutSession, or any other mechanism suitable for this use case. Any best practices or App Store review considerations for apps that require extended screen time and continuous updates. How such use cases were traditionally handled on watchOS and what has or hasn’t worked. We want to ensure we're implementing this in a battery-efficient, user-respectful, and Apple-compliant manner. Thank you for your assistance and guidance.

Waze is not available in the home screen icons for selection in CarPlay. I just reloaded Waze when it disappeared as a selectable icon. How can it be restored?

Hello, Is it possible to retrieve URLs (the URL associated for the specified location) for the Place object when you query the Apple Maps Server APIs? They are available when you make a MKLocalSearch.Request() directly in Swift. We have both iOS and Android apps, and it's not currently possible to get the URLs on Android. Thanks!

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.

Hello everyone, I'm doing some work on validating some data to do with the zpseed functionality around corelocations, i've read up on the speedaccuracy field but the wording doesn't make sense to me. It says if its a positive number it is plus or minus the value in the zspeed column so would this be for example zspeed of 35 mps with an accuracy of 3 mps would it be 32 mps 38 mps or is it a range? so would it be anywhere between 32-38 mps. Or is it just plus or minus the 3mps and if this is the case how would it be worked out if its plus or minus when all the numbers will be a positive numbers as any negative numbers are deemed inaccurate ?

We have an application. We are monitoring the fence event. We are using 'startMonitoringForRegion' API. but we are not getting any fence event. Steps Create a fence using 'startMonitoringForRegion' API BG on APNS trigger. initial fence state 'didDetermineState' not received. From Syslogs we can see OS has detected but event is not given to Application We are compiling code using SDK18.0 Error ** locationd Fence: LAC monitoring is not sufficient for / ocationd Fence: no allowing wifi monitor for, 400.0, fence Feedback Ticket ID: FB17250308 Syslogs Snippet: debug 2025-04-15 12:45:40.890193 -0500 locationd FenceCal: combine non-fine non-large fence, distance, 0.0, / //OS detetected fence state default 2025-04-15 12:45:44.706232 -0500 locationd Fence: fenceUpdate, , bundle, , type, GPS , loc, 33.1171776, -96.6606076, acc, 19, distance, 17, tech, LC...+, trans, 0, state, 0, cont, 1, fence, 33.11728835, -96.66048288, 1011.0, 766431742.6, sCount, 0, 0, trig, 0, 3, sinceLastLoc, 10.0, events, 0x00001810, status, (Inside) => (Inside) , settled state, (Unknown) ==> (Unknown), cantShiftButNeedTo, 0, sinceLastTransition, -1.0, significant, 0, loi, 0, lastProximityStateTimestamp, -1.000000, lastProximityState, 0, lastApproachingState, 0 // debug 2025-04-15 12:45:44.706247 -0500 locationd Fence: LAC monitoring is not sufficient for / // debug 2025-04-15 12:45:44.706263 -0500 locationd Fence: no allowing wifi monitor for, 400.0, fence, Fence, []//, latitude, 33.11728835, longitude, -96.66048288, refFrame, 0, distance, 1011.0, eFistance, 1011.0, lDown, -1.0, time, 766431742.6, ctime, -1.0, flags, EX------, key, -1506186373, throttled, N, polygon, 0, envType, 2, locType, 0

I have a marine navigation app which displays GPS quality information when receiving NMEA message from an external GPS. These include the number of satellites and Horizontal Dilution of Precision (HDOP). As far as I can see, the only additional information available through location services (for devices with built in GPS) is horizontal and vertical accuracy. Am I missing anything? Also does anyone know how horizontal accuracy is derived from HDOP?

Hello, I'm encountering a runtime crash when building my visionOS app with Xcode 16.3 for visionOS 2.5. Our existing AppStore/Testflight app is also instantly crashing on visionOS 2.5 when opened but works fine on e.g visionOS 2.4. The app builds successfully but crashes on launch with this symbol lookup error (slightly adjusted because the forum complained regarding sensitive data): Symbol not found: _$sSo22CLLocationCoordinate2DVSE12CoreLocationMc Referenced from: <XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX> /private/var/containers/Bundle/Application/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/MyApp.app/MyApp.debug.dylib Expected in: <XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX> /usr/lib/swift/libswiftCoreLocation.dylib dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/System/Library/PrivateFrameworks/GPUToolsCapture.framework/GPUToolsCapture:/usr/lib/libViewDebuggerSupport.dylib I've already implemented my own Codable conformance for CLLocationCoordinate2D: extension CLLocationCoordinate2D: Codable { // implementation details... } This worked fine on previous visionOS/Xcode versions. Has anyone encountered this issue or found a solution? System details: macOS version: 15.3.2 Xcode version: 16.3 visionOS target: 2.5 Thank you!

Hello, I'm experiencing an issue with the Apple Maps URL scheme when using raw latitude and longitude coordinates in the daddr parameter. Until recently, using a URL like this worked reliably: https://maps.apple.com/?daddr=37.7749,-122.4194 This would open Apple Maps and show directions from the current location to the specified coordinates. However, on recent iOS versions, this URL no longer behaves as expected.

I am developing an iOS app that uses CLLocationManager to collect location continuously in both foreground and background. But it has the following 4 issues and I don’t understand why: After a while of not using the app, I can not get location updates regularly. Even after that, I go into the app more often or even turn OFF and turn ON the permission again, but the problem still doesn’t improve until I reinstall the app. Previously, I used SilentLog SDK to collect location. Since the cost was quite high, we developed our own SDK that also handles location tracking. After updating the app from the old version using SilentLog SDK to the new version using my own SDK, I can not get location updates regularly. However, when I reinstalled the app, it worked perfectly. It seems that apps downloaded from TestFlight can get location more continuously than apps downloaded from the App Store We sometimes encounter this error in the logs: Error Domain=kCLErrorDomain Code=0 “(null)” I think my app was not terminated in the background because I still collect location but it is not as frequent. I want to know if Apple has any mechanism to prevent such apps from getting location data continuously? I use CLLocationManager with the following configuration: self.locationManager.distanceFilter = 20 self.locationManager.desiredAccuracy = kCLLocationAccuracyBest self.locationManager.allowsBackgroundLocationUpdates = true self.locationManager.showsBackgroundLocationIndicator = false self.locationManager.pausesLocationUpdatesAutomatically = false I also filter the location updates using: guard let location = locations.last else { return } guard location.horizontalAccuracy <= 100 else { return } guard location.speedAccuracy >= 0 else { return } I use a background task to wake up the device every 15 minutes, and I also use silent push notifications in a similar manner. Each time the task is executed, I usually call stopLocation and then startLocation again. This happens quite frequently — will it have any impact or cause any issues?

I am using CLLocationUpdate.liveUpdates() to build a location sharing app. Most of the time it works fine, including in the background, giving acceptably frequent updates. However, soon after the user puts their phone away for the night, the updates stop coming. I've checked all the instance properties (.stationary, .locationUnavailable, etc.) but none of them are ever set to true, even for the last update before updates end. Is there some way to keep the updates coming through the night? I've included some relevant parts of my code here: func startLocationUpdates() { if self.manager.authorizationStatus == .notDetermined { self.manager.requestWhenInUseAuthorization() } Task { do { self.background = CLBackgroundActivitySession() self.session = CLServiceSession(authorization: CLServiceSession.AuthorizationRequirement.always) let updates = CLLocationUpdate.liveUpdates() for try await update in updates { if let loc = update.location { BackgroundServiceKt.onLocationUpdate(arg: loc) } // check all the instance properties } } catch { // error } return } } class AppDelegate: NSObject, UIApplicationDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool { LocationsHandler.shared.startLocationUpdates() return true } }

Summary The onLongPress callback on MapViewcomponent is not working on iOS devices. The callback is properly implemented but never gets triggered on iOS, while it works as expected on Android. Reproducible sample code <MapView onLongPress={(e) => { console.log("onLongPress", e); setAddLocation(e.nativeEvent.coordinate); }} // ... other props Steps to reproduce Just put onLongPress callback on MapView and notice it won't be triggered. Expected result Long press on the map should trigger the onLongPress callback The callback should receive the event object with coordinates Actual result Long press on the map does not trigger the callback on iOS No console logs are shown when long pressing The functionality works as expected on Android React Native Maps Version 1.23.8 What platforms are you seeing the problem on? iOS (Apple Maps) React Native Version 0.79.2 What version of Expo are you using? SDK 53 Device(s) Any iOS Device