Hi, I'm using the Apple Maps Server API (/v1/geocode) to retrieve geocoding results for Japanese addresses. Until recently, requests like the one below returned correct results: GET https://maps-api.apple.com/v1/geocode?q=東京都千代田区千代田1-1&lang=ja-JP Authorization: Bearer <valid JWT> But now, the response is always: { "results": [] } However, when I use the same address with lang: en-US, it returns valid coordinates: GET https://maps-api.apple.com/v1/geocode?q=1-1 Chiyoda, Chiyoda-ku, Tokyo=en-US "東京都千代田区千代田1-1" is a Japanese address, and "1-1 Chiyoda, Chiyoda-ku, Tokyo" is the same address written in English. My Questions: Has there been a recent change to the geocoding behavior for Japanese addresses when lang: ja-JP is used? Does the lang parameter affect not only the response language but also the internal parsing logic? Is this a known issue or limitation? The access token is valid and I'm getting a 200 OK response, but results is always empty with lang: ja-JP. Thanks for your help!

Hello, Is it possible to retrieve URLs (the URL associated for the specified location) for the Place object when you query the Apple Maps Server APIs? They are available when you make a MKLocalSearch.Request() directly in Swift. We have both iOS and Android apps, and it's not currently possible to get the URLs on Android. Thanks!

Hi, I have develop the application in the react native. Now this application is related to truck drivers. So we have added load and when they accept the load then we fetch the location to firebase. Now issue is its not working when app close (background) on physical device. We tried on simulator and its working perfectly in the background. But when i make the build and test on physical device its not working for background task.

Hello everyone, We've developed a safety application for schools that runs on supervised, MDM-managed iOS devices. The app requires "Location Always" to maintain a persistent background state for its core functionality. The Challenge: Our primary issue is with the periodic background location reminder prompts that iOS automatically presents to the user (e.g., "[App Name] has used your location X times in the past 3 days..."). A screenshot of the exact prompt is attached. While we educate users on the importance of selecting "Always Allow," these recurring prompts make it very easy for a student to downgrade the permission at a later date, which disables the app's safety features. This makes the solution unreliable in a school environment. Our Question: Since these are supervised devices managed by an educational institution, we are looking for a way to manage this behavior. Is there any Info.plist key, entitlement, or API available to developers to influence or suppress these recurring location reminders for our app? From an MDM perspective, is there a known payload or declarative management configuration that can prevent these specific prompts from appearing for a designated app? We understand these prompts are a key privacy feature. Our question is whether there are any provisions for managed, special-purpose environments like a school, where the app's function is considered essential and pre-approved by the device administrator (the school). We are looking for a way to provide a "set it and forget it" configuration for the school, but these reminders currently prevent that. Any architectural advice or insights would be greatly appreciated. Thank you.

Hello everyone, I'm doing some work on validating some data to do with the zpseed functionality around corelocations, i've read up on the speedaccuracy field but the wording doesn't make sense to me. It says if its a positive number it is plus or minus the value in the zspeed column so would this be for example zspeed of 35 mps with an accuracy of 3 mps would it be 32 mps 38 mps or is it a range? so would it be anywhere between 32-38 mps. Or is it just plus or minus the 3mps and if this is the case how would it be worked out if its plus or minus when all the numbers will be a positive numbers as any negative numbers are deemed inaccurate ?

I am having issues loading in a mapkit snapshot. I get an error saying that https://domain.com and they're expecting domain.com. I have no idea what could be going wrong here. I set the domains properly in the mapkit tokens. When I click on the link it opens a new tab and loads what the data properly, but somehow in the application on production this error comes up.

