Issue Summary Our app integrates two third-party telematics SDKs that each create their own CLLocationManager: Core Engine — continuous GPS, geofence monitoring, and significant location changes for trip telematics Radar SDK — location tracking that can enable startMonitoringVisits() (CLVisit) When Radar visit monitoring is enabled, Core Engine experiences severe location data loss — sparse or missing didUpdateLocations callbacks during active trip recording, despite Core Engine calling startUpdatingLocation() with: desiredAccuracy = kCLLocationAccuracyBest distanceFilter = kCLDistanceFilterNone pausesLocationUpdatesAutomatically = false allowsBackgroundLocationUpdates = true When Radar visit monitoring is disabled, Core Engine location behavior returns to normal on the same devices and iOS versions. The issue is reproducible in field testing and is not isolated to a single iOS version. Expected Behavior Per our understanding of Core Location: Each CLLocationManager instance should deliver delegate callbacks to its own delegate independently. startMonitoringVisits() should provide visit arrival/departure events without materially degrading continuous startUpdatingLocation() on a separate CLLocationManager in the same app that is configured for high-accuracy continuous tracking. Actual Behavior With Radar CLVisit enabled: Core Engine’s CLLocationManager receives far fewer or no didUpdateLocations callbacks during periods when continuous updates are required (e.g. active driving). Telematics data is incomplete or missing. Behavior is worse when the Radar SDK initializes before the Core Engine SDK. Disabling startMonitoringVisits() in Radar resolves the issue without other Core Engine code changes. Technical Notes Two separate CLLocationManager instances, separate delegates. Visit monitoring appears to affect app-wide location behavior, not only the manager that registered it. Geofence usage across both SDKs may approach the ~20 region limit, but data loss persisted even when geofence count was within limits in our tests. Issue reproduced across multiple iOS versions, not tied to a single OS release. Request to Apple We would appreciate guidance on the following: Is it expected that startMonitoringVisits() on one CLLocationManager can significantly reduce or suppress didUpdateLocations on a separate CLLocationManager configured for continuous high-accuracy tracking in the same app? If yes, is there documented guidance for running visit monitoring alongside continuous location in multi-SDK apps? Is there a recommended pattern (shared manager, ordering, capability flags, background session APIs) for multiple SDKs needing different location strategies in one process? Should this be treated as a bug or documentation gap?

Hello I started using CLMonitor on my App, and I am noticing the following crash on Xcode Organizer for dozens of my app users: Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000001 Exception Codes: 0x0000000000000001, 0x0000000000000001 VM Region Info: 0x1 is not in any region. Bytes before following region: …………. REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT ………-…….. [ 176K] r-x/r-x SM=COW /var/containers/Bundle/Application/.........../MyApp Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler […..] Thread 4 name: Thread 4 Crashed: 0 libswiftCoreLocation.dylib 0x000000021680b4c8 @objc completion handler block implementation for @escaping @callee_unowned @convention(block) (@unowned CLMonitor) -> () with result type CLMonitor + 44 (<compiler-generated>:0) 1 CoreLocation 0x0000000196cdddd4 __76-[CLMonitorConfiguration vendMonitorWithIdentityAndAuthorizationAttributes:]_block_invoke + 216 (CLMonitorConfiguration.m:195) 2 libdispatch.dylib 0x0000000191138370 _dispatch_call_block_and_release + 32 (init.c:1549) 3 libdispatch.dylib 0x000000019113a0d0 _dispatch_client_callout + 20 (object.m:576) 4 libdispatch.dylib 0x00000001911416d8 _dispatch_lane_serial_drain + 744 (queue.c:3934) 5 libdispatch.dylib 0x00000001911421e0 _dispatch_lane_invoke + 380 (queue.c:4025) 6 libdispatch.dylib 0x000000019114d258 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 7 libdispatch.dylib 0x000000019114caa4 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 8 libsystem_pthread.dylib 0x0000000211933c7c _pthread_wqthread + 288 (pthread.c:2696) 9 libsystem_pthread.dylib 0x0000000211930488 start_wqthread + 8 Does anyone have similar issue when using CLMonitor? How can I debug / fix this issue? Is it an CLMonitor API bug? Should I file a bug report?

