I am encountering a coordinate rendering issue using MKMapView in my iOS app. I have a GPS coordinate in WGS84 format, which corresponds to a location in Hong Kong. When my device is physically located in Hong Kong, MKMapView displays the map with the "Apple Maps" label, and the WGS84 coordinate is rendered at the correct position. However, when the device is in Mainland China, MKMapView switches to display "Amap" (Gaode Maps) branding, and the same WGS84 coordinate is rendered at an incorrect position. I understand that Amap in Mainland China uses the GCJ-02 coordinate system, while Apple Maps typically uses WGS84. This discrepancy suggests a potential coordinate system mismatch, but I cannot definitively confirm which map type (and corresponding coordinate system) MKMapView is actually using in different regions. My key questions are: How can I programmatically or visually confirm the underlying map type (Apple Maps vs. Amap) and its coordinate system within MKMapView? Is there a way to simulate the Apple Maps environment for testing when physically located in Mainland China?

We (at the NYC MTA) are building a new subway/bus app and diving deep into location tracking on iOS. We’re encountering an issue with how Core Location functions in the subway, specifically regarding how long it takes to update a passenger’s location as they travel from station to station. As an example, please see this video: https://drive.google.com/file/d/1yaddkjyPEETvTEmClPAJ2wks8b-_whqB/view?usp=sharing The red dot is set manually (via a tap gesture) and represents the ground truth of where the phone actually is at that moment. The most critical moment to observe is when the train physically arrives at a station (i.e., when I can see the platform outside my window). At this moment, I update the red dot to the center of the station on the map. Similarly, I adjust the red dot when the train departs a station, placing it just outside the station in the direction of travel. The trip shown is from Rector St to 14 St. All times are in EST. I’d like to investigate this issue further since providing a seamless underground location experience is crucial for customers. As a point of comparison, Android phones exhibit near-perfect behavior, proving that this is technically feasible. We want to ensure the iOS experience is just as smooth.

This is my first post here. Please guide me, if I need to provide more information to answer this post. I write a simple application, that monitors GPS position (location). I followed Apple documentation for LiveUpdates: https://developer.apple.com/documentation/corelocation/supporting-live-updates-in-swiftui-and-mac-catalyst-apps My app can monitor location in foreground, background or it can completely stop monitoring location. Background location, if needed, is switched on when application changes scenePhase to .background. But it is in the foreground, that memory leaks occur (according to Instruments/Leaks. Namely Leaks points to the instruction: let updates = CLLocationUpdate.liveUpdates() every time I start location and then stop it, by setting updatesStarted to false. Leaks claims there are 5x leaks there: Malloc 32 Bytes 1 0x6000002c1d00 32 Bytes libswiftDispatch.dylib OS_dispatch_queue.init(label:qos:attributes:autoreleaseFrequency:target:) CLDispatchSilo 1 0x60000269e700 96 Bytes CoreLocation 0x184525c64 Malloc 48 Bytes 1 0x600000c8f2d0 48 Bytes Foundation +[NSString stringWithUTF8String:] NSMutableSet 1 0x6000002c4240 32 Bytes LocationSupport 0x18baa65d4 dispatch_queue_t (serial) 1 0x600002c69c80 128 Bytes libswiftDispatch.dylib OS_dispatch_queue.init(label:qos:attributes:autoreleaseFrequency:target:) I tried [weak self] in Task, but it doesn't solve the leaks problem and causes other issues, so I dropped it. Anyway, Apple doesn't use it either. Just in case this is my function, which has been slightly changed comparing to Apple example, to suit my needs: func startLocationUpdates() { Task() { do { self.updatesStarted = true let updates = CLLocationUpdate.liveUpdates() for try await update in updates { // End location updates by breaking out of the loop. if !self.updatesStarted { self.location = nil self.mapLocation = nil self.track.removeAll() break } if let loc = update.location { let locationCoordinate = loc.coordinate let location2D = CLLocationCoordinate2D(latitude: locationCoordinate.latitude, longitude: locationCoordinate.longitude) self.location = location2D if self.isAnchor { if #available(iOS 18.0, *) { if !update.stationary { self.track.append(location2D) } } else { // Fallback on earlier versions if !update.isStationary { self.track.append(location2D) } } } } } } catch { // } return } } Can anyone help me locating these leaks?

I am using the code provided on the website https://developer.apple.com/maps/sample-code/embedded-map/index.html, replacing it with my own MapKit JS Token. When accessing it using a network in mainland China, a 401 error occurs with the message [Initialization failed because the authorization token is invalid]. However, it works normally when using a network in Japan. Does this service not work in mainland China?

