Apple's Location Services & Privacy notice (https://www.apple.com/legal/privacy/data/en/location-services/) describes per-app sharing of Visited Places and Preferred Routes/Predicted Destinations where available. We are investigating a transit companion with a watchOS app and an optional iPhone companion. We have checked public developer documentation and installed SDK interfaces but have not identified the API that delivers these shared records. Which public SDK interface, entitlement or enrollment process implements this capability for third-party apps? A documentation or sample link, with supported platforms and eligibility requirements, would let us build a minimal probe. We are asking about delivery of the shared records, rather than monitoring new visits with Core Location or supplying relevance hints to the system.

Hello, I develped underground GNSS solution. The goal of this is to achieve seamless GNSS for navigation and autonomous driving. The solution we developed has been installed in tunnel in Korea. We tested it using an Android phone and iPhone. We check the Android phone's response using the GNSSLogger App. however, there is not one for the iPhone. I want to make PERFECT solution in tunnel. So, how can I get GNSS log from and iPhone? Thanks.

iOS Background Location / Geofencing for Automatic Attendance — App Not Triggering Reliably We are developing an enterprise attendance application called Attendo, which uses location-based geofencing for automatic employee check-in/check-out. Business requirement The application needs to work as follows: An employee is assigned an office/work location with a defined radius. When the employee enters the configured radius, the application should automatically record a Check-In. When the employee leaves the radius, the application should automatically record a Check-Out. This should happen without the employee having to open the application. The functionality needs to work even when the application is in the background and, where supported by iOS, after the application has been terminated. For example: «Office geofence = 200 meters Employee enters the 200 m radius → automatic Check-In Employee leaves the 200 m radius → automatic Check-Out» Current iOS implementation We are using iOS location services with: Location permission: Always Precise Location: enabled Background Location capability enabled Background location updates enabled Geofencing / region monitoring The application is intended to respond to location/geofence events without requiring the user to open the app. However, we are seeing cases where the application does not reliably receive/process the required location/geofence event when the application has been in the background for an extended period. The same business workflow works more reliably while the application is active. Our concern Our understanding is that iOS does not allow an application to maintain a continuously running background service in the same way that Android can. However, our requirement does not necessarily require continuous GPS polling if there is an Apple-supported mechanism that can reliably wake/relaunch the application when a user crosses a geofence. We would therefore like to understand the recommended architecture for this use case. Questions Is Core Location Region Monitoring the recommended mechanism for an enterprise geofencing application that needs to detect entry/exit while the app is not running? Can iOS relaunch the application after it has been terminated by the user/system when a monitored region is entered or exited? Is there any supported way to guarantee that an application will continue receiving location/geofence events after it has been in the background for a long period? Does enabling: "UIBackgroundModes = location" "allowsBackgroundLocationUpdates" "CLLocationManager" Region Monitoring provide the expected behavior, or are there additional requirements/configurations we should consider? Are there known limitations regarding: Low Power Mode device movement speed GPS/location accuracy stationary devices iOS terminating/suspending the application force-quitting the application from the App Switcher large/small geofence radius multiple monitored regions Is it possible to use significant-change location updates + region monitoring together for this type of attendance workflow? For an enterprise application where the user explicitly grants Always Allow Location permission and Precise Location is enabled, what level of reliability can realistically be expected from iOS geofencing? Important business constraint We cannot require employees to manually open the application every time they arrive at or leave the workplace. The objective is an automatic attendance system, where the employee's entry and exit from the workplace geofence is detected by iOS and the application records the corresponding attendance event. We understand that iOS is designed to protect battery life and user privacy and that continuous background execution may not be permitted. We are therefore looking for the Apple-recommended architecture for achieving this requirement using supported iOS APIs, rather than trying to circumvent iOS background execution policies. Any guidance from Apple engineers or developers who have implemented reliable enterprise geofencing would be greatly appreciated.

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?

