We have a setup that's really close to the one used in the example project - Monitoring location changes with Core Location. In short, we have a flag that indicates whether or not we should start background location monitoring. If the flag is on, after the app starts, we Create a CLServiceSession with authorization: .always Create a CLBackgroundActivitySession The user can perform an action (press a button) to toggle the flag off, in which case we invalidate and dispose of the CLServiceSession and CLBackgroundActivitySession instances and cancel any liveUpdates observation. So far, so good, everything works as expected. However, we're experiencing a weird behavior on iPhones with Dynamic Island after there's an app update. When the user is on the same app version, the behavior is correct. have the flag on, background location monitoring works fine, when the app is in the the background, there's correctly a location indicator in Dynamic Island the user can go back to the app and turn the flag off (disposing of instances, cancelling location observation), and when the app is in the background, there is no location indicator in Dynamic Island The problem arises when the user updates the app open version 1.0 of the app have the flag on, background location monitoring works fine, when the app is in the the background, there's correctly a location indicator in Dynamic Island download an app update - version 2.0 the app restarts, didFinishLaunchingWithOptions gets called again and we start the background services dynamic island indicator is correctly showing a location indicator the user goes into the app, toggles the flag off - turning location observation off, we dispose of everything now, when the app is moved to the background, there's still a location indicator in the Dynamic Island, even though we're no longer observing location The indicator is hard to get rid of, there are only 2 ways we've found restart the device, or uninstall the app The question is - is this a bug in the system? Or is there anything we should be doing actively after an app update? 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’ve just updated to Simulator 16.0 (104.1) I’m currently developing my first app, which relies heavily on location data. It was simulating correctly before I updated Simulator. Since the update it is no longer receiving location data. Is anyone else experiencing this problem?

Hello, I’ve done a lot of testing of location services running in background with various settings, but in all scenarios location updates pause after a couple of hours, especially overnight In sleep mode. My app, for personal safety, requires regular location updates to 5m accuracy every minute. The only solution I have found is to keep the app in foreground. Location always stops updating. Background mode stops updating. Live location services stops updating. Is there a solution I may have missed other than keeping app in foreground? thank you, Brendan

Hi, I'm using MapKit's MKDirections.calculate, calculateETA, and reverse geocoding (via CLGeocoder.reverseGeocodeLocation) in my iOS app. I understand that there are undocumented rate limits for these services to prevent abuse, but I couldn't find official details. I would like to know: Are the rate limits applied per device, per app installation, or are they shared across all users of the same app bundle ID? Is there any guidance on how to design these features to avoid hitting rate limits in a production environment? What is the best practice if a user repeatedly triggers routing or reverse geocoding (e.g., typing or moving the map)? Any clarification or official documentation would be greatly appreciated. Thank you!

The other day I was playing with iBeacon and found out that CLBeaconIdentityConstraint will be deprecated after iOS 18.5. So I've written code with BeaconIdentityCondition in reference to this Apple's sample project. import Foundation import CoreLocation let monitorName = "BeaconMonitor" @MainActor public class BeaconViewModel: ObservableObject { private let manager: CLLocationManager static let shared = BeaconViewModel() public var monitor: CLMonitor? @Published var UIRows: [String: [CLMonitor.Event]] = [:] init() { self.manager = CLLocationManager() self.manager.requestWhenInUseAuthorization() } func startMonitoringConditions() { Task { print("Set up monitor") monitor = await CLMonitor(monitorName) await monitor!.add(getBeaconIdentityCondition(), identifier: "TestBeacon") for identifier in await monitor!.identifiers { guard let lastEvent = await monitor!.record(for: identifier)?.lastEvent else { continue } UIRows[identifier] = [lastEvent] } for try await event in await monitor!.events { guard let lastEvent = await monitor!.record(for: event.identifier)?.lastEvent else { continue } if event.state == lastEvent.state { continue } UIRows[event.identifier] = [event] UIRows[event.identifier]?.append(lastEvent) } } } func updateRecords() async { UIRows = [:] for identifier in await monitor?.identifiers ?? [] { guard let lastEvent = await monitor!.record(for: identifier)?.lastEvent else { continue } UIRows[identifier] = [lastEvent] } } func getBeaconIdentityCondition() -> CLMonitor.BeaconIdentityCondition { CLMonitor.BeaconIdentityCondition(uuid: UUID(uuidString: "abc")!, major: 123, minor: 789) } } It works except that my sample app can take as long as 90 seconds to see event changes. You would get an instant update with an fashion (CLBeacon and CLBeaconIdentityConstraint). Is there anything that I can do to see changes faster? Thanks.

