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

Environment macOS 14+ (Sonoma), Apple Silicon Background LaunchAgent installed at /Applications/.app, launched by a plist in /Library/LaunchAgents. LSUIElement = true (no Dock icon). Signed with a Developer ID Application certificate, hardened runtime, secure timestamp. Notarized. No provisioning profile embedded. Distributed outside the App Store (signed .pkg installer). Info.plist keys present in the installed bundle: NSLocationUsageDescription NSLocationWhenInUseUsageDescription NSLocationAlwaysAndWhenInUseUsageDescription Entitlements file: empty (I removed com.apple.developer.* entitlements because they require a provisioning profile that Developer ID distribution cannot ship.) What I need CoreWLAN's scanForNetworks(withSSID:) returns entries with nil ssid / nil bssid on macOS 14+ unless the process has Location authorization. I'm trying to obtain that authorization from the LaunchAgent so I can populate SSID/BSSID for a connectivity report. What I'm doing Instantiating CLLocationManager on the main thread (verified via Thread.isMainThread) from an NSApplication.shared.run() runloop. Setting a CLLocationManagerDelegate. Calling requestWhenInUseAuthorization(), requestAlwaysAuthorization(), and startUpdatingLocation(). Observed behavior No authorization prompt is ever displayed. authorizationStatus stays at .notDetermined across launches. locationManager(_:didFailWithError:) fires with kCLErrorDomain error 1 (kCLErrorDenied). System Settings → Privacy & Security → Location Services lists the app and its toggle can be flipped ON, yet the process still reads authorizationStatus == .notDetermined immediately after and on subsequent launches. locationd logs (Console) around the same time show: "#Warning #ClientResolution the passed keyPath is not registered. Resolving to #nullCKP" Things I've already tried Verified Info.plist keys are embedded in the installed bundle (defaults read /Applications/<app>/Contents/Info.plist). Verified codesign is valid and entitlements are preserved on install (codesign -d --entitlements - /Applications/<app>). tccutil reset All <bundle-id> and full reboot. Uninstall + reinstall. Toggling Location Services OFF and back ON, both globally and per-app. Ensuring all CLLocationManager interaction runs on the main thread. Verified CLLocationManager.locationServicesEnabled() returns true. Questions Is a Developer-ID-signed LaunchAgent (LSUIElement=true, no Dock icon) supposed to be able to trigger the standard Location prompt on macOS 14+, or is a foreground/UI process required to establish initial authorization? What does the locationd "keyPath is not registered / Resolving to #nullCKP" message indicate, and how do I diagnose which registration is missing? Is there an entitlement or Info.plist key I'm still missing for Developer-ID-distributed background agents to be recognized by locationd? Given that the Settings toggle appears to be ON but authorizationStatus still reports .notDetermined to the running process, is there a bundle identity / code-signing check I can run to confirm locationd is looking at the same identity Settings is showing? Any pointers appreciated - happy to share codesign output, sample entitlements plist, or the full locationd log excerpt on request.

The new Apple Maps 3D experience in iOS 27 beta has very cool 3D Gaussian Splat maps of a number of cities now. I would like to be able to include these views inside my native app using MKMapItem. Is there a way to enable this 3D view inside of these map views at the moment? Thanks!

Overview We are developing a BLE + UWB accessory. We need to initiate UWB ranging as quickly as possible after establishing a BLE connection with an iPhone. However, it consistently takes approximately 900–1000 ms from centralManager(_:didConnect:) until the notification subscription (setNotifyValue) reaches the accessory. Most of this delay does not appear to be caused by ATT throughput or accessory response times, but rather by internal iOS processing. Details (Observed Behavior and Measurements) We tested this by implementing code on the app side to delay calling discoverServices by 1 second, measuring the processing times for both scenarios (with vs. without delay). Elapsed time for each phase measured on the app side (CBPeripheralDelegate): Phase Calling discoverServices immediately after connection Delaying discoverServices by 1 second didConnect → discoverServices call 0.1 ms (1000 ms delay) discoverServices → didDiscoverServices 416 ms 26 ms didDiscoverServices → didDiscoverCharacteristics 90 ms 60 ms Key Observations: The most notable finding is that simply delaying the discoverServices call by 1 second reduces the discoverServices → didDiscoverServices duration from 416 ms to 26 ms. This suggests that iOS is performing some internal processing right after connection, during which ATT service discovery responses appear to be delayed/postponed. Pure ATT discovery (Services + Characteristics) completes in about 86 ms when delayed. The app calls setNotifyValue(true, for:) immediately without delay inside peripheral(_:didDiscoverCharacteristicsFor:error:). However, the accessory receives the CCCD write approximately 400 ms after discovery completes. (Note: This 400 ms is an estimate based on the difference with accessory-side measurements). On the accessory side, completion of the ATT MTU exchange was observed around 380 ms after connection. Hypothesis We hypothesize that during the "first ~1 second after connection," iOS is sequentially executing link-layer control procedures (e.g., Feature Exchange, Version Exchange, Data Length Update, PHY Update) as well as ATT MTU exchange. Because these procedures are processed sequentially, ATT service discovery responses may be deprioritized or queued behind them. We have isolated the issue on the accessory side: the peripheral responds immediately to all requests, confirming that accessory processing delays or ATT throughput limitations are not the cause. Questions Is taking several hundred milliseconds to ~1 second from connection establishment (didConnect) to the completion of service discovery and notification subscription expected behavior in iOS? Is our understanding correct that iOS (CoreBluetooth / Bluetooth Controller) is executing link-layer control procedures during this initial period? If not, what specifically is taking place? Are there any means to shorten this duration from the app side or via peripheral connection parameters? Given the significant difference in response time between calling discoverServices immediately vs. delaying it, is there any way to prioritize ATT traffic right after connection or accelerate these procedures? For accessories that need to begin ranging immediately after connecting, what are the recommended best practices to minimize latency before data communication can start?

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

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

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

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

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

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

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

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

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

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

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

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