我想使用苹果地图Api，我需要地图长期令牌或密钥 1.如果创建地图令牌仅7天到期（p1），我需要一个长寿命令牌。 2.如果像p2那样创建地图金鑰，則沒有MapKit 3.如果创建地图密钥需要首先创建一个标识符，如p3和p4，没有地图ID 那么，从长远来看，我到底应该如何有效地使用Map Server API呢？ p1 : linkText p2: linkText p3: linkText p4: linkText

After upgrading to iOS 27 Beta 3, iBeacon region monitoring no longer behaves as it did on previous iOS versions. Issue 1 – Never exits region After connecting to an iBeacon, I power off the beacon and move several kilometers away. The app never receives an Outside (didExitRegion) event. Even after force quitting the app, powering off the beacon, locking the screen, and turning the screen back on, iOS may relaunch the app as if it were still inside the beacon region. Is this an intentional change in iOS 27 or a bug? Issue 2 – Sometimes never enters region Occasionally, the app is not awakened when entering the iBeacon region. No Inside event is delivered. The only way to recover is to manually scan and reconnect to the beacon. Otherwise, the app is never awakened by the iBeacon again. This worked reliably on iOS versions before iOS 27.

I’m developing a sandboxed macOS app with a Quick Look extension that previews user-selected files. The preview includes an interactive MapKit map showing the route from the file During TestFlight review, Apple rejected temporary entitlement exceptions for: com.apple.security.temporary-exception.files.home-relative-path.read-only /Library/Caches/GeoServices/ com.apple.security.temporary-exception.mach-lookup.global-name com.apple.geoanalyticsd I understand these temporary exceptions are not appropriate for Mac App Store distribution and will remove them. What is the supported sandbox-compliant way to use MapKit inside a macOS Quick Look extension? Should an interactive MapKit view work inside a sandboxed Quick Look extension without temporary exceptions, or is MapKit unsupported in this extension context? If interactive MapKit is not supported, is MKMapSnapshotter the recommended alternative, or should the extension render a route-only preview without Apple map tiles? Any guidance on the expected entitlement/capability setup for this scenario would be appreciated.

Hi all, I am unable to use Apple Maps Navigation or direction. I can explore maps but the function for navigation is not available. Phone Model: iPhone 15, iOS version: 26.5.2 (latest). Model No. NTML3AH/A. Location Service Enables, Location permission for Apple Maps: While using the APP, Precision location: Enabled. Can anyone help me out to use Apple Maps navigation? Thank you in advance

I did not modify in any way the relative code when porting to Swift 6, still locationManager( _ manager: CLLocationManager, didUpdateLocations locations: [CLLocation] ) is never called, notwithstanding of course there is the property in the info files and all required steps were performed. What did change in Swift 6 hampering the calling of the location callbacks?

Hello, I would like to report an inconsistency in Apple Maps regarding place names in the Balearic Islands when using Apple Maps in Spanish. Most official place names in the Balearic Islands are displayed correctly. For example, Apple Maps correctly shows names such as Eivissa, and other Balearic municipalities also appear with their official names. However, there are still some incorrect cases, especially: Maó, which is still displayed incorrectly (shown as "Mahón") Sant Francesc de Formentera, shown as "San Francisco Javier" This does not seem consistent, because Apple Maps already respects the official Catalan/Balearic place names in most other cases. Until recently, Ciutadella was also displayed incorrectly, but after months of reporting the issue, it has finally been corrected. This shows that the correction is possible and that the current remaining cases are likely data inconsistencies. Other major platforms such as Google Maps and Tripadvisor already display these names correctly. The official reference sources that should be used are the Instituto Geográfico Nacional (IGN) and the IDEIB / official geographic data of the Balearic Islands. https://www.ign.es/iberpix https://www.tripadvisor.es/Tourism-g642211-Mao_Menorca_Balearic_Islands-Vacations.html https://www.tripadvisor.es/Tourism-g1188767-Sant_Francesc_de_Formentera_Formentera_Balearic_Islands-Vacations.html The expected behavior would be for Apple Maps to use the official place names consistently across the Balearic Islands, including Maó and Sant Francesc de Formentera, just as it already does with Eivissa and other municipalities. Could Apple Maps review its geographic data for the Balearic Islands and align these names with the official sources? Thank you.