We are seeing a reproducible issue on a physical iPhone with Dynamic Island. Steps to reproduce Install and launch version 1 of the app locally. Start background location tracking using CLLocationUpdate.liveUpdates() together with CLBackgroundActivitySession. Move the app to the background. The blue location indicator appears in the Dynamic Island. While tracking is still active, install version 2 over the existing app. Open the updated app. Stop all location tracking: Cancel the CLLocationUpdate task. Call invalidate() on the CLBackgroundActivitySession. Release all references to the session. Move the app to the background again. Expected behavior The blue background location indicator disappears after the location updates and background activity session have been stopped. Actual behavior The blue location indicator remains permanently visible in the Dynamic Island, even though: No location updates are being received. No CLBackgroundActivitySession is retained. Starting and stopping another location session does not remove it. Force-quitting and reopening the app does not remove it. Only restarting the iPhone makes the indicator disappear. The problem occurs when a new build is installed over an existing installation while a background location session is active. Starting and stopping the same session normally within one installed version works as expected. Comparison with Live Activity background location The app also has a separate location feature that uses an active Live Activity to support background location updates without creating a CLBackgroundActivitySession. Installing a new build while that feature is active does not cause the blue location indicator to become stuck. The problem has only been reproduced when a CLBackgroundActivitySession is active during the installation. This suggests that the issue is specifically related to transferring or cleaning up CLBackgroundActivitySession state across an app update, rather than to CLLocationUpdate.liveUpdates() itself. Questions Is this a known issue with CLBackgroundActivitySession or CLLocationUpdate.liveUpdates()? Is there a supported way for the newly installed app process to invalidate or clean up a background location session created by the previous app process?

I’m building an iOS app using MapKit that allows users to create and navigate trails. I need offline map functionality, I was wondering if MapKit supports that. If not I was wondering if MapBox is a viable alternative to MapKit though I would prefer using MapKit. Thanks!

After upgrading to macOS 27.0, I noticed a specific issue in Find My > People. Two people who share their location with me use iPhone 6 devices. Their locations are unavailable in Find My on my Mac running macOS 27.0. The same location-sharing relationships work correctly on my other devices: iPhone running iOS 26: locations are visible iPad running iPadOS 26: locations are visible Mac running macOS 27.0: locations are unavailable Other people using newer iPhones are displayed correctly on the same Mac. This suggests that location sharing itself and my Apple Account are working correctly. The issue appears specific to Find My > People on macOS 27 when receiving location shared from older iPhone/iOS devices. I can reproduce this independently with two different iPhone 6 users. macOS 27.0 is the public release, not a beta. I have submitted this to Apple through Feedback Assistant: FB24761605 Has anyone else seen this specifically with iPhone 6 or devices running older iOS versions after upgrading to macOS 27?

