Hello (: I have a question regarding the current pricing model for Apple Maps APIs, specifically MapKitJS, the Maps Snapshot API, and the Maps Server API. Previously, the documentation and my understanding indicated that the usage limits were defined per day — for example, 250,000 map loads per day for MapKitJS and 25,000 snapshots per day. However, in the Apple Developer Dashboard, I’m now seeing these limits shown on a per-month basis, such as only 25,000 snapshots per-month. This appears to contradict the publicly available information on the official website, which still states daily limits. Has the pricing model officially changed, or is this just a display issue in the dashboard? I need to know this because we're going into release soon, and then we might have thousands of users.

We have a setup that's really close to the one used in the example project - Monitoring location changes with Core Location. In short, we have a flag that indicates whether or not we should start background location monitoring. If the flag is on, after the app starts, we Create a CLServiceSession with authorization: .always Create a CLBackgroundActivitySession The user can perform an action (press a button) to toggle the flag off, in which case we invalidate and dispose of the CLServiceSession and CLBackgroundActivitySession instances and cancel any liveUpdates observation. So far, so good, everything works as expected. However, we're experiencing a weird behavior on iPhones with Dynamic Island after there's an app update. When the user is on the same app version, the behavior is correct. have the flag on, background location monitoring works fine, when the app is in the the background, there's correctly a location indicator in Dynamic Island the user can go back to the app and turn the flag off (disposing of instances, cancelling location observation), and when the app is in the background, there is no location indicator in Dynamic Island The problem arises when the user updates the app open version 1.0 of the app have the flag on, background location monitoring works fine, when the app is in the the background, there's correctly a location indicator in Dynamic Island download an app update - version 2.0 the app restarts, didFinishLaunchingWithOptions gets called again and we start the background services dynamic island indicator is correctly showing a location indicator the user goes into the app, toggles the flag off - turning location observation off, we dispose of everything now, when the app is moved to the background, there's still a location indicator in the Dynamic Island, even though we're no longer observing location The indicator is hard to get rid of, there are only 2 ways we've found restart the device, or uninstall the app The question is - is this a bug in the system? Or is there anything we should be doing actively after an app update? Thank you!

Hi, Does anyone know how can a company sign up to be a publisher for guides on apple maps? Example - https://maps.apple.com/guides?publisher=17882075820533551969&_provider=9902 I'm having hard time figuring out the process.

Hi, I'm using MapKit's MKDirections.calculate, calculateETA, and reverse geocoding (via CLGeocoder.reverseGeocodeLocation) in my iOS app. I understand that there are undocumented rate limits for these services to prevent abuse, but I couldn't find official details. I would like to know: Are the rate limits applied per device, per app installation, or are they shared across all users of the same app bundle ID? Is there any guidance on how to design these features to avoid hitting rate limits in a production environment? What is the best practice if a user repeatedly triggers routing or reverse geocoding (e.g., typing or moving the map)? Any clarification or official documentation would be greatly appreciated. Thank you!

I am encountering a coordinate rendering issue using MKMapView in my iOS app. I have a GPS coordinate in WGS84 format, which corresponds to a location in Hong Kong. When my device is physically located in Hong Kong, MKMapView displays the map with the "Apple Maps" label, and the WGS84 coordinate is rendered at the correct position. However, when the device is in Mainland China, MKMapView switches to display "Amap" (Gaode Maps) branding, and the same WGS84 coordinate is rendered at an incorrect position. I understand that Amap in Mainland China uses the GCJ-02 coordinate system, while Apple Maps typically uses WGS84. This discrepancy suggests a potential coordinate system mismatch, but I cannot definitively confirm which map type (and corresponding coordinate system) MKMapView is actually using in different regions. My key questions are: How can I programmatically or visually confirm the underlying map type (Apple Maps vs. Amap) and its coordinate system within MKMapView? Is there a way to simulate the Apple Maps environment for testing when physically located in Mainland China?

Summary CLLocationSourceInformation.isSimulatedBySoftware (iOS 15+) fails to detect location spoofing when using third-party tools like LocaChange, despite Apple's documentation stating it should detect simulated locations. Environment iOS 18.0 (tested and confirmed) Physical device with Developer Mode enabled Third-party location spoofing tools (e.g., LocaChange etc.) Expected Behavior According to Apple's documentation, isSimulatedBySoftware should return true when: "if the system generated the location using on-device software simulation. " Actual Behavior Tested on iOS 18.0: When using LocaChange sourceInformation.isSimulatedBySoftware returns false This occurs even though the location is clearly being simulated. Steps to Reproduce Enable Developer Mode on iOS 18 device Connect device to Mac via USB Use LocaChange to spoof location to a different city/country In your app, request location updates and check CLLocation.sourceInformation?.isSimulatedBySoftware Observe that it returns false or sourceInformation is nil Compare with direct Xcode location simulation (Debug → Simulate Location) which correctly returns true

Hello Apple Developer Team, I’m currently using Apple MapKit JS as the main map provider for our logistics, telematics, and HR platform TADMIN, and we are extremely satisfied with its reliability, accuracy, and visual quality. We would now like to expand our Apple integration by migrating our backend reverse geolocation services to Apple as well. However, our current usage requirements significantly exceed the standard 25,000 daily service request limit. At this stage, we already need between 250,000 and 350,000 reverse geocoding requests per day, and this number will continue to grow rapidly. Our TADMIN Tracking product processes live GPS data from connected vehicle telematics boxes, and each vehicle sends an average of 1.5 pings per minute in normal mode. We currently manage around 140 vehicles and are already in discussions with new customers that will add over 1,000 additional vehicles to the platform soon. As our customer base continues to expand, we expect this growth trend to accelerate significantly over the coming months. We already make extensive use of caching to minimize redundant geolocation calls. For example, we reuse location data when vehicles remain within a defined radius. However, since trucks rarely stay stationary for long, there is still a constant flow of new coordinates that require reverse geolocation. To give you a broader picture: TADMIN is a comprehensive SaaS ecosystem for the transport and logistics industry, combining HR management, telematics and tracking, dispatching, and data analysis into one integrated platform. The Tracking module is just one part of this system and serves as the live data backbone for our dispatching, HR, and telematics analytics modules. We would therefore like to increase our quotas for: Service Requests (especially Reverse Geocoding) Snapshot Requests, which we use for our Geofence Alerts. These are sent via push notification and email, and we would love to include the snapshot images in the emails for a clear and visually rich presentation MapKit JS Views, since we also use MapKit JS heavily in our web dashboards, for example in our tracking portal Higher quotas would allow us to rely even more on Apple services, including Autocomplete and Geocoding for customer-facing address searches inside our applications. We already have three apps published on the App Store, with a fourth one scheduled for release this week, and I will soon be upgrading my Apple Developer account to an Organization Account for our company. We are currently evaluating providers for this next stage of integration, as we are preparing a new major version of our TADMIN software, which will introduce a reworked telematics backend. Our goal is to migrate to Apple’s geolocation and map services as part of this new release. Could you please advise how we can best address this use case, for example through higher quotas or an adjusted configuration? Thank you very much for your time and support. Best regards, Timo Köhler Founder & CTO, TADMIN GmbH

Since iOS 26 the delegate method locationManager(:didVisit:) is no longer invoked reliably while locationManager(:didUpdateLocations:) continues to be called regularly on the same devices. The issue appears to be directly tied to iOS version updates. Visit callbacks worked consistently under iOS 18.x but in some cases stopped being invoked immediately after updating the same device to iOS 26.0. In other cases didVisit worked on iOS 26.0 but stopped after updating to 26.0.1 and similarly from 26.0.1 to 26.1. The behaviour is inconsistent with no identifiable pattern and affects multiple recent device models. All required configuration is in place: – startMonitoringVisits() is called correctly – location permission is set to “Always”– background mode for location updates is enabled – allowsBackgroundLocationUpdates is enabled – restarting the app or the device does not fix the problem The only workaround that restores visit monitoring is deleting the app and reinstalling the same App Store version which is not a viable solution for end users. Have other developers experienced the same issue and are there any recommended best practices or technical guidelines to handle missing didVisit callbacks after updating to iOS 26?

Hi, I’m a member of the Apple Developer Program and I’m planning to use Apple Maps Server API together with MapKit JS for a production, customer-facing web service. I have reviewed the Apple Developer Program License Agreement (including Schedule 6 – Apple Maps Services) and the documentation, but I still need clarification on several points to ensure that our usage fully complies with Apple’s policies. Daily quota and additional capacity From the documentation, I understand that there is a daily limit of 250,000 map views and 25,000 service calls per Apple Developer Program membership, shared between MapKit JS and Apple Maps Server API. When the 25,000 service calls are exceeded, the API returns HTTP 429. Should this limit be considered a hard limit for production use? The wording “For additional capacity needs, contact us” is unclear. Is there any official channel or program to request a higher quota, or should we assume this is not practically available and design our system to always stay within the documented limit? Caching of geocoding / reverse-geocoding results Schedule 6 section 2.5 restricts caching, prefetching, or storing map data except when temporary and only as necessary for Apple Maps Services, and any cached data must be deleted after use. To understand what “temporary” means in practice, I would like to confirm whether the following scenarios are acceptable: (a) In-memory cache during a single page or tab session: - Store geocoding results (latitude/longitude and normalized address) only in a JavaScript in-memory structure (e.g., a Map object) during the lifetime of the browser tab. - Delete all cached results when the tab is closed or after a short TTL (for example, a few minutes). (b) sessionStorage with a short TTL: - Store geocoding results in window.sessionStorage on a per-tab basis. - Apply a short TTL (for example, a few minutes), and delete the data when the TTL expires or the tab is closed. Are both (a) and (b) considered acceptable forms of “temporary caching” under section 2.5, or should we avoid sessionStorage and limit ourselves to purely in-memory (non-persistent) caching? Use on a commercial customer-facing website Our intended use case is a public website that: Displays store locations on a map Allows users to search for nearby stores Optionally shows routing directions We do not do fleet management, asset tracking, enterprise route optimization, or insurance risk scoring. Is this type of consumer-facing store-locator use case permitted under the Apple Maps Services terms? Any clarification from the Maps or MapKit teams would be greatly appreciated. Thank you. Best regards, Naoto Omori

Hello 👋🏼, We are using MapKit JS to display maps on our application working on two domains .com and .cn. Everything is working for all ours users in the world except for users using Chinese local network. After investigation, there is an error display in the browser console: [MapKit] Initialization failed because the authorization token is invalid. As the tokens are used as they are for the rest of the world, we know that they are valid... 😕 Problem appears on all browsers: Current versions of MapKit JS mapkit-typescript @ 5.18.2 https://cdn.apple-mapkit.com/mk/5.49.x/mapkit.js Do you have any tips, suggestions to help us 🙏 ? Aurélien.

Has anyone found a thread-safe pattern that can extract results from completerDidUpdateResults(MKLocalSearchCompleter) in the MKLocalSearchCompleterDelegate ? I've downloaded the code sample from Interacting with nearby points of interest and notice the conformance throws multiple errors in Xcode 16 Beta 5 with Swift 6: extension SearchDataSource: MKLocalSearchCompleterDelegate { nonisolated func completerDidUpdateResults(_ completer: MKLocalSearchCompleter) { Task { let suggestedCompletions = completer.results await resultStreamContinuation?.yield(suggestedCompletions) } } Error: Task-isolated value of type '() async -> ()' passed as a strongly transferred parameter; later accesses could race and Error: Sending 'suggestedCompletions' risks causing data races Is there another technique I can use to share state of suggestedCompletions outside of the delegate in the code sample?

I have a test application I'm working on (so it's a fresh Xcode project under Sonoma - with older map code borrowed from another project). It is a macOS application. And in Obj-C. When the map window is opened the logs contain the following - I've been trying to hunt down and resolve. Thank you in advance for any clues/pointers. Failed to locate resource "default.csv" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite.styl" Failed to locate resource "satellite.styl" Couldn't find satellite.styl in framework, file name satellite.styl Authorization status: Authorized The application does have MapKit.framework included.