Hi all, We’re running into a challenge with our iOS app DriveSmarter, which uses background location updates when connected to a physical Bluetooth device (e.g., dash cam, radar detector). For battery efficiency, we disable location services in the background when no device is connected. The problem we’re now facing is: How can we programmatically re-enable location services when a Bluetooth device reconnects while the app is still in the background? From what I understand, Core Location doesn’t allow re-enabling background location updates unless the app returns to the foreground. But our core use case requires this to happen seamlessly in the background when the user starts driving and the device connects again. To clarify: We stop location updates when the device disconnects. We want to resume location updates only when the device reconnects, even if the app is still in the background. Manually bringing the app to the foreground is not a reliable or user-friendly option. So my questions: Is it possible to programmatically restart background location services upon a Bluetooth connection event while staying in the background? If not, are there any best practices or Apple-recommended alternatives to achieve a similar result? Any guidance, patterns, or creative solutions would be greatly appreciated! Thanks in advance

Our backend management system uses Google for Location, and Apple Maps is just one of the solutions in our map component. When should I convert coordinates to GCJ02? Maybe you would say that when you are in mainland China？ BUT NOT AT ALL! What if the user does not enable location permission? What if the user has not inserted a SIM card? Or not Chinese SIM card but location in China? OR the user location in China, But use VPN with en overseas IP? All solutions are not perfect, unless you open the API to developers and tell us whether Apple Maps currently uses the wgs84 coordinate system or gcj02, which is the most reliable.

One of my apps includes a free weather forecast using WeatherKit. Recently, it started to get more downloads and almost reached the limits of the free tier. I've removed the forecast in newer versions but there's still a substantial amount of users who do not update their apps. Is it possible to somehow remove the capability from existing apps? Thank you!

The problem is that the favorite buttons are reversed: people already marked as favorites show the ‘Favorite’ button, while those who aren’t show ‘Unfavorite’.

My IMDF tour is stuck at Occupants Data in Review

Hi, I am creating a Driving Behaviour Monitoring app in which I range beacons and I require location updates in foreground, background and in terminated state all the time. I am using CLServiceSession with "Always Authorisation" to get location events. I create CLServiceSession object in the foreground and start monitoring driving and then re-create it when the app is relaunched after termination. Doing this works fine. But sometimes when app is terminated and is not opened again, the app runs on its own even when the device is stationary ( I can see the app is using Location in the Control Centre) and after that Location updates are not received and I am not able to track the driving behaviour. I tried to add diagnostics to know the cause and found "Insufficiently In Use" and then "Service Session Required" in the diagnostics. It would be of great help if the proper usage of CLServiceSession is provided. Important Question: When does the CLServiceSession gets invalidated or destroyed that was created when the app was in foreground ? What happens to the CLServiceSession which was created in the foreground if the app is not opened for long duration, let's say a day or two?

Our IMDF indoor maps submission is stuck on "Occupants data in review" for several months and I can't ahold of that team (their email doesn't work). I've been told they have a backlog, but the other steps were pretty fast. How long is the expected completion? Thank you!

I'm trying to scan for Beacon's in a visionos app iBeacon detection via CoreLocation (like CLBeacon or CLBeaconRegion) isn't supported on visionOS, so I went for CoreBluetooth + Manual Beacon Parsing Problem is I don't get my beacons scanned, only the other bluetooth devices central.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey:true]) what should I do?

I tried detecting fake locations using CLLocationSourceInformation.isSimulatedBySoftware, but it doesn’t work with spoofing tools like iTool AnyTo. It never gets flagged as simulated. Is this a limitation of the API, and is there any recommended way to detect virtual location tools on real devices?

I'm currently testing the CLMonitor API and have a question about CLServiceSession management. When my app is relaunched from a terminated state in the background due to CLMonitor events, do I still need to create and maintain a CLServiceSession instance? I'm wondering if CLServiceSession is necessary even when I don't need to continuously receive GPS updates through liveUpdates. Since CLMonitor can trigger app launches for region monitoring events without requiring constant location updates, I'm unclear about whether the CLServiceSession is still required in this scenario. Any clarification on the proper implementation would be greatly appreciated. Thanks!