Hello, I'm Greg, the developer of EV Dashboard, an app for electric vehicle owners. I'm extending it with features that help drivers understand their efficiency, including elevation and grade along a drive. It works for most of my beta testers, but two behaviors have me stuck, and they raise the same question: both hand my app an altitude that is wrong by hundreds or thousands of meters while reporting a small, positive verticalAccuracy, so I have no field I can test to distinguish a measurement from a value that is not one. Both also reproduce in Apple's Compass app on a tester's phone, with none of my code in the path. A 35-second screen recording he sent me, at the same spot in Eagan, Minnesota, shows Compass reading 889ft (the true elevation, 271m), then 5996ft for about a second, then 889ft again, and then 0ft at the moment the "CarPlay - AirPlay Connected" banner appears. Screenshots attached. Setup in my app: one CLLocationManager per active scene, desiredAccuracy kCLLocationAccuracyBestForNavigation, standard location updates (not significant-change), authorization When In Use or Always depending on the tester. Elevation comes from CLLocation.altitude, with CMAltimeter relative altitude used to carry a known altitude between fixes. Case 1: accessory fixes under CarPlay report altitude 0.0 with a positive verticalAccuracy (FB24778173) On several vehicles, every fix whose sourceInformation.isProducedByAccessory is true arrives with altitude exactly 0.0 and a verticalAccuracy that is positive and constant for the whole session (19.0 on the cars I have traces from). In the same drives, the phone's own fixes read the true altitude, around 1,345m on one tester's route. ellipsoidalAltitude does not distinguish them either: it comes back as the geoid correction applied to the 0 (-16.5 to -17.4), so both fields agree on sea level. This is not fleet-wide, which is what makes it testable. Other vehicles deliver real altitude on accessory fixes, on the same app build, with verticalAccuracy 9.5 and values that agree with the phone within a few meters. So it appears to depend on the head unit, and an app cannot ask iOS for the phone's own fix while CarPlay is connected. The Compass recording above is the same behavior in a first-party app: 889ft before the connection, 0ft after it. Case 2: a fix with an altitude about 1,550m too high The same tester's iPhone has twice delivered fixes with altitude 1823.8 where the true elevation is about 271m, an error of roughly 1,552m, with verticalAccuracy 30.0 and horizontalAccuracy 5. These fixes report no speed and no course. The same value appeared on two separate days five days apart, at the same coordinates, identical to the tenth of a meter in both altitude (1823.8) and ellipsoidalAltitude (1796.4). Both times it was the first fix after a location manager started, with the vehicle at rest. Every other fix at that spot in his logs, 76 of them across a week, reads between 269.2m and 272.6m, most with verticalAccuracy 3.0. Compass showed 5996ft (1,827.6m) at that spot in the recording, within 4m of the value my app receives. Because the value repeats exactly across days, it does not look like a measurement. What I'm asking Are either of these known issues? My reading of the documentation is that a positive verticalAccuracy means the altitude is valid, with that value as one standard deviation. In both cases the error is 50 times the stated accuracy or more. Is there any supported way to recognize an altitude that CoreLocation did not measure? Should an accessory that supplies no altitude produce a negative verticalAccuracy, as an invalid altitude does elsewhere in CoreLocation? Is a fix with no speed and no course a reliable signal that it is not a live GNSS solution, and are cached or non-GNSS positions expected to carry an altitude at all? More generally, is there current guidance for obtaining elevation along a drive that I may have missed, particularly how CLLocation.altitude and CMAltimeter are intended to be combined, and what to expect from accessory-produced fixes under CarPlay? Happy to provide traces, the recording, or sysdiagnose for either case. Thanks, Greg

Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration iOS 27.0, iPhone 17 Pro Max. Always authorization, Precise on, Low Power off. React Native / expo-location 19.0.8. While recording a GPS trail with the app backgrounded and the screen locked, deliveries stop after roughly 2-5 minutes. The JS runtime stops executing entirely — no logging of any kind during the gap. Deliveries resume only on a significant-location-change event or when the user foregrounds the app. Gaps of 6-7 minutes are typical on a 15-minute drive. Walking does not reproduce it. A stationary phone does not reproduce it. Only driving. Configuration (expo-location calls both startUpdatingLocation and startMonitoringSignificantLocationChanges on the same manager): desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = kCLDistanceFilterNone pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation UIBackgroundModes includes "location" (verified at runtime) This matches the settings described as compliant in threads 726945 and 776698 regarding the iOS 16.4 change. Ruled out with logs: the app never stops the session; no app-side filter runs during the gaps; no crash or memory kill (same process before and after); queue length under 20 and handler time ~3 ms. Tested BestForNavigation + 5 m filter, Best + no filter, and BestForNavigation no filter — all three show gaps, the last is best but not cured. Two observations that may matter: immediately after each gap the first fixes have horizontal accuracy of 170-1950 m, consistent with a cold session start rather than a resume. And on one occasion a foreground watcher callback delivered a fix 264 seconds old on resume. Questions: Under what conditions does iOS 27 suspend an app with an active standard location session configured this way? Does calling startMonitoringSignificantLocationChanges alongside startUpdatingLocation affect suspension behaviour? Is CLBackgroundActivitySession or CLLocationUpdate.liveUpdates the supported path for sustained background recording on iOS 17+? Can an app detect that its session has been suspended, so it can report honestly to the user?

Hi all, We are testing an indoor navigation app using Nearby Interaction / FiRa DL-TDOA on iPhone. In this sysdiagnose, the anchor is successfully discovered and ranging starts, but the UWB firmware crashes almost immediately. Device / OS: iPhone: 15 iOS: 27 Key timeline (redacted): text 18:09:22.969 nearbyd #dltdoa-ble-oob,Started BLE OOB scanning for FiRa DL-TDOA service 18:09:22.970 bluetoothd Received 'start active Unspecified scan' request, UUIDs [ 0xFFF3 0xFFF4 ] on 1M PHY 18:09:24.122 nearbyd #ses-loc,Scanned OOB: Mac addr: [0x], uwb session id: [0x], details: 18:09:24.122 nearbyd #ses-loc,_buildOOBConfigFromOOBMessage for anchor mac_address: [0x], payload 18:09:24.508 nearbyd #ses-loc,Selected anchor 0x (round-robin oldest in 2min window) 18:09:24.516 nearbyd Built FiRa localization packet V2: { ... } 18:09:24.516 nearbyd Built clientStartService packet: { ... } 18:09:24.520 nearbyd [RoseScheduler] RangingDidStart 18:09:24.664 nearbyd Error state - FatalChipError. Start error handling. 18:09:24.664 nearbyd #roseprovider,Got RoseState Event: FirmwareCrash 18:09:24.665 nearbyd [RoseServiceProvider] RoseInfrastructureEvent::Error 18:09:24.667 nearbyd #ses-container,#interrupt Interrupt session with reason: 18:09:24.741 nearbyd fwStateChangeReceived: FW is in FirmwareCrashed 18:09:24.742 nearbyd crashReceived 18:09:24.742 nearbyd Firmware logs are disabled 18:09:24.742 nearbyd Crash log saving is disabled 18:09:24.742 nearbyd Core dump saving is disabled 18:09:25.926 nearbyd PRRose: Resetting chip. Previous counter: 18:09:27.681 nearbyd fwStateChangeReceived: FW is in FirmwareRunning 18:09:31.333 nearbyd #roseprovider,Got RoseState Event: Ready UWB versions from the log: text RoseUpdater Version: RoseUpdater-133~26833 host interface version 0x223 (2.35) hardware version 0x6 UWB_AP version 0x8d UWB_DSP version 0x47 modem init version 0x563cfdf1 board ID 0x8 Important: this is not the earlier BLE OOB fragmentation issue. In this log, OOB scanning, OOB parsing, anchor selection, and ranging start all succeed. The failure occurs right after RangingDidStart, with FatalChipError / FirmwareCrash. We also see this secondary error, but it does not seem to be the main cause: text nearbyd SpatialPlaceLookup ticket submission failed. Too many parameters: 1 max allowed: 0 Questions: Has anyone seen FatalChipError / FirmwareCrash immediately after DL-TDOA ranging starts? Could specific FiRa localization packet V2 parameters (channel, preamble, sfd_id, slot/round/block config, static_sts_iv, etc.) trigger this firmware crash? Are there any known iOS / nearbyd / UWB firmware issues or workarounds for this? Any help would be appreciated.

