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

I just submitted a feedback for this (FB9662125) but in the spirit of “share and enjoy”… The cool new Generate Info.plist File feature in Xcode 13 crashes if you try to put an NSLocationTemporaryUsageDescriptionDictionary in your Info.plist file. Here’s a simple repro scenario: Create a minimal iOS app (no Core Data, no tests) Go to target settings → Info tab → Custom iOS Target Properties Click the (+) button on any row to begin inserting a new row Select Privacy - Location Temporary Usage Description Dictionary Click somewhere else or press Return to commit the selection Xcode crashes immediately More generally, it seems that Xcode crashes any time it tries to regenerate your Info.plist file if it contains an NSLocationTemporaryUsageDescriptionDictionary, even if (for example) you manually pasted that dictionary into the file earlier. In that case, merely tapping the (+) button in step 3 above is enough to crash it.

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

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

I created my app. One of its functionality is receive remote notification in the background (it receives it from Firebase Cloud Messaging via APNS) and replies with device location data. This is "boat tracking and alarm" type of app. It worked well both on my iPhone (where I use the same Apple ID as on developer's account) and on my son's iPad (different Apple ID). After the first review, when app was rejected with some remarks, background remote notifications completely stopped working on my iPhone. It looks like my iPhone put the app in permanent sleep. It never receives the background notifications. It receives them though in 2 case: when I open the app (it is no longer in background) when location is changed (it wakes app in the background). But the app should also respond when the device is stable at the position (I use both: precise and Significant Location Change. In the latter case changes are very rare). Btw, I scheduled a background task, not location, and it also never gets executed, so this workaround does not work. I describe it, so any Apple engineer does not get confused, verifying that these remote notifications reach the device. NO, they never get through when app is in the background (THIS IS THE PROBLEM), not that they are never delivered (the are, in the foreground). And the proof that it is not a problem with the app or remote notification construction is: they work on another drives (iPad) with no issues. Sometimes they are very delayed, sometimes almost instant. But usually they work. they worked the same way on my iPhone (with my developer's Apple ID) before the first rejection, and I haven't messed with messaging functionality since then. Now I am over with the last hope I had. I finally got my app release in App Store. I hoped official version would release some blockade my iOS put on my app. But unfortunately not. Official version works the same way as the test one. It works fine (receiving notifications in the background) on my son's iPad and it does not receive any background notification on my iPhone (100% block rate). Can anyone help me how can I reset my apps limits, the iOS created for my app? It seems that the rejection was a sparkle here - this is just a hint. I can provide any system logs for Apple engineers from both devices (iPhone and iPad) if you would like to check this case.

My code was running with with the version before Xcode 26 RC. I recompiled one last time. Now I'm getting the error: A server with the specified hostname could not be found let now = Calendar.current.date(byAdding: .hour, value: 1, to: Date())! let nextWeek = Calendar.current.date(byAdding: .day, value: 14, to: Date())! do { let (dailyForecast, hourlyForecast, currentWeather, alertWeather) = try await weatherService.weather(for: thisLocation, including: .daily, .hourly(startDate: now, endDate: nextWeek), .current, .alerts) Suggestions?

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.

In the last few months we have seen a lot of the following errors in which it fails to retrieve location information. This seems to happen across multiple browsers and feels related to apple/mac OS more than the browsers. Error: "CoreLocationProvider: CoreLocation framework reported a kCLErrorLocationUnknown failure." Any suggestions or an ETA on when this can be fixed? I have seen other threads/posts on this but wanted a new one to highlight the issue is prevalent.

Dear Apple Team,​ We are reaching out regarding several compatibility issues our app users have encountered after upgrading to iOS 26. These issues not only affect our application but also seem to impact the system's native settings, which has raised concerns about the universality of these problems.​ Problem Description​ Bluetooth Functionality: When users attempt to use the Bluetooth feature within our app after upgrading to iOS 26, the app freezes completely. What's more, when accessing the Bluetooth section in the system Settings app, it also freezes and ultimately crashes.​ Location Service: The location service on the device becomes inoperable after the iOS 26 upgrade. However, both the Bluetooth and location service issues are resolved after the user restarts the device.​ 2. Questions​ Universality: We are eager to know if these issues are exclusive to our app or are a more widespread problem among other applications on iOS 26. Are these known compatibility glitches in iOS 26? ​ Avoidance: Is there any guidance or best - practice that we, as developers, can follow to avoid these issues in our app? For example, are there specific API calls or configurations that need to be adjusted? ​ System - level Impact: If these are system - level bugs related to Bluetooth and location services, will they affect all apps that rely on these features? Or are there certain app - level mitigations that can be implemented? ​ We would greatly appreciate it if you could provide us with any insights, solutions, or information regarding these issues. Your prompt response will be crucial for us to address these problems and ensure a smooth user experience for our customers.​ Thank you in advance for your assistance.​ Best regards,

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!