Hello, thanks for your effort! I found that when showsUserLocation is set to true (by default), the pulsing blue dot user location annotation is shown, which is cool and beautiful. However, it will automatically and periodically attempt to call the Apple Server API GET https://api.apple-mapkit.com/v1/reverseGeocode within userLocationDidChange() and updateUserLocationAnnotation() to display, I assume, the user's current address when single-tapping on the blue dot. It will significantly use the MapKit service calls quota since the user location is automatically updated. It almost runs out of quota even though the map initialization is plenty enough. Is there any way to disable the bubble behavior but preserve the user location blue dot, which is lovely and better than drawing my own user location dot? It seems I can only turn off all user location features. Many thanks!

Our app supports UIScene. As a result, launchOptions in application(_:didFinishLaunchingWithOptions:) is always nil. However, the documentation mentions that UIApplication.LaunchOptionsKey.location should be present when the app is launched due to a location event. Given that our app is scene-based: How can we reliably determine whether the app was launched due to a location update, geofence, or significant location change? Is there a recommended pattern or API to detect this scenario in a Scene-based app lifecycle? This information is critical for us to correctly initialize location-related logic on launch. Relevant documentation: https://developer.apple.com/documentation/corelocation/cllocationmanager/startmonitoringsignificantlocationchanges()