Hi, in MapKit JS the hybrid view appears to have lost the street names overlay in the last few days. Does anyone know if this is an issue/error or a changed feature? Thanks.

Has anyone found a thread-safe pattern that can extract results from completerDidUpdateResults(MKLocalSearchCompleter) in the MKLocalSearchCompleterDelegate ? I've downloaded the code sample from Interacting with nearby points of interest and notice the conformance throws multiple errors in Xcode 16 Beta 5 with Swift 6: extension SearchDataSource: MKLocalSearchCompleterDelegate { nonisolated func completerDidUpdateResults(_ completer: MKLocalSearchCompleter) { Task { let suggestedCompletions = completer.results await resultStreamContinuation?.yield(suggestedCompletions) } } Error: Task-isolated value of type '() async -> ()' passed as a strongly transferred parameter; later accesses could race and Error: Sending 'suggestedCompletions' risks causing data races Is there another technique I can use to share state of suggestedCompletions outside of the delegate in the code sample?

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?

I have a test application I'm working on (so it's a fresh Xcode project under Sonoma - with older map code borrowed from another project). It is a macOS application. And in Obj-C. When the map window is opened the logs contain the following - I've been trying to hunt down and resolve. Thank you in advance for any clues/pointers. Failed to locate resource "default.csv" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite.styl" Failed to locate resource "satellite.styl" Couldn't find satellite.styl in framework, file name satellite.styl Authorization status: Authorized The application does have MapKit.framework included.

Hi everyone, I’m encountering a strange issue with GPS tracking in my app, and I’m hoping for some insights. I’m developing an app that records users' GPS activities (walking, biking, etc.) with app in the foreground and/or background. Most activities are outdoors, sometimes in areas with poor GPS reception, such as mountains. To track user location, we’re using: locationManager = CLLocationManager() locationManager.distanceFilter = 3 locationManager.activityType = .fitness locationManager.pausesLocationUpdatesAutomatically = false locationManager.allowsBackgroundLocationUpdates = true The Issue In certain scenarios, the GPS behaves unexpectedly. For example (see attached image below): A user followed a normal route (brown line), then reached an intersection and turned right (blue arrow). However, the GPS continued straight for about 200 meters (brown line) before correcting itself and resuming accurate tracking. Here’s a snippet of the recorded coordinates during this misbehavior: time,latitude,longitude,elevation,verticalAccuracy,horizontalAccuracy 10:17:17,47.92408,7.10438,950.82375,4.74865,4.80005 10:17:33,47.92410,7.10435,950.14966,4.74865,4.10799 10:17:44,47.92412,7.10431,943.63913,4.74865,4.46287 10:17:53,47.92413,7.10427,939.51380,4.74865,4.60644 10:17:59,47.92415,7.10424,934.82986,4.74865,4.52599 10:18:02,47.92417,7.10420,932.53145,4.74865,4.823035 10:18:05,47.92418,7.10416,927.84917,4.748655,4.59619 10:18:09,47.92420,7.10413,924.89886,4.748655,4.50172 10:18:13,47.92422,7.10409,923.35354,4.74865,4.77356 10:18:18,47.92424,7.104055,920.16327,4.74865,4.78286 10:18:22,47.92426,7.10400,915.23174,4.74865,4.66226 10:18:28,47.92427,7.10397,906.08626,4.74865,4.97331 10:18:31,47.92429,7.10394,903.25157,4.74865,4.81649 10:18:35,47.92431,7.10390,895.27948,4.74865,5.15392 10:18:38,47.92433,7.10386,889.71076,4.74865,5.25283 10:18:42,47.92435,7.10382,881.74041,4.74865,5.49089 10:18:46,47.92437,7.103785,874.34945,4.74865,5.55564 10:18:49,47.92439,7.10374,869.63184,4.74865,5.37537 10:18:53,47.92441,7.10370,861.26690,4.74865,5.39344 10:18:57,47.92443,7.10366,854.67646,4.74865,5.30404 10:19:01,47.92445,7.10362,848.48881,4.74865,5.59742 10:19:06,47.92447,7.10359,836.48915,4.74865,5.65666 10:19:08,47.92449,7.103555,835.72566,4.74865,5.54957 10:19:10,47.92450,7.10352,834.41579,4.74865,5.63540 10:19:13,47.92452,7.10348,830.17080,4.74865,5.65795 10:19:16,47.92454,7.10344,828.17052,4.74865,5.72169 10:19:19,47.92456,7.10340,824.93658,4.74865,5.62606 10:19:24,47.92458,7.10337,818.40503,4.74865,5.23265 10:19:34,47.92460,7.103335,804.42539,4.74865,4.683855 10:19:38,47.92462,7.10329,799.51747,4.74865,4.47590 10:19:48,47.92464,7.10324,784.97044,4.74865,4.59459 10:19:50,47.92466,7.10320,782.04750,4.748655,4.71036 10:19:57,47.92468,7.10317,777.49314,4.74865,4.60504 10:20:05,47.92469,7.10313,771.30168,4.74865,4.35574 10:20:09,47.92472,7.10308,766.64446,4.74865,4.94510 10:20:13,47.92474,7.10304,757.33384,4.74865,5.39175 10:20:15,47.92476,7.10300,753.52157,4.74865,5.442045 10:20:20,47.92477,7.10297,742.66179,4.74865,5.52391 10:20:23,47.92479,7.10293,735.38369,4.74865,5.44657 10:20:25,47.92480,7.10290,732.19367,4.74865,5.519945 10:20:28,47.92482,7.10286,725.15380,4.748655,5.58173 10:20:31,47.92484,7.10282,717.08813,4.74865,5.37805 10:20:34,47.92486,7.102785,710.35208,4.74865,5.27918 10:20:37,47.92488,7.10274,706.16774,4.748655,5.53270 10:20:40,47.92490,7.10270,702.84802,4.74865,5.71088 10:20:41,47.92648,7.10356,940.27115,6.600805,10.78768 10:20:43,47.92651,7.10355,940.24665,6.61807,10.45243 At 10:17:44, the location data was correct. Shortly after, CLLocationManager started returning inaccurate coordinates. Despite the system reporting good horizontal and vertical accuracy, the altitude readings drop progressively from 940m to 702m, even though the user remained at 940m in reality. (We also recorded barometric elevation, which confirms that he stayed around 900m) Then, at 10:20:41, the GPS corrected itself. Questions Is it possible that GPS could "lock onto" the wrong path, generating valid-looking but incorrect coordinates? Can we force CLLocationManager to use GPS exclusively (disabling other sensors like Wi-Fi)? I assumed that setting activityType = .fitness would prioritize outdoor tracking, but I’m still being located indoors. Could adjusting the activityType improve this behavior? Could having multiple CLLocationManager() instances in our app cause issues? (We use one to save the GPS coordinates, but MapBox also creates a CLLocationManager with lower accuracy for its Telemetry framework, for example) Thanks in advance for any help or suggestions!