Dear Apple team, we have confusion about the test method for the specification that beacon-to-beacon transmit power average variation shall stay within ±5dB compared with the golden device. Could you kindly clarify the definition of the golden device, whether we should measure conducted or radiated Tx power, the averaging rule over advertising channels, required test sample quantity and environmental test conditions, and confirm if the ±5dB tolerance applies to each individual beacon’s average transmit power?

I draw a dashed line using MKPolyline in MapKit JS. Even though I set a fixed strokeWidth, the dashed polyline automatically becomes thicker every time I zoom in or out of the map. The line thickness scales along with the map zoom level.

Our current business goal is to improve the success rate of iBeacon wake-up on iOS. Apple's official iBeacon specification recommends a standard broadcast interval of 100ms; Now we are planning to shorten the broadcast frequency to 50ms, and we would like to consult the full dimensional impact of this change, and whether it can really improve the success rate of beacon identification and pull trigger on iOS devices.

We're using the iOS ibeacon APIs to wake up our app for vehicle bluetooth key and to enable the seamless walk-away features; Does the Measured Power value in the advertising packet affect an app’s background launch? If so, what is the mechanism? If not, what is the actual purpose of this field in Core Location? For different beacon devices/vehicle models, does this value need to be adjusted? For example, we have different vehicle models – should each model set this value based on actual calibration data? Our current understanding: Measured Power is typically used for our APP to do the distance estimation but we are not sure whether the system also uses it as a weighting factor for background wake‑ups or region triggers. We have noticed some discussions in forums about similar scenarios where it is mentioned that Measured Power needs to be set correctly.

Hello AD Forums, I am a member of the ADP and am working on an iOS app for the App Store. My app needs to match the user’s current location to one of Germany’s 400 district-level administrative areas: Landkreise and kreisfreie Städte. In Firebase, each region has a geoTagName field. The app compares the detected location name against this geoTagName to load the correct internal region document. I need to understand the recommended Apple/Core Location field for this use case. My current understanding is: CLPlacemark.administrativeArea usually represents the federal state in Germany, for example “Thüringen” or “Bayern”. CLPlacemark.locality usually represents the city, municipality, or town. CLPlacemark.subAdministrativeArea seems to be the most likely candidate for the German Landkreis / kreisfreie Stadt level. However, I need to know whether CLPlacemark.subAdministrativeArea is the correct and reliable field for identifying German Landkreise and kreisfreie Städte. I also tested Apple Maps Server API /v1/reverseGeocode. For district-level locations in Germany, it often returns values such as: administrativeArea: Thüringen locality: Bad Sulza but no value such as: subAdministrativeArea: Weimarer Land Example coordinate tested: 50.9957525, 11.5129989 My questions are: Is CLPlacemark.subAdministrativeArea the recommended field to identify German Landkreise and kreisfreie Städte in an iOS app? Are there known differences between iOS CLGeocoder.reverseGeocodeLocation and Apple Maps Server API /v1/reverseGeocode regarding subAdministrativeArea? Does Apple provide any official list, dataset, or recommended validation method for the exact district-level names used by Core Location / Apple Maps in Germany? How should an app distinguish cases where a kreisfreie Stadt and a Landkreis have the same name, for example: Stadt Augsburg Landkreis Augsburg Stadt Ansbach Landkreis Ansbach Stadt Aschaffenburg Landkreis Aschaffenburg Should administrativeArea be avoided for this use case because it represents the federal state level in Germany? The goal is to create reliable matching between the Apple/Core Location result and our Firebase geoTagName values. Thank you.

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

Hello, I would like to consult Apple’s technical team regarding how different iBeacon Bluetooth advertising packet configurations impact iOS app background wake-up performance. My specific questions are outlined below: We have two available iBeacon advertising configuration schemes: Scheme 1: Encapsulate the non-connectable iBeacon advertising payload and connectable Bluetooth advertising payload into a single advertising packet for transmission. Scheme 2: Split the two types of advertising payloads above into two separate independent advertising packets and broadcast them respectively. Could you please clarify which packet format enables iOS apps to detect and recognize iBeacon devices more reliably and easily, thereby triggering app background wake-up more effectively? I would appreciate it if you could explain the differences, advantages and disadvantages of these two schemes under iOS’s Bluetooth scanning and app wake-up mechanisms, as well as provide your official recommendations. Thank you very much for your assistance.

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Feedback Assistant reports have been submitted with sysdiagnose attached. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated? Feedback ID: FB23196632