Hi- I've never posted on here before! But ChatGPT hasn't been helpful with this. I have a call using MKLocalSearch (i have a waddled down version below) let region = MKCoordinateRegion( center: location, // the user's location span: MKCoordinateSpan( latitudeDelta: 0.005, longitudeDelta: 0.005 ) ) let req = MKLocalPointsOfInterestRequest(coordinateRegion: region) req.pointOfInterestFilter = MKPointOfInterestFilter(including: [.nightlife]) let search = MKLocalSearch(request: req) I made the latitude and longitude the lowest they can possibly be without throwing an error. Sometimes (and unreliably) when the user's location is at say, a bar, this list will give me like 10 bars that are not even within the region, and exclude the bar that the user is actually present in. How can i make this not the case? In other words, I just want this to return what I expect: a list of POIs with the category .nightLife within the defined region. Any help would be appreciated!

The documentation for CLGeocoder states Geocoding requests are rate-limited for each app, so making too many requests in a short period of time may cause some of the requests to fail. (When the maximum rate is exceeded, the geocoder returns an error object with the CLError.Code.network error to the associated completion handler.) And it provides helpful guidance on how and when to submit geocoding requests. The documentation for MKReverseGeocodingRequest does not mention requests are rate-limited. Does this mean it is not rate-limited? If it is rate-limited, is it similar to CLGeocoder, what is its behavior? It is important to understand behavior of the API in order to understand impact on my app’s use case and how users will be affected should I change the implementation. Thanks!

I encountered a crash in iOS 17 related to CLBackgroundActivitySession, which appears to be due to misleading guidance in an Apple’s WWDC video. Crash sample code: https://github.com/steve-ham/AppleLocationCrash Simplified Reproduction Steps: 1. Open the GitHub sample app. 2. Archive and export (Distribute App -> Custom -> (Release Testing, Enterprise, or Debugging) -> Export). 3. Open the app. 4. Tap enableBackgroundLocation -> select Allow While Using App on the system popup. 5. Tap disableBackgroundLocation. 6. Go to the iOS home screen. 7. Wait for 10 seconds. 8. Reopen the app -> crash occurs. The crash happens because setting CLBackgroundActivitySession to nil does not end the session, despite Apple’s guidance suggesting it should. Below is the exact quote from WWDC 2023, which explicitly states that both calling invalidate() or letting the object get destroyed (i.e., setting to nil) would end the session: WWDC 2023 Discover Streamlined Location Updates (https://developer.apple.com/videos/play/wwdc2023/10180/) “Before starting the updates, you should instantiate a CLBackgroundActivitySession object to start a new session. Note, we are assigning the session to self.backgroundActivity, which is a property and not to a local variable. And this is important because if we used a local variable, then when it goes out of scope, the object it holds would be deallocated, invalidating the session and potentially ending your app’s access to location. Then when we want to end our session, we can do that by sending the invalidate message or by letting the object be destroyed.” I’ve submitted this to Apple for resolution but wanted to share this with the community. This misguidance has caused issues in my app’s release. If Apple could reply to confirm or provide clarification, it would be greatly appreciated. P.S. Even a minimal implementation in viewDidLoad triggers the crash: let session = CLBackgroundActivitySession() print("session (session)")

Their support email is broken and our IMDF is stuck at "Occupants Data in Review" step. Thank you

Hello Apple Developers， I encountered a 401 Unauthorized error when developing a web map. I asked the developer to check whether my key authorization is normal. This is the test website: https://pro.kyeasy.com/#/user/map Test account: +33 0625823391 Test password: jinghui111 Domain pro.kyeasy.com Token Type MapKit JS Restriction Type Domain Restricted Token eyJraWQiOiJKNzZSNkpSM0FLIiwidHlwIjoiSldUIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiIzSzQ4UEE2MjRNIiwiaWF0IjoxNzU0ODA3MTc2LCJvcmlnaW4iOiJwcm8ua3llYXN5LmNvbSJ9.ZQLVPpn2Zbm5uHhT_YaA6T2eyaYNKYL5X1Z3DIC17vo4FlOLAKJnXUdB_0zOLDufVDT-CNZWK08_5KkjI5pAKA Creation Date 08/10/25 Expiration Date None Status Active Created by Jinghui Yang info java develop team id： 3K48PA624M Key ID DNRWXXA4L2 Created by Jinghui Yang on 2025/08/10 06:08 am bunld id 3K48PA624M.maps.com.kyeasy p8 DNRWXXA4L2.p8

My app has been using MKLocalSearch.Request for keyword-based location searches, and it has worked smoothly for a long time. However, starting last Wednesday, I began receiving an error from MKLocalSearch.start: MKErrorDomain (error code 4). This issue only occurs when the network environment is based in mainland China (where the API uses the Amap data source). When the network switches to other regions and other Apple Maps data source is used, the error does not occur. Another complication is that the API doesn't always fail—certain keywords still work (for example, "Huawei"). Already filed a ticket in Feedback Assistant: https://feedbackassistant.apple.com/feedback/15544549

Issue Summary After calling startRangingBeacons, the didRangeBeacons delegate method does not receive iBeacon scan data when the device display is turned off in the background. Expected Behavior On iOS 17.2.1 (iPhone 14), beacon ranging continues in the background even when the display is turned off. The same behavior is expected on iOS 18, but it is not working as intended. Observed Behavior On iOS 18, once the display turns off, beacon ranging stops, and the didRangeBeacons method is not triggered until the display is turned back on. • Location permission is set to “Always Allow.” • Background Modes are correctly configured (Location Updates enabled). Steps to Reproduce Ensure location permission is set to Always Allow. Enable Background Modes → Location Updates in Xcode settings. Call startRangingBeacons(in:) in the app. Put the app in the background and turn off the display. Observe that didRangeBeacons is not triggered while the display is off. Additional Notes • The issue does not occur on iOS 17.2.1 (iPhone 14), where beacon ranging continues even with the display off. • This behavior change is observed on iOS 18 across multiple devices. Could you confirm if this is an intended change in behavior or a bug? If this is expected behavior, what alternative approach is recommended to maintain continuous beacon ranging when the display is off in the background?

Our IMDF indoor maps submission is stuck on "Occupants data in review" for several months and I can't ahold of that team (their email doesn't work). I've been told they have a backlog, but the other steps were pretty fast. How long is the expected completion? Thank you!