I’m facing an issue with iOS that I hope someone can help with. I developed an app a few years ago that records GPS tracks. Up until recently, everything worked fine—even when the app was running in the background, the recording continued without problems. However, since releasing an update compiled after the iOS 18 release, users have reported that background tracking no longer works. I’ve reviewed the iOS documentation but haven’t found any relevant changes or solutions. Before the newly compiled release the app was working well on iOS 18 devices as well. Some users have reported that switching to the location permission from "When Using the App" to "Always" solved the issue. This is not the case for all users. Has anyone else encountered this issue? Any recommendations or insights on how to resolve it would be greatly appreciated. Below you can see the code used for the location tracking. Before the issue happened the app was compiled with XCode 15.4. Now I am using XCode 16.2 locationManager.activityType = CLActivityType.fitness locationManager.desiredAccuracy = kCLLocationAccuracyBest locationManager.distanceFilter = 3 locationManager.allowsBackgroundLocationUpdates = true locationManager.pausesLocationUpdatesAutomatically = false if #available(iOS 11.0, *) { locationManager.showsBackgroundLocationIndicator = true } locationManager.startUpdatingLocation() if #available(iOS 17.0, *) { // Create a CLBackgroundActivitySession object backgroundActivitySession = CLBackgroundActivitySession() } Thanks in advance for your help!