Hi Apple engineers, I’m unable to create a Maps ID for Apple Maps Server API because the Maps IDs option is missing from my developer account. Feedback report: FB24888337 The report includes screenshots showing the complete identifier-type list. Steps to reproduce Sign in to the Apple Developer account. Open Certificates, Identifiers & Profiles → Identifiers. Click + to register an identifier. Look for Maps IDs, as instructed in Creating a Maps identifier and a private key. The option is absent, so I cannot create a Maps ID and its associated private key. What already works Apple Maps Server API requests succeed using temporary tokens generated in the developer portal. However, these require manual replacement every seven days. The blocker is therefore obtaining credentials for the documented production authentication workflow—not implementing JWT signing or making API requests. Use case My app, Journeys, helps users physically located in mainland China search for places outside mainland China, such as attractions, restaurants, and hotels in Paris, to plan outbound travel. My developer account is registered in mainland China. I have not received confirmation that the missing option is caused by a regional restriction. Questions Is the missing Maps IDs option a portal issue, a team eligibility/permission issue, or an intended regional restriction? If my team is eligible, how can I create a Maps ID and the associated private key? If this workflow is unavailable for my account, is there an officially supported production authentication method that avoids manual token replacement every seven days? Apple Developer Support advised me to ask on the forums because they could not handle or transfer the issue. I also found this matching report, where an Apple DTS engineer requested a Feedback Assistant report and its FB number. I have filed FB24888337 accordingly. Thank you for any guidance.

Hello, I'm currently refactoring my app to use the new Core Location APIs introduced in iOS 17 (CLLocationUpdate) and iOS 18 (CLServiceSession). I'm not quite sure how best to reproduce the current flow I've in my app right now: At app launch: If location services are authorized when in use + full accuracy: get the user current location then stop. If the services are not yet determined or denied, do nothing. Later in the app, when a user taps on a button to get its current location: Not determined: prompt and get the user current location if authorised when in use with full accuracy, then stop. Denied: present an alert (open Settings). Authorised when in use Full accuracy: get the user current location then stop. Not full accuracy: present an alert (open Settings). My issue is that I can't find a way to determine the authorisation status without prompting the user. As soon as I create a CLServiceSession to inspect the diagnostics (CLServiceSession.Diagnostic), the user is prompted. So I can't use this at app launch as I want to delay the prompt until the user first interacts with the feature actually requiring location services. Do I still need to use CLLocationManager().authorizationStatus and CLLocationManager().accuracyAuthorization at app launch? Or am I missing something in the new APIs that allow me to check a session status without prompting? Thank you!

I'm building a cycling navigation app. Route calculation uses MDirections with transportType = „cycling (ioS 26). During navigation I want to render guidance on a custom, high-contrast Canvas view designed for glanceability on a handlebar-mounted phone: the route polyline drawn as a simple ribbon, plus turn instructions derived from the route steps. There is a standard Map/MKMapView elsewhere in the app for route preview and selection. The Program License Agreement (Attachment 6) says Map Data may be displayed "only on an Apple map provided through the Apple Maps Service". My questions: Does rendering the MKRoute polyline in my own view, without an underlying Apple map, comply with the Mapkit terms? Does it matter that an Apple map view is used for the preview screen, just not during turn-by-turn guidance? If drawing the polyline itself is not permitted, is displaying only derived guidance (my map-matched position, distance to next turn, instruction text/arrow from MKRoute.Step) permitted without an Apple map? I'd like to know the compliant design before building. Thank you.