I’m facing an issue with iOS that I hope someone can help with. I developed an app a few years ago that records GPS tracks. Up until recently, everything worked fine—even when the app was running in the background, the recording continued without problems. However, since releasing an update compiled after the iOS 18 release, users have reported that background tracking no longer works. I’ve reviewed the iOS documentation but haven’t found any relevant changes or solutions. Before the newly compiled release the app was working well on iOS 18 devices as well. Some users have reported that switching to the location permission from "When Using the App" to "Always" solved the issue. This is not the case for all users. Has anyone else encountered this issue? Any recommendations or insights on how to resolve it would be greatly appreciated. Below you can see the code used for the location tracking. Before the issue happened the app was compiled with XCode 15.4. Now I am using XCode 16.2 locationManager.activityType = CLActivityType.fitness locationManager.desiredAccuracy = kCLLocationAccuracyBest locationManager.distanceFilter = 3 locationManager.allowsBackgroundLocationUpdates = true locationManager.pausesLocationUpdatesAutomatically = false if #available(iOS 11.0, *) { locationManager.showsBackgroundLocationIndicator = true } locationManager.startUpdatingLocation() if #available(iOS 17.0, *) { // Create a CLBackgroundActivitySession object backgroundActivitySession = CLBackgroundActivitySession() } Thanks in advance for your help!

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 keep getting severe weather warnings in CA but I’m in NY. I have checked my locations and I have no CA weather requests selected. I clicked on the alert and it said it was from weatherkit. How do I make these CA go away for good? Thanks!

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

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 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.

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.

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.

The https certificate has expired

We developed a app in which the I need the app to update the User's location even in background( even after terminating from the recent UI ), Currently I am receiving the location updates when the user has kept the app in open and if minimised, But I want that it should update the location even when it is removed from recent app (minimised UI)(after terminating the app) Is it possible to do so.???

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)