Hi, Apple recently announced DL-TDoA (Downlink TDoA) support on iOS26. This API is currently marked as Beta. We are working on integrating this functionality into our app, already added the APIs and tried to configure a new DL-TDoA session using NIDLTDOAConfiguration (the only parameter it takes is networkIdentifer). The session is configured but automatically invalidated by the OS. When is DL-TDoA expected to be fully supported by phones? Can we expect a detailed documentation or specification explaining how to arrange the session with the DT-Anchors (channel, ranging duration, ...)? Do we need Bluetooth LE connection with the anchors while running DL-TDoA? We already have the 4 DT-Anchors (1 initiator and 3 responders) ready, looking forward to be able to test this new exciting feature and get DL-TDoA measurements to trilaterate the phone position within a map. Regards.

Apple recently announced DL-TDoA (Downlink TDoA) support on iOS 26, and the API is currently marked Beta. Using two iPhones (16 Pro and 13) on iOS 26.0 Beta, I’m starting a Nearby Interaction session and need to read NITLDOA parameters (address, carrier frequency offset, signal strength/RSSI), but I can’t find a supported way. I’m also seeing asymmetry: iPhone 13 reports distance+direction, while 16 Pro reports distance only. Is there a supported workflow/API to access those parameters, and any known device/OS constraints that would cause direction to be unavailable on 16 Pro?