Setting NSLocationDefaultAccuracyReduced = true appears to prevent CLLocationManager.requestAlwaysAuthorization() from presenting the upgrade prompt after When In Use authorization has been granted. Repro https://github.com/Wenszel/core-location-always-repro Set NSLocationDefaultAccuracyReduced = true Start from a fresh location authorization state Call requestWhenInUseAuthorization() and choose Allow While Using App Call requestAlwaysAuthorization() Expected: The Always authorization upgrade prompt is presented. Actual: No prompt is presented Without NSLocationDefaultAccuracyReduced, the upgrade prompt is presented as expected. Additional case After granting When In Use, enable Precise Location in Settings and then call requestAlwaysAuthorization(). The upgrade prompt still does not appear, suggesting the issue is tied to NSLocationDefaultAccuracyReduced rather than the current CLAccuracyAuthorization. Environment iPhone 14 Pro, iOS 26.6.1 Also reproduced on iOS 26.4 Simulator

Since iPadOS 26.5, when my application is running in background (non visible but with location fetching active in background), then my users are not able to update the application from their MDM application. The installation stays frozen, until the user manually kills my app. While in iPasOS 26.2 and older iOS, the MDM was able to terminate and update my app. My understanding: The MDM app can only terminate the non-interactive applications (maxTerminationResistance:NonInteractive). My application running in background with the location activated is seen as interactive. TestFlight and Appstore can terminate all applications (maxTerminationResistance:Absolute), so they are able to terminate and update my application. Can you confirm this has changed in the ios26 (after iPadOS26.2)? What are the recommendations to allow my users to update my app?

Hi, Our Apple Maps integration has been working normally for years, but starting today, newly created Maps tokens suddenly became unusable. Tokens created from the Apple Developer backend now return 401 Unauthorized everywhere we test them. We can reproduce this in: our own code Apple’s Try Maps Server API page MapKit JS So this does not appear to be limited to our app code. We also tested through a US network entry point to rule out a mainland China network issue, but the result was the same. At the moment, Maps tokens created in the backend seem to be unusable in all cases on our side. Has anyone else seen this today, or is there any known issue affecting Maps token creation or validation? Thanks.

I am using the code provided on the website https://developer.apple.com/maps/sample-code/embedded-map/index.html, replacing it with my own MapKit JS Token. When accessing it using a network in mainland China, a 401 error occurs with the message [Initialization failed because the authorization token is invalid]. However, it works normally when using a network in Japan. Does this service not work in mainland China?

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.

We have a micromobility / scooter sharing app. Apple apparently introduced some sort of new feature some bikesharing apps' vehicles are shown in Maps. Similar to car rental services or public transports, we now see those bikes inside our app. Which we don't like. Because they are our competitor company. We tried disabling .carRental, .parking, .publicTransport etc options for mapView's pointOfInterestFilter option. None of them worked. We had to do .excludeAll and provided a version to our client to test with this. I just don't understand how this ridesharing app information comes and how it is shown in our app. But we need to find a solution to this. This feature doesn't make any sense to our company.

Hi everyone, I am currently working on a SwiftUI / Swift client project that visualizes live, distributed infrastructure nodes across a dynamic map interface using MapKit. As the dataset scales and coordinates update dynamically, I want to ensure rendering performance stays smooth and memory overhead remains low. I would appreciate some guidance from the community on best practices for this scenario: Clustering vs. Custom Overlays: For frequently updating data points, is native annotation clustering (MKClusterAnnotation / clusteringIdentifier) the standard recommendation, or does heavy clustering introduce recalculation overhead during rapid state changes? Visible Region Filtering: What is the recommended pattern in modern MapKit (SwiftUI Map vs. MKMapViewRepresentable) for culling off-screen data points vs. letting MapKit handle view recycling? High-Frequency Updates: When coordinates or statuses update frequently (e.g., via polling or streaming data), what are the best practices to avoid unnecessary view rebuilds and maintain 60/120 FPS panning and zooming? Any architectural tips, performance benchmarks, or WWDC sessions you recommend reviewing for large-scale dynamic rendering would be greatly appreciated! Thanks in advance.