WeatherKit never returns data for my app. Both the on-device API and the REST API fail at the authentication layer, which points to WeatherKit not being enabled at the backend for my team. On-device: WeatherService.shared.weather(for:including:.current) throws WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 on a real device, every time. REST API: I created a WeatherKit key and called the REST endpoints directly from my Mac (bypassing the app and the device entirely). Both return HTTP 401 {"reason":"NOT_ENABLED"}: GET https://weatherkit.apple.com/api/v1/weather/en/37.5665/126.978?dataSets=currentWeather GET https://weatherkit.apple.com/api/v1/availability/37.5665/126.978?country=KR Identifiers: Team ID: 5L3SCT446M App ID: com.saebom.weathergal (widget: com.saebom.weathergal.widget) WeatherKit REST Key ID: 2BGXGVFDX6 Everything on my side is verified correct: com.apple.developer.weatherkit entitlement is present in the signed binary AND in the embedded App Store provisioning profile (verified via codesign and by decoding the .mobileprovision). WeatherKit is enabled under App Services for the App ID. Apple Developer Program License Agreement accepted; Paid/Free Apps Agreements active. The WeatherKit Usage dashboard shows 0 of 500,000 calls used (the request never authenticates). I toggled the WeatherKit capability off/on and regenerated provisioning profiles; no change after several days. Likely cause: the WeatherKit capability was first enabled on 2026-06-09, while the updated Developer Program License Agreement (issued 2026-06-09) was not accepted until 2026-06-11. The backend WeatherKit token registration appears to have gotten stuck because it was created while the agreement was still pending. Could the WeatherKit/DTS team please verify and re-sync the backend WeatherKit token registration for Team ID 5L3SCT446M? I already filed FB23197482 with the same details. Thank you.

I'm creating an APP for the first time in Xcode, I have a part of a place search on a map, it has a card very similar to the iPhone map card, I want it to move to the left when it's horizontal and position itself there to see the information that slides up and down. What should I write in the code?

I generated an Apple Maps API key and Server API test token via Maps services, and checked it has a valid header and payload with jwt. Ive also generated a valid token with my AuthKey_.p8 file via PyJWT, however, I continue to get 401 error returned from my local server when trying to test hitting https://maps-api.apple.com/v1/api/searchAutocomplete?....

Hi, I'm working on a trip detection and recording app that relies on CLLiveLocationUpdates for the location tracking. We've observed a recurring issue where trip recording eventually stops working if the app is not opened for an extended period of time (approximately 2–3 weeks). What we observe The app continues to be installed on the device. The user does not manually open the app during this period. Eventually, trip detection and recording stop. Location diagnostics indicate: Service Session Required At this point, CLLiveLocationUpdates no longer appears to deliver location events. Recovery attempts We've tried several ways to recover without launching the app: Turning Location Services off/on Rebooting the device Changing location permissions None of these restore location updates. The only reliable recovery method we've found is: Open the app manually. Leave it running for some time. Kill the app again. After doing this, location tracking resumes and works normally for 4-5 days before eventually failing again with the same "Service Session Required" diagnostic. Questions Why would a valid location setup eventually transition into a "Service Session Required" state after the app has not been launched for several weeks? Are there any documented conditions under which an existing CLServiceSession expires, becomes invalid, or requires recreation? Is there a recommended way to recover from this state programmatically without requiring the user to manually launch the app? Is this expected behavior or a potential issue with CLLiveLocationUpdates / CLServiceSession? Additional details iOS version: 26 App uses: CLLiveLocationUpdates, Beacon Ranging & Beacon Monitoring, SLC updates, Motion Activity Updates Background location enabled: Yes Authorization type: Always Device models tested: iPhone 14 Pro Max Service session creation code: private var serviceSession: CLServiceSession? serviceSession = CLServiceSession( authorization: .always, fullAccuracyPurposeKey: "Trip" ) Has anyone else encountered a similar issue after long periods where the app is not launched? Thanks.