Hello, I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150). I observed a difference between U1-based and U2-based iPhones: iPhone 12 Pro (U1 chip) NINearbyObject.direction returns valid 3D vector (x, y, z). Distance and direction both work as expected. iPhone 15 Pro and iPhone 16 Pro (U2 chip) NINearbyObject.direction is always nil. Only distance is returned (around 0.35–0.40 m in my test). Effectively behaves as "distance-only mode". Environment: Hardware: iPhone 12 Pro, iPhone 15 Pro iOS version: 18.5 Accessory: Murata UWB SR040 / SR150 App: Using NINearbyAccessoryConfiguration with BLE-based discovery Info.plist includes NSNearbyInteractionUsageDescription Camera assistance was tested both ON and OFF Expectation: I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible. Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly. Questions: Is this an intentional limitation for U2 chip + third-party accessories? Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices? Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2? Thanks in advance for any clarification.

1. The Inquiry Hello, I have been implementing a background geofencing feature and, during testing, I found a significant numerical difference in event callback frequency between the older CLCircularRegion API and the newer CLMonitor API (CLMonitor.CircularGeographicCondition), introduced in iOS 17. My testing was strictly conducted using the "Always Allow" location permission (requestAlwaysAuthorization()). I used both APIs in parallel under identical geofencing conditions and within the same implementation environment. Since a clear difference persists in the data, I suspect this may stem from structural differences in the internal mechanisms of the two APIs rather than an implementation error on my part. 2. Environment and Implementation Details (Proof of Integrity) I have ensured that my implementation adheres to Apple's guidelines and uses modern Swift concurrency features. A. Development Environment and Permissions iOS Version: iOS 18.x and later Xcode Version: Version 17A400 (Version 26.0.1) Location Authorization: Always permission obtained. Background Mode: Location updates is configured correctly in Info.plist. B. CLMonitor Initialization and Lifecycle I implemented robust lifecycle management to ensure CLMonitor is stable and persists correctly: Initialization: I performed CLLocationManager object allocation and related service setup (e.g., CLServiceSession set to always) within the call stack frame of didFinishLaunchingWithOptions. Monitor Management: I use an Actor-based Singleton pattern to guarantee that only a single CLMonitor instance is used application-wide. Event Monitoring: Following initialization, I allocated a background Task containing the for try await event in await monitor.events loop. This Task is explicitly managed to persist in the background until the application is terminated, ensuring continuous event listening. C. Registration Limit Management I manage both APIs to ensure they never exceed the recommended maximum of 20 simultaneously monitored regions/conditions. My logic removes the oldest item (LRU) when the limit is reached. The average registration counts during the test period were highly similar: Component Average Registered Count CLCircularRegion count 7.02 CLMonitor.CircularGeographicCondition count 7.04 This confirms that registration count is not the cause of the event frequency difference. 3. Data-Based Observation The test data (bubble_test_data_for_apple_forum.csv) records the event callbacks for both APIs under identical conditions: Component Total Count Percentage of All Events (%) CLCircularRegion Delegate Total Calls 617 83.56% CLMonitor Event Total Fires 122 16.44% Overall Total Count 739 100% A. Key Findings CLCircularRegion Operability: 617 calls confirm that core implementation factors (permissions, background setup, etc.) are functioning correctly. Disparity in Frequency: Despite running in parallel, the CLMonitor event count (122) is approximately 1/5th the frequency of the CLCircularRegion calls (617). Efficiency per Registration: CLCircularRegion averaged ~0.86 calls per registered item, while CLMonitor averaged only ~0.17 calls per registered item. 4. Questions for Apple Engineering Based on the robust implementation and the data presented, I request a review of the following potential differences between the APIs: Internal Mechanism Differences: Are there structural differences in how CLCircularRegion and CLMonitor.CircularGeographicCondition process and schedule geofencing event callbacks? For instance, do they differ in terms of battery optimization priority, event batching, or internal throttling mechanisms? CLMonitor Event Ratio: Is the phenomenon where CLMonitor records a significantly lower ratio of events compared to CLCircularRegion an intended behavior, or could this be indicative of a specific environmental factor that affects the newer API differently? Thank you for your time and assistance. geofence-test-data.csv