We are experiencing a failure in CLMonitor event delivery when the application is launched into the background via an APNS (Remote Push Notification). Even when a CLBackgroundActivitySession is instantiated immediately upon background launch, CLCircularGeographicCondition "Enter" events are suppressed. The system fails to deliver these events until the user manually brings the application to the Foreground. This indicates that CLBackgroundActivitySession does not correctly maintain background persistence when the session begins in a background state rather than transitioning from the foreground. Comparison of API Behavior (Background State) Launch via APNS: CLMonitor: Fails to trigger "Enter" events until the app is manually brought to the foreground. Legacy API: Successfully triggers and delivers "Enter" events immediately upon background launch. Exit Event Reliability: CLMonitor: Reliably triggers exit events even in the background. Legacy API: Reliably triggers exit events. Foreground Dependency: CLMonitor: Requires a foreground transition to "flush" or activate the delivery of pending entry events. Legacy API: No foreground transition required; events are delivered directly to the background process. Event Recovery: CLMonitor: Relies on the developer re-instantiating the CLMonitor and awaiting the events stream, which appears to "stall" during warm-starts. Legacy API: Relies on the CLLocationManagerDelegate which remains active as long as the manager instance exists. Steps to Reproduce Preconditions: Location Permissions: Set to "Always Allow". Background Modes: "Location updates" and "Remote notifications" enabled. App State: Terminated or Killed (by the user or the OS). Reproduction Path: Trigger Background Launch: Send a silent push notification (APNS) to wake the app in the background. Initialize Session: Within the background launch sequence (e.g., didFinishLaunchingWithOptions), immediately create and hold a strong reference to a CLBackgroundActivitySession. Register Monitor: * Initialize CLMonitor using requestMonitorWithConfiguration. Add a geofence using addConditionForMonitoring with a CLCircularGeographicCondition. Simulate Entry: Move the physical device (or simulate location) into the geofence boundary while the app remains in the background state. Observe: No "Enter" event is received in the CLMonitor event stream. Foreground Transition: Bring the app to the foreground. Actual Result: The "Enter" event is only delivered the moment the app enters the Foreground. Expected Result: The CLBackgroundActivitySession should enable CLMonitor to deliver "Enter" events immediately in the background, parity with the deprecated startMonitoringForRegion API.

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

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 have tried to make colored annotations in mapView (shown in the commented sections) but they always appear in black. Any help would be appreciated. func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> MKAnnotationView? { let annotationView = MKAnnotationView(annotation: annotation, reuseIdentifier: "TempAnnotationView") annotationView.canShowCallout = true annotationView.rightCalloutAccessoryView = UIButton(type: .detailDisclosure) let configuration = UIImage.SymbolConfiguration(pointSize: 10, weight: .thin, scale: .default) if annotation.title == "Start" { // let config = UIImage.SymbolConfiguration.preferringMulticolor() // let image = UIImage(systemName: "flag.fill", withConfiguration: config) // // palette // let config2 = UIImage.SymbolConfiguration(paletteColors: [.systemRed, .systemGreen, .systemBlue]) // let image2 = UIImage(systemName: "person.3.sequence.fill", withConfiguration: config2) // // hierarchical symbols // let config3 = UIImage.SymbolConfiguration(hierarchicalColor: .systemIndigo) // let image3 = UIImage(systemName: "square.stack.3d.down.right.fill", withConfiguration: config3) // // color // let image4 = UIImage(systemName: "cone.fill")?.withTintColor(.systemRed, renderingMode: .alwaysTemplate) // annotationView.image = image4 annotationView.image = UIImage(systemName: "poweron", withConfiguration: configuration) } return annotationView }

The https certificate has expired

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.

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)

Hi, We are using beacon ranging methods to detect beacon in foreground and background in our app. We are using beacon's UUID, major and minor values to create a beacon region and then calling locationManager.startRangingBeacons to range beacons. We listen for beacon updates via the didRangeBeacons delegate method to get beacon data emitted. However, we've observed some inconsistent behavior: The beacon region frequently reports exit events even when the device is within close proximity (approximately 1.5 to 2 meters). There are instances where no beacon updates are received for extended periods (up to 15–20 minutes), despite the beacon being nearby. Generally, The distance between the device and the beacon is approximately 1.5 - 2 meters. What could be the reason for this behaviour and how can we avoid it and continuously receive beacon updates when the beacon is near without any delay? Thanks

Hello 👋🏼, We are using MapKit JS to display maps on our application working on two domains .com and .cn. Everything is working for all ours users in the world except for users using Chinese local network. After investigation, there is an error display in the browser console: [MapKit] Initialization failed because the authorization token is invalid. As the tokens are used as they are for the rest of the world, we know that they are valid... 😕 Problem appears on all browsers: Current versions of MapKit JS mapkit-typescript @ 5.18.2 https://cdn.apple-mapkit.com/mk/5.49.x/mapkit.js Do you have any tips, suggestions to help us 🙏 ? Aurélien.

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?

Since iOS 26 the delegate method locationManager(:didVisit:) is no longer invoked reliably while locationManager(:didUpdateLocations:) continues to be called regularly on the same devices. The issue appears to be directly tied to iOS version updates. Visit callbacks worked consistently under iOS 18.x but in some cases stopped being invoked immediately after updating the same device to iOS 26.0. In other cases didVisit worked on iOS 26.0 but stopped after updating to 26.0.1 and similarly from 26.0.1 to 26.1. The behaviour is inconsistent with no identifiable pattern and affects multiple recent device models. All required configuration is in place: – startMonitoringVisits() is called correctly – location permission is set to “Always”– background mode for location updates is enabled – allowsBackgroundLocationUpdates is enabled – restarting the app or the device does not fix the problem The only workaround that restores visit monitoring is deleting the app and reinstalling the same App Store version which is not a viable solution for end users. Have other developers experienced the same issue and are there any recommended best practices or technical guidelines to handle missing didVisit callbacks after updating to iOS 26?

1. The Inquiry Hello, I have been implementing a background geofencing feature and, during testing, I found a significant numerical difference in event callback frequency between the older CLCircularRegion API and the newer CLMonitor API (CLMonitor.CircularGeographicCondition), introduced in iOS 17. My testing was strictly conducted using the "Always Allow" location permission (requestAlwaysAuthorization()). I used both APIs in parallel under identical geofencing conditions and within the same implementation environment. Since a clear difference persists in the data, I suspect this may stem from structural differences in the internal mechanisms of the two APIs rather than an implementation error on my part. 2. Environment and Implementation Details (Proof of Integrity) I have ensured that my implementation adheres to Apple's guidelines and uses modern Swift concurrency features. A. Development Environment and Permissions iOS Version: iOS 18.x and later Xcode Version: Version 17A400 (Version 26.0.1) Location Authorization: Always permission obtained. Background Mode: Location updates is configured correctly in Info.plist. B. CLMonitor Initialization and Lifecycle I implemented robust lifecycle management to ensure CLMonitor is stable and persists correctly: Initialization: I performed CLLocationManager object allocation and related service setup (e.g., CLServiceSession set to always) within the call stack frame of didFinishLaunchingWithOptions. Monitor Management: I use an Actor-based Singleton pattern to guarantee that only a single CLMonitor instance is used application-wide. Event Monitoring: Following initialization, I allocated a background Task containing the for try await event in await monitor.events loop. This Task is explicitly managed to persist in the background until the application is terminated, ensuring continuous event listening. C. Registration Limit Management I manage both APIs to ensure they never exceed the recommended maximum of 20 simultaneously monitored regions/conditions. My logic removes the oldest item (LRU) when the limit is reached. The average registration counts during the test period were highly similar: Component Average Registered Count CLCircularRegion count 7.02 CLMonitor.CircularGeographicCondition count 7.04 This confirms that registration count is not the cause of the event frequency difference. 3. Data-Based Observation The test data (bubble_test_data_for_apple_forum.csv) records the event callbacks for both APIs under identical conditions: Component Total Count Percentage of All Events (%) CLCircularRegion Delegate Total Calls 617 83.56% CLMonitor Event Total Fires 122 16.44% Overall Total Count 739 100% A. Key Findings CLCircularRegion Operability: 617 calls confirm that core implementation factors (permissions, background setup, etc.) are functioning correctly. Disparity in Frequency: Despite running in parallel, the CLMonitor event count (122) is approximately 1/5th the frequency of the CLCircularRegion calls (617). Efficiency per Registration: CLCircularRegion averaged ~0.86 calls per registered item, while CLMonitor averaged only ~0.17 calls per registered item. 4. Questions for Apple Engineering Based on the robust implementation and the data presented, I request a review of the following potential differences between the APIs: Internal Mechanism Differences: Are there structural differences in how CLCircularRegion and CLMonitor.CircularGeographicCondition process and schedule geofencing event callbacks? For instance, do they differ in terms of battery optimization priority, event batching, or internal throttling mechanisms? CLMonitor Event Ratio: Is the phenomenon where CLMonitor records a significantly lower ratio of events compared to CLCircularRegion an intended behavior, or could this be indicative of a specific environmental factor that affects the newer API differently? Thank you for your time and assistance. geofence-test-data.csv

I'm following: https://developer.apple.com/documentation/applemapsserverapi/creating-a-maps-identifier-and-a-private-key#Create-a-Maps-ID to create map id and private key. On step #4 I can't find "Maps IDs checkbox" on the web page, blow is the screen capture which contains all options I have on my page:

In MapKit, the MKAnnotation takes a CLLocationCoordinate2D. However, in 3D/Flyover mode, the user marker has a height position on the map. We are currently plotting points which have altitude, speed, heading, etc, and I have a method for creating a CLLocation with this information. What I'm trying to figure out is if there's a way to pass that information along to the MapKit rendering engine / annotations / AnnotationViews to recognize and show when in 3D mode. Is there any support for that currently?

Downloaded example app from here Xcode version: Version 26.1.1 (17B100) Simulator iOS Version: 26.1 & 18.5 Set custom location in the simulator to the center of the condition being monitored in the example. The only log entry was "Setup Monitor". Tried a custom gpx starting at the same point and moving 500m away. Same logs. Didn't change any of the source code, granted always permissions, allowed notifications, tapped "AddCircularGeographicCondition". Let me know if there is something I am missing or more information I can provide.

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?