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!

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?

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?

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.

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.

I am testing two Core Location clients running concurrently: V1: a delegate-based CLLocationManager with activityType set to .other V2: CLLocationUpdate.liveUpdates(.otherNavigation) I expect each client’s activityType and location processing to remain isolated. However, while V1 is running, V2 sometimes reports coordinates with a southward bend that appears aligned with a nearby mapped road. This occurs when traveling off-road beside that road. As a control, two independent delegate-based CLLocationManager instances remain independent and do not produce this bend. Reproduction steps: Grant Precise Location access with When In Use authorization. Start V1 and V2 together. Travel off-road beside a mapped road. Log each update’s source, timestamp, latitude, and longitude. Environment: iPhone 17 Pro iOS 26.6.1 (23G83) Xcode 26.6 (17F113) macOS 26.6.2 Is activityType expected to remain isolated when CLLocationManager and CLLocationUpdate run concurrently? What diagnostics would Apple recommend collecting to determine whether one client is affecting the other? I can provide the focused LocationActivityTypeBugSample project, raw logs, and an annotated screenshot.

We 7develop a location-tracking backend for sailing regatta tracking (RegattaHero, GPS tracking of racing sailboats via a Flutter iOS app). We rely on CLLocationManager for continuous position updates during races that can last several hours. Problem: In light wind conditions, a sailboat can move at low but steady speed (e.g. 1-2 knots) with essentially no acceleration signature - unlike automotive or fitness activities, which involve intermittent acceleration/deceleration (starting, braking, footstrikes). We suspect Core Location's motion-based heuristics (built on accelerometer/motion coprocessor data, not solely GPS delta) interpret this near-constant, low-acceleration motion as "stationary" or low-priority, resulting in reduced update frequency or unexpected pausing of location updates. We have already set pausesLocationUpdatesAutomatically = false explicitly, which per documentation should prevent automatic pausing entirely - but we still observe degraded update behavior in these conditions. This suggests the effect is not limited to the auto-pause mechanism but also influences other parts of the positioning/update-frequency pipeline that key off activityType. We currently use activityType = .otherNavigation (the closest existing match, covering "boats" alongside cycling/trains/off-road vehicles), but this activity type appears tuned around vehicles with more typical acceleration profiles, not low-speed, low-acceleration marine drift. Steps to Reproduce: Set activityType = .otherNavigation, pausesLocationUpdatesAutomatically = false, desiredAccuracy = kCLLocationAccuracyBestForNavigation Track a device moving continuously at 1-3 knots with minimal acceleration variance (e.g. sailboat drifting/sailing in light wind, or equivalent slow, smooth continuous motion) over an extended period (30+ minutes) Compare update frequency/consistency to a scenario with typical stop-and-go motion (e.g. driving in traffic) Expected: Consistent location update delivery reflecting actual continuous movement, independent of acceleration variance, when pausesLocationUpdatesAutomatically is explicitly disabled. Actual: Update frequency/consistency appears to degrade during sustained low-acceleration, low-to-moderate-speed motion at sea, despite auto-pause being disabled. Suggestion: Either: (a) Add a dedicated CLActivityType case for marine/nautical navigation, with pause/throttling heuristics based on speed-over-ground rather than acceleration signatures, or (b) Document/expose a way to fully decouple update-frequency behavior from the motion-coprocessor-based heuristic when pausesLocationUpdatesAutomatically = false is set, so this flag reliably covers all related throttling behavior, not just the auto-pause feature itself.

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?

Now that there are 3D buildings in Apple Maps, will there be any ability to add an elevation property to markers so that we can annotate a specific floor of a building, for example?

I'm wondering if setting the correct activityType after initializing CLLocationManager will make the location results more accurate. locationManager = CLLocationManager() locationManager.distanceFilter = 20 locationManager.activityType = .fitness

Dear Apple Developer Support Team, We are experiencing a crash in our iOS application that appears to originate within Apple's MapKit/VectorKit framework. Based on the crash logs, the failure occurs during map rendering operations inside VectorKit. The crash stack contains only Apple framework calls and does not include any application business logic methods. Crash Summary: Exception Type: NSMallocException Framework: MapKit / VectorKit Crash Location: VectorKit map rendering pipeline Observed Behavior: Application crashes while rendering map-related data Our analysis indicates that the crash occurs within Apple's native map rendering engine. Since the stack trace does not contain any application-specific code, we are unable to determine whether the issue is caused by framework behavior, an OS/device-specific condition, or a framework-level defect. We would appreciate your assistance in reviewing this issue and advising whether there are any known MapKit/VectorKit issues related to this crash signature. We can provide additional crash logs, device details, and reproduction information if required. Thank you for your support. Kind Regards, Yogesh Raj Ushyaku Software Solutions LLP

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?