We are currently experiencing a very interesting issue when accessing the location in the background with CLLocationManager. The user has given our app the "whenInUse" permission for locations and in most cases the app provides location updates even when it's in the background. However, when we started to use other navigation apps in the foreground we saw that the func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) method was called with (kCLErrorDomain error 1.). The user hasn't changed the location permission and we saw that locations were delivered once the user opened the app again. I don't see anything in the documentation explaining this issue, but I chatted with other developers that confirm that specific behavior. Am I missing something here?

Apple Feedback Ticket: FB16804936 Background We develop a parental control application called Adora Kids (https://apps.apple.com/us/app/adora-kids/id6443787669) that requires "Location Always" permission to function properly. Our app has Screen Time authorization and provides monitoring services for parents. Issue We are experiencing a recurring problem where child users receive the system notification "Adora accessed your location in the background" every few days. This frequently results in children disabling location permissions, which prevents our app from functioning as intended. Current Approach and Limitations We have explored using Content & Privacy Restrictions for Location Services as a potential solution, but have encountered two significant limitations: These restrictions cannot be accessed programmatically via the ManagedSettings framework (unlike AppStoreSettings and other restrictions). The current implementation is "all-or-nothing" - enabling location restrictions blocks permission changes for ALL apps on the device, preventing children from granting legitimate location access to other applications. Questions Is there a way to programmatically access and manage Content & Privacy Restrictions for Location Services through the ManagedSettings framework that we might have overlooked? Are there any recommended approaches for apps with Screen Time authorization to prevent users from changing specific permissions (particularly location) while still allowing them to manage permissions for other apps? Does Apple have plans to implement app-specific permission locking for apps with Screen Time authorization in future iOS releases? Are there any alternative approaches or workarounds that other developers have successfully implemented for this use case? Any guidance from the developer community or Apple engineers would be greatly appreciated. This is a critical functionality issue affecting the reliability of our parental control service. Thank you in advance for your assistance.

We are experiencing an issue where MKMapView appears red on the app builded with Xcode 16 and executed on iOS 18 simulator. Only the ground is affected and buildings or POIs stay normal color. Xcode 16.1 beta 3 shows same result. Is there any similar case?