First of all : Thanks for the great presentation (wwdc2023-10180), Siraj ! This new, simple API looks like what we've been looking for for easy manageable background location updates with 'automatic battery drain minimization' :-) There were two questions that came to my mind. As far as I understood, the CLLocationUpdate.LiveConfiguration is used to help the location services to improve the location fixes. Are there other options planned to specify the granularity of delivered locations e.g., how accurate the locations need to be (as the desiredAccuracy and distanceFilter settings for the olden CLLocationManager)? Does the Implementation switch between significant location changes and regular, more expensive ways (like GPS hardware) or just deliver the most feasible accuracy available at the time of notification? I'm just curious - if I get the most feasible granularity, everything is fine for me anyway :-) Thanks again, Michael

I'm trying to scan for Beacon's in a visionos app iBeacon detection via CoreLocation (like CLBeacon or CLBeaconRegion) isn't supported on visionOS, so I went for CoreBluetooth + Manual Beacon Parsing Problem is I don't get my beacons scanned, only the other bluetooth devices central.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey:true]) what should I do?

I tried detecting fake locations using CLLocationSourceInformation.isSimulatedBySoftware, but it doesn’t work with spoofing tools like iTool AnyTo. It never gets flagged as simulated. Is this a limitation of the API, and is there any recommended way to detect virtual location tools on real devices?

Can I integrate Timer along with liveUpdates(_:) in order to manipulate the frequency. Let say for example I need the user location ever 1 min. Is it possible to do so?

The code below using LookAroundPreview works fine on iOS (showing the preview image with a button saying "Look Around" at the top to enter full screen with navigation), but on macOS (15.3) there is no button and no way to navigate the view. Is this a bug or is there something I need to do differently on macOS? I have also tried using AppKit with MKLookAroundViewController and I don't seem get the button to launch full screen there either. import SwiftUI import MapKit struct ContentView: View { var body: some View { LookAroundPreviewView(coordinate: CLLocationCoordinate2D(latitude: 37.33182, longitude: -122.03118)) .frame(width: 300, height: 200) } } struct LookAroundPreviewView: View { let coordinate: CLLocationCoordinate2D @State private var scene: MKLookAroundScene? @State private var errorMessage: String? var body: some View { Group { if scene != nil { LookAroundPreview(scene: $scene, allowsNavigation: true) } else if let errorMessage = errorMessage { Text("Error: \(errorMessage)") .foregroundColor(.red) } else { ProgressView("Loading Look Around Preview...") } } .task { do { let request = MKLookAroundSceneRequest(coordinate: coordinate) let fetchedScene = try await request.scene scene = fetchedScene } catch { errorMessage = error.localizedDescription print("Error loading Look Around scene: \(error)") } } } }

We have a that relies on accurate GPS location but we’ve noticed that every now and then the location ‘jumps’ a few hundred meters to a different location but reports horizonal accuracy less than 10m. we think the device is picking up a rough location from a local WiFi rather than internal gps sensors. can we a) disable WiFi location Updates? b) identify WiFi location Updates? thank You