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?

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?

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.

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 use MapKit and MKDirections for driving directions. The error "Directions Not Available" appears when the two points (A and B) are outside mainland China (e.g. Tokyo → Osaka). For routes inside China (e.g. Shanghai → Beijing), the same code works. let req = MKDirections.Request() req.source = MKMapItem(placemark: MKPlacemark(coordinate: origin)) req.destination = MKMapItem(placemark: MKPlacemark(coordinate: destination)) req.transportType = .automobile MKDirections(request: req).calculate { response, error in // Tokyo–Osaka (outside China): "Directions Not Available" // Shanghai–Beijing (inside China): works } Questions: Is MKDirections intended to support only routes within the device’s region (e.g. China)? When A/B are abroad, is "Directions Not Available" expected? Is this documented? For cross-country or overseas routes (e.g. Tokyo–Osaka), what is the recommended approach—third-party routing API + drawing on MapKit? Thanks.

We are currently building a kiosk system that displays an indoor map built using the Apple Maps Toolkit and have encountered a challenge regarding the required link to the Apple legal information page. In a standard web application this is straightforward, but in our kiosk environment following the link opens a new webpage and effectively takes users out of the map application, which disrupts the kiosk experience. Our preferred approach would be to intercept the link and display the legal information in a modal window within the application. However, we've not yet found a way to make this possible. Has Apple got any recommended approach or best practice for handling the mandatory legal link in kiosk deployments? Has anyone seen other kiosk implementations address this requirement in a supported way? Thanks for the support!

Hi everyone, I'm integrating Apple Maps Server API into the backend of a production iOS application (Java / Spring Boot). Before posting, I reviewed the following Apple documentation: Apple Maps Server API Creating and using tokens with Maps Server API Integrating the Apple Maps Server API into Java Server Applications Try Maps Server API I also verified the current Developer Portal behavior and inspected the network requests made by the Try Maps Server API page. What I verified Using the current Apple Developer Portal: Certificates, Identifiers & Profiles → Services → Maps → Configure Tokens I can successfully create a Server API token. I verified the following behavior: A Server API token can be created successfully. The token only supports the None restriction type. The token expires after 7 days. The Try Maps Server API page first calls GET /v1/token using the Server API token. The /v1/token endpoint returns a short-lived Maps access token. That Maps access token is then used to call Apple Maps Server API endpoints such as /v1/place, /v1/search, and /v1/reverseGeocode. Documentation vs. Developer Portal The current Apple Maps Server API documentation describes a production authentication flow in which developers: Create a Maps Identifier Create a Maps Private Key (.p8) Generate a signed authentication JWT Exchange that JWT for a Maps access token via GET /v1/token Use the Maps access token to call Apple Maps Server API However, in my current Apple Developer account: There is no Maps IDs section under Certificates, Identifiers & Profiles → Identifiers. There is no Maps or Apple Maps Server API key available under Certificates, Identifiers & Profiles → Keys. My account information: Apple Developer Program: Active Account Type: Individual Role: Account Holder Based on these observations, I'm not sure how the authentication flow described in the documentation relates to the authentication flow currently supported by the Developer Portal. Questions What is the currently recommended production authentication flow for Apple Maps Server API? Is the Server API token created from Certificates, Identifiers & Profiles → Services → Maps → Configure Tokens intended only for development and testing, or is it also the recommended authentication mechanism for long-running production backend services? If the production authentication flow described in the documentation is still the recommended approach, how can developers create a Maps Identifier and Maps Private Key using the current Developer Portal? Any clarification from Apple or from developers who have recently deployed Apple Maps Server API in production would be greatly appreciated. Thank you!

Hello, I have a question similar to this post regarding MapKit JS quota limits. I understand that we can request rate limit increases, but it is not a guaranteed increase. My app is rapidly growing. What if Apple decides to not award the limit increase? Then, the directions service of my app will stop working, which would be catastrophic for my company. I need to know if the rate limit increases are guaranteed. I need to decide early on whether to use MapKit JS or another service on, because the more time that passes, the more entangled my code will get with MapKit JS. Can we get some more information on this?

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

I'm a user in mainland China. I use the built-in Workout app on my Apple Watch Series 11 (watchOS 27 beta 3) to record outdoor and indoor workouts, and then view the workout data in the built-in Fitness app on my iPhone Air (iOS 27 beta 3). I've noticed that the marker points on the route map are offset — they deviate from the actual location by several hundred meters, ending up in the middle of a river. Note: This looks like a GCJ-02 coordinate conversion issue. In mainland China, map providers are required to use the GCJ-02 datum, and GPS (WGS-84) coordinates must be converted before being displayed on the map. The offset pattern (several hundred meters) is consistent with WGS-84 coordinates being rendered on a GCJ-02 map without conversion, or a double conversion. I've filed this via Feedback Assistant: FB23716158. Happy to provide a sysdiagnose or sample workout data if needed

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?

We are conducting iBeacon compliance testing for our device and would like to clarify two test items from the iBeacon test specification: Regarding Tx power stability verification over time and across different battery capacities: Could you please specify the required test duration and the exact test procedure? Specifically, how long should the Tx power be monitored to verify stability within the 2dB standard deviation requirement, and what battery capacity levels (e.g., 100%, 50%, 20%, low battery threshold) should be tested? Regarding device interoperability with iOS CoreLocation APIs for beacon-based region monitoring and ranging: Could you please provide guidance on the test methodology? Specifically, what test cases, expected behaviors, and pass/fail criteria should we follow to verify correct interoperability with region monitoring (didEnter/didExit) and ranging (didRangeBeacons) APIs? Any official test guidelines or reference documents 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. 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

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?

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.

Hey everyone, in our project, the architecture sets all location services through one CLLocationManager, configured for navigation accuracy with background updates enabled. Start/stop is condition driven, so we track location while navigating, free-driving, connected to CarPlay or to a BLE device and stop immediately (no timeout) when none of those hold and the app is backgrounded. On stop() we tear down everything, including startMonitoringSignificantLocationChanges . BLE Device connection forces full background location for as long as it's paired and requires “Always authorization”. We keep one continuously-updating CLLocationManager (navigation accuracy, no distance filter, no auto pause) alive in the background whenever we're navigating, free-driving, connected to CarPlay, or to a BLE device using a CLBackgroundActivitySession on iOS 17+. Is a single always-best-accuracy manager the right approach, or should we be downgrading accuracy / using pausesLocationUpdatesAutomatically in some states for battery or performance? Any pitfalls with CLBackgroundActivitySession lifecycle we should watch for? As I wrote above, when the BLE accessory connects we force full background location on for the entire duration it's paired, and we require “Always authorization” for the BLE link to survive backgrounding. Is keeping location running the whole time an accessory is connected the right model? Thanks for the opportunity and have a great day!