My app is currently using CLGeocoder to get a CLPlacemark, then using placemark.postalAddress with CNPostalAddressFormatter to get an attributed string for the full address, I then enumerate its attributes to pull out specific elements like just the street or state or zip etc. This is deprecated in iOS 26 with MKReverseGeocodingRequest being the intended replacement. This API returns an MKMapItem which doesn’t provide a CNPostalAddress - you can get a full address as a String but not structured address data that I’m seeing. Am I missing some way to get the postal address? Or is it a non-goal to provide that anymore? Thanks!

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.

We have developed an iPad application using the ARCL (AR + CoreLocation) library to render Point of Interest (POI) annotations in both an AR view and a standard MapView. The application performs as expected on standard devices. However, we have some iPad covered with strong magnet. This creates significant magnetic interference, resulting in a 90° to 180° heading offset, rendering the AR POI placement and MapView orientation unusable. Technical Challenges & Constraints: Hardware Lock: The magnetic cover is a mandatory business requirement and cannot be removed during field use. Sensor Failure: The internal magnetometer cannot provide an accurate North reference due to the proximity of the cover’s magnets. While CoreLocation and CoreMotion use sensor fusion, the magnetometer remains the primary source for absolute heading. Alternative Orientation Tracking: Is there a documented method to bypass the magnetometer and derive device orientation using only the Gyroscope and Accelerometer (e.g., relative tracking) while still maintaining alignment with geographic coordinates in CoreLocation? Programmatic Offsets: Are there known APIs or mathematical workarounds to programmatically "nullify" or offset a constant magnetic bias once the device is inside the cover? so we can use that offset for ARView and in Mapview as well.

The documentation for CLGeocoder states Geocoding requests are rate-limited for each app, so making too many requests in a short period of time may cause some of the requests to fail. (When the maximum rate is exceeded, the geocoder returns an error object with the CLError.Code.network error to the associated completion handler.) And it provides helpful guidance on how and when to submit geocoding requests. The documentation for MKReverseGeocodingRequest does not mention requests are rate-limited. Does this mean it is not rate-limited? If it is rate-limited, is it similar to CLGeocoder, what is its behavior? It is important to understand behavior of the API in order to understand impact on my app’s use case and how users will be affected should I change the implementation. Thanks!

Hello, This is my first post in the forums, and I'm still learning my way with iOS Development and Swift. My apologies if the formatting is not correct, or If I'm making any mistakes. I'm currently trying to implement an iOS App where the device needs to share the location with my server via an API call. The use case is as follows: the server expects location updates to determine if a device is inside/outside a geofence. If the device is stationary, no locations need to be sent. If the device begins moving, regardless of whether the app is in foreground, background, or terminated, the app should resume posting locations to the server. I've decided to use the CLLocationUpdate.liveUpdates() stream, together with CLBackgroundActivitySession(). However, I have not been able to achieve the behavior successfully. My app either maintains the blue CLActivitySession indicator active, regardless of whether the phone is stationary or not, or kills the Indicator (and the background capability) and does not restore it when moving again. Below I've attached my latest code snippet (the indicator disappears and does not come back). // This method is called in the didFinishLaunchingWithOptions func startLocationUpdates(precise: Bool) { // Show the location permission pop up requestAuthorization() // Stop any previous sessions stopLocationUpdates() Task { do { // If we have the right authorization, we will launch the updates in the background // using CLBackgroundActivitySession if self.manager.authorizationStatus == .authorizedAlways { self.backgroundActivity = true } else { self.backgroundActivity = false self.backgroundSession?.invalidate() } // We will start collecting live location updates for try await update in CLLocationUpdate.liveUpdates() { // Handle deprecation let stationary = if #available(iOS 18.0, *) { update.stationary } else { update.isStationary } // If the update is identified as stationary, we will skip this update // and turn off background location updates if stationary { self.backgroundSession?.invalidate() continue } // if background activity is enabled, we restore the Background Activity Session if backgroundActivity == true { self.backgroundSession = CLBackgroundActivitySession() } guard let location = update.location else { continue } // Do POST with location to server } } catch { print("Could not start location updates") } } } I'm not sure why the code does not work as expected, and I believe I may be misunderstanding how the libraries Work. My understanding is that the liveUpdates stream is capable of emitting values, even if the app has gone to the background/terminated, thus why I'm trying to stop/resume the Background Activity using the "stationary" or "isStationary" attribute coming from the update. Is the behavior I'm trying to achieve possible? If so, I'm I using the right libraries for it? Is my implementation correct? And If not, what would be the recommended approach? Regards