As GeoCoder is now deprecated I am struggling to get the country only information from the new MKReverseGeocoding. Maybe someone can guide me or give me direction? Or is this just not possible anymore? let request = MKReverseGeocodingRequest(location: self.lastLocation ?? fallbackLocation) request?.getMapItems { items, error in guard let items = items else { return } self.cityName = items.first?.addressRepresentations?.cityWithContext ?? "" self.countryName = items.first?.addressRepresentations?.regionName ?? "" } I couldn't find anything here, sure you can get the full Address but I need single values to store so the user can search for (example City, Country) In case the structure is always the same, let us say the country is always third part, sure I could split the string but it is not a reliable way to do this, at least for me. Any help would be much appreciated.

Hello, CLServiceSession is not on macOS. Does anyone have a drop-in CLServiceSession like replacement for macOS that wraps CLLocationManager? I would like to migrate to the latest for the other platforms. FWIW I filed FB17910626 Thanks!

Pinned 2 homes address for the same contact Steps Initial check in Apple Maps No saved places or pinned addresses appear. Open Personal Contacts You have two addresses stored in your contact card: Main and Home. Pin & Edit “Main” You pinned the Main address in Maps. Refined the location on the map. Renamed it (but still saved under the type “My Home”). Open “Home” Address in Contacts Refined the location again. Changed the type to “My Home.” Attempted to rename, but no option to change the label. Final Saved Places View Shows two entries both called “Main.” Opening either of them displays the same details for the Home address. Saved Places list only shows the full address text, without the ability to rename them inside Maps. Results Both addresses appear duplicated with the same name (“Main”), even though they point to different underlying addresses. When selecting either entry, Apple Maps incorrectly shows the same Home address details. The Saved Places section does not allow renaming; it defaults to showing the full address string. Issues Identified Sync Conflict Between Contacts & Maps Apple Maps pulls labels/types from Contacts, but the edits don’t update consistently across apps. Duplicate Naming Bug Both “Main” and “Home” collapse into “Main” in Saved Places, making them indistinguishable. One-to-One Mapping Failure Regardless of which saved place you open, Maps shows the same Home entry, meaning the system isn’t correctly binding each saved place to its respective contact address. Renaming Limitation Apple Maps doesn’t allow renaming saved addresses directly — it relies on Contacts. Since Contacts only supports preset labels (Home, Work, School, etc.), custom naming is blocked.

I'm experiencing app crashes when calling the CLMonitor initialization function: let monitor = await CLMonitor("my_monitor") According to WWDC 2023: Meet Core Location Monitor, when creating a CLMonitor object with the same identifier, it should access the existing monitor without any mention of app crashes or buggy behavior. However, in my actual testing, attempting to create a CLMonitor object with the same identifier immediately causes an app crash. Here's part of the crash log: Last Exception Backtrace: 0 CoreFoundation 0x19c4ab21c __exceptionPreprocess + 164 (NSException.m:249) 1 libobjc.A.dylib 0x199945abc objc_exception_throw + 88 (objc-exception.mm:356) 2 Foundation 0x19b7a9670 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 (NSException.m:252) 3 CoreLocation 0x1aa25cbb4 +[CLMonitor _requestMonitorWithConfiguration:locationManager:completion:] + 516 (CLMonitor.mm:516) 4 libswiftCoreLocation.dylib 0x22bf6085c CLMonitor.init(_:) + 488 (CLMonitor.swift:280) 5 libswiftCoreLocation.dylib 0x22bf604b9 <deduplicated_symbol> + 1 6 MiniPlengi 0x106372ec9 closure #1 in static CLMonitor.loplatMonitor.getter + 1 (CLMonitor+Extensions.swift:31) 7 MiniPlengi 0x1062ce325 0x106290000 + 254757 8 MiniPlengi 0x1062f6a29 specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1 (/<compiler-generated>:0) 9 MiniPlengi 0x1062ce325 0x106290000 + 254757 10 libswift_Concurrency.dylib 0x1a7f75241 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:537) Furthermore, even though I've written code to create CLMonitor objects based on a singleton structure to handle these crash cases, the app still crashes: extension CLMonitor { static var loplatMonitor: CLMonitor { get async { struct Static { static var monitor: CLMonitor? static var initializationTask: Task<CLMonitor, Never>? } // If already initialized if let monitor = Static.monitor { return monitor } // If there's an initialization task in progress, wait for its result if let task = Static.initializationTask { return await task.value } // Create new initialization task let task = Task { let monitor = await CLMonitor("my_monitor") Static.monitor = monitor Static.initializationTask = nil // Clean up task after completion return monitor } Static.initializationTask = task return await task.value } } } Is the CLMonitor API still in a stabilization phase and not recommended for production release? I would appreciate guidance on the correct usage. If these issues are expected to persist, I'm wondering if I should continue using the existing CLCircularRegion API instead. Any insights or recommendations would be greatly appreciated.