I am developing an Augmented Reality (AR) navigation application for the iPad, utilizing the ARCL library to place Points of Interest (POIs) in the real world. The application's behavior varies significantly based on the device's networking configuration: Cellular Network (Expected Behavior): On an iPad with a cellular modem, when using the cellular network, all POIs are placed accurately with correct orientation. Wi-Fi Only (Expected Behavior): On a Wi-Fi-only model (no GPS chip), POI placement is inaccurate, confirming the need for an external GPS receiver for that hardware configuration. Cellular + Wi-Fi (Anomalous Behavior): The iPad is a cellular model (equipped with GNSS/GPS). The device is connected to a Wi-Fi network (enforced via an MDM profile, preventing the user from disabling Wi-Fi). When actively connected to this specific Wi-Fi network, the AR POIs consistently display with an incorrect orientation and placement, even though the device hardware has a dedicated GPS chip. The placement error strongly suggests that the device's determined location or heading is erroneous. It appears that the active Wi-Fi connection is somehow interfering with or overriding the high-accuracy GNSS/GPS data, leading to a flawed Core Location determination that negatively impacts the ARCL world tracking and anchor placement. Has anyone experienced a scenario where an active Wi-Fi connection on a cellular iPad model causes Core Location to prioritize less accurate location data (potentially Wi-Fi-based location services) over the device's built-in GNSS/GPS, resulting in severe orientation errors? We observed that on Apple map(native application) as well it is showing wrong location and orientation when it is connected to WiFi

Hello, I’d like to ask about best practices for handling interactive snippet intents when working with the user’s location. My use case is: 1. Get the user’s location 2. Fetch nearby data 3. Display it My current flow is: try to show the snippet view in "loading" state while waiting for Core Location Manager, then fetch data and reload() the view. BUT I’m running into an issue where I sometimes receive Core Location error 1 (not authorized), even though the main app has “While In Use” authorization. It seems that in some cases, especially when the app has been force-closed, App Intents are unable to start location updates, even though I’m using supportedModes = .foreground(.dynamic). Any guidance would be appreciated. Cheers, Ondrej

I have been using the SCNetworkReachabilityGetFlags for 10+ years to inform users that their request won't work. In my experience this works pretty well although i am aware of the limitations. Now, i am looking into the NWPathMonitor, and i have one situation that i'm trying to. get my head around - it's asynchronous. Specifically, i am wondering what to do when my geofences trigger and i want to check network connectivity - i want to tell the user why the operation i'll perform because of the trigger couldn't be done. SO. say i start a NWPathMonitor in didFinishLaunchingWithOptions. When the app is booted up because of a geofence trigger, might i not end up in a case where my didEnterRegion / didExitRegion gets called before the NWPathMonitor has gotten its first status? The advantage here with SCNetworkReachabilityGetFlags, as i understand it, would be that it's synchronous? If i want to upgrade to nwpathmonitor, i guess i have to do a method that creates a nwpathmonitor, uses a semaphore to wait for the first callback, then contunues? Thoughts appreciated

System Information in macOS from 26.0 to 26.2 RC no longer provides Wi-Fi SSIDs; instead, it displays "< redacted> " for every SSID on my two MacBooks. This issue has been fixed in macOS 26.1 beta and macOS 26.2 beta, but it returns in the RC and the Final Release versions. Is it an expected behaviour or a bug in the Release Candidate? MacBook Air 2025: MacBook Pro 2021:

Our iOS app supports CarPlay capability with the Driving task. The app is also configured to wake in the background on geofence entry or exit events, even from a terminated (killed) state. We would like to understand how to detect whether CarPlay is connected to the iPhone when the app wakes up or runs in the background. In this case, the CarPlay app is not actively running in the Car infotainment system foreground. Requirement: The app should perform a background task only when CarPlay is connected, including when launched in the background or from a killed state due to a geofence trigger. Could you please advise on the recommended way or API to determine CarPlay connection status in this background scenario? Thanks for the support!

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

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?

In my app, I am using geofencing to perform an action when the user enter or leaves a specified location. The geofencing (CLMonitor) is active permanently, and should work across multiple app sessions or after the device is restarted. It should also work after the app was minimized or terminated. This worked perfectly with iOS 17 and prior, but with iOS 18, things changed. As soon as iOS 18 dropped, users were informing me that the app does no longer perform the entry/exit action reliably (without me making any changes to the app). Most of the times, events are missed entirely. Sometimes, after the user opens or resumes the app, duplicate events are delivered and/or events with the current time instead of the correct time of entry/exit. I am making sure that the app has the "Always" location permission before geofencing is enabled The gefocence radius is between 20 and 500m, but even with the max. radius specified, the geofencing is unreliable For the same user and geofence, the entry/exit event is delivered occasionally, but not always I am currently not using CLLocationManager.allowsBackgroundLocationUpdates (even though it's documented as "Apps that receive location updates when running in the background must include the UIBackgroundModes key (with the location value) in their app’s Info.plist file") because it wasn't necessary on iOS 17 and in my tests, using it didn't yield any improvements In my search for what could have caused this change, I found this WWDC video about location authorization: . It appears that with iOS 18, it is now required to have an active CLServiceSession to ensure that location updates are delivered to my app. Even though the video is long (and I've watched it multiple times), some things are still unclear. For example, the docs state: If your app actively receives and processes location updates and terminates, it should restart those APIs upon launch in order to continue receiving updates. Also, in the video it is stated that: ... So your job, ..., is to make sure that your process launch logic knows what features it has been tasked with pursuing, and re-takes session objects... But on the other hand it's also said that: you can only start holding one (a CLServiceSession) when your app is in the foreground and also ... CLMonitor.events won’t yield results when it is not in use, unless a session which was started in the foreground, .... To summarize my questions, for the geofencing to work as described above: when exactly do I need to create a CLServiceSession if the app is launched into the backgorund? Immediately in the applicationDidFinishLaunching method, even though the app is still in the background (applicationState is background)? Or later on, when the app is opened again by the user, e.g. in applicationDidBecomeActive (and applicationState is active)? do I need to specify the background mode capability as noted in the Handling location updates in the background article? do I need to create a CLBackgroundActivitySession as noted in the Handling location updates in the background article? does it matter, which of the four initializer methods I am using to create the CLServiceSession (with CLServiceSessionAuthorizationRequirementAlways)? does it matter if I specify NSLocationRequireExplicitServiceSession in the Info.plist or not when I already do ensure that the app has the "Always" location permission when the feature is being enabled Does a CLServiceSession last indefinitely and should it only be invalidated once the user disables the feature?

I am currently using Core location to get user's current location and few surrounding coordinates to draw annotations in Augmented reality. It works best on Cellular network and on Wifi network few times it is working ok and sometimes orientation is completely changed when device is connected to WiFi. Checked on Apple map as well, there itself it was giving wrong orientation and even after user is at same location, current location on map got fluctuating. On WiFi only models GPS accuracy is not good.

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?

Problem Description I am using CLLocationManager to obtain the device's compass heading (direction), and I have encountered an abnormal behavior: When the user is stationary: After calling startUpdatingHeading(), the CLHeading object returned in the locationManager(_:didUpdateHeading:) callback correctly reflects the device’s actual physical orientation (i.e., the direction the top of the device is pointing) in terms of magnetic north / true north, via the magneticHeading and trueHeading properties. When I rotate the device, the heading values change accordingly — this is the expected behavior. But when the user is in motion (e.g., driving a car): Even if I rotate the device, the values of magneticHeading and trueHeading no longer reflect the device’s actual orientation. Instead, they consistently return what appears to be the user's or vehicle's travel direction (forward direction). In other words, the compass behaves as if it is reporting the direction of motion rather than the device’s actual facing direction. Only after the user has completely stopped moving, does rotating the device again result in magneticHeading and trueHeading reflecting the actual device orientation as expected. However, on another device running iOS 16 (iPhone XR), this behavior does not occur — everything works normally. Expected Behavior I expect that regardless of whether the user is moving or not, the CLHeading values returned by CLLocationManager should always represent the physical orientation of the device itself (i.e., which direction the top of the device is pointing), as a standard compass should. Actual Behavior User is stationary, rotating the device: magneticHeading / trueHeading change properly according to the device’s actual orientation User is in motion (e.g., driving):magneticHeading / trueHeading remain fixed to the direction of motion (travel direction), and do not change when the device is rotated User stops moving, then rotates the device:Compass behaves normally again, reflecting the actual device orientation Environment Information iOS Version: iOS 26.0.1 Device Models: iPhone 15 Pro / iPhone 17 Pro Xcode Version: Xcode 26.0.1 Language: Objective-C Questions Is this a known issue in iOS? Are there any related radars or official documentation about it? Have other developers encountered similar issues, especially where CLHeading behaves incorrectly when the user is in motion? Do I need to set any specific parameters in CLLocationManager (such as headingOrientation) to resolve or work around this issue? 🙏 Thank you for your help — any insights, experiences, or official feedback regarding this issue would be greatly appreciated!

We have a that relies on accurate GPS location but we’ve noticed that every now and then the location ‘jumps’ a few hundred meters to a different location but reports horizonal accuracy less than 10m. we think the device is picking up a rough location from a local WiFi rather than internal gps sensors. can we a) disable WiFi location Updates? b) identify WiFi location Updates? thank You

Hello, We are a software and hardware development company for the forestry and environmental sectors. We have been based in Quebec (Canada) for over 30 years now. Our Canadian market covers Quebec, Ontario, and the Maritime provinces in the east. We are currently expanding across Canada and into the northern United States. We are on Android platforms with several map and data entry applications. To ensure the success of our expansion, we aim to become part of the Apple family, which is why we are contacting you today. We have developed our own GNSS receiver to increase the location accuracy of our users. This device is called GSFGPS. It uses Bluetooth BLE to communicate with mobile devices and a high-precision GPS that transmits its position using the NMEA protocol. We would like this device to be compatible with an iPhone/iPad. We have developed a mock location application in MAUI (multi-platform). Based on our interpretation of your documentation, we understand that the concept of mock location does not exist at Apple. How can we ensure that our Bluetooth GNSS device is compatible with your iPhone/iPad devices and that they can use the position of the Bluetooth device rather than the internal GPS of your devices? We are a reseller for Juniper Systems, and we know that they have an app on the App Store that has the same features as our product. https://junipersys.com/index.php/support/article/14709 We look forward to your follow-up and recommendations.

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)

Summary CLLocationSourceInformation.isSimulatedBySoftware (iOS 15+) fails to detect location spoofing when using third-party tools like LocaChange, despite Apple's documentation stating it should detect simulated locations. Environment iOS 18.0 (tested and confirmed) Physical device with Developer Mode enabled Third-party location spoofing tools (e.g., LocaChange etc.) Expected Behavior According to Apple's documentation, isSimulatedBySoftware should return true when: "if the system generated the location using on-device software simulation. " Actual Behavior Tested on iOS 18.0: When using LocaChange sourceInformation.isSimulatedBySoftware returns false This occurs even though the location is clearly being simulated. Steps to Reproduce Enable Developer Mode on iOS 18 device Connect device to Mac via USB Use LocaChange to spoof location to a different city/country In your app, request location updates and check CLLocation.sourceInformation?.isSimulatedBySoftware Observe that it returns false or sourceInformation is nil Compare with direct Xcode location simulation (Debug → Simulate Location) which correctly returns true