Hi Apple team and fellow developers, We previously had Location Push Service Extension enabled and working in production. After transferring the app to a new Apple Developer team, the production App ID was transferred, but the Location Push entitlement was not retained. We've also created a new App ID for development, and now need Location Push access enabled for both the transferred production ID and the new development ID. We’ve already submitted the Location Push Access form with all relevant details. Unfortunately, the App Transfer documentation didn’t make it clear that Location Push access would be lost, and now we’re blocked from making new builds — even for the existing production app. ❓ Questions: Is it possible to re-enable Location Push for a transferred App ID? What’s the expected timeline for entitlement approval? Can Apple staff confirm the request status or let us know if any further action is needed? Thanks in advance — this entitlement is critical for our app’s functionality and release pipeline. Best, Aidar

If I have, say a doctor appointment in the Calendar app, and I'm leaving to go to it, the address will appear in Apple Maps on CarPlay. Forgive if I'm getting the details wrong, but I believe if I bring up the Map, it will be available to tap on, so I can quickly go there. I think it may also show up on one on the car-play screens that shows a few different panels. The point is, I really like this feature, and want to do it in my app. In my iOS app, the user can order food from a restaurant, and pick it up. I'm not ready to make this app a "quick service" app, but I want to give the user an easy to get to her location. Since I just ordered food, this means that I'll need to leave fairly quickly to go to the location. The Calendar app is able to offer a location because of scheduling, I'd like to do the same.

I asked a question similar to this earlier, but I think this is probably the better question. I have a food-ordering app. When the user wants to pick up food, I'd like for Apple Maps to automatically display the location of the restaurant that the user is driving to. Calendar does something similar. If there is an event that is soon, the location in the calendar-event shows up in Apple Maps. I'd like to do the same thing. So, when the user makes an order, they'll need to drive to the location fairly quickly. So, I'd like to launch Apple Maps, see the location of the restaurant where I'm picking up food, and then get directions to it. Bonus points if this also works when I have CarPlay.

Hi all, We’re running into a challenge with our iOS app DriveSmarter, which uses background location updates when connected to a physical Bluetooth device (e.g., dash cam, radar detector). For battery efficiency, we disable location services in the background when no device is connected. The problem we’re now facing is: How can we programmatically re-enable location services when a Bluetooth device reconnects while the app is still in the background? From what I understand, Core Location doesn’t allow re-enabling background location updates unless the app returns to the foreground. But our core use case requires this to happen seamlessly in the background when the user starts driving and the device connects again. To clarify: We stop location updates when the device disconnects. We want to resume location updates only when the device reconnects, even if the app is still in the background. Manually bringing the app to the foreground is not a reliable or user-friendly option. So my questions: Is it possible to programmatically restart background location services upon a Bluetooth connection event while staying in the background? If not, are there any best practices or Apple-recommended alternatives to achieve a similar result? Any guidance, patterns, or creative solutions would be greatly appreciated! Thanks in advance

Our backend management system uses Google for Location, and Apple Maps is just one of the solutions in our map component. When should I convert coordinates to GCJ02? Maybe you would say that when you are in mainland China？ BUT NOT AT ALL! What if the user does not enable location permission? What if the user has not inserted a SIM card? Or not Chinese SIM card but location in China? OR the user location in China, But use VPN with en overseas IP? All solutions are not perfect, unless you open the API to developers and tell us whether Apple Maps currently uses the wgs84 coordinate system or gcj02, which is the most reliable.

Hi, I've watched the WWDC video "Discover streamlined location updates" As detailed here: https://developer.apple.com/videos/play/wwdc2023/10180/?time=364 In order for my app to receive location updates in the background, the video states that I can either use a live activity or a CLBackgroundActivitySession My app has a live activity, however the location updates stop shortly (10 seconds, this is the normal "grace period" described) after backgrounding the app, even when the live activity is visible. If I acquire a CLBackgroundActivitySession, location updates continue in the background. I have reproduced this behavior in the Simulator in a barebones app for testing and confirmed that it's not working as described. My question is: Should I hold a CLBackgroundActivitySession even when I already have a Live Activity?

Hey All! I keep receiving an email from Apple stating "You have a missing purpose string in your Info.plist" for the key "NSLocationAlwaysAndWhenInUseUsageDescription". The thing is, though, that we are setting that value within our build Info.plist. The data in that value is even reflected into the application after build, with the correct purpose string showing up when requesting location services. We currently do our builds via Azure Devops CI/CD, where we use xcodebuild for this process. The archive also generates an Info.plist without the location key, so I tried manually inserting it before deployment. Also no luck. Anyone else had this issue or know how to resolve it? Snippet to show how the location key is currently set during build: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSLocationWhenInUseUsageDescription</key> <string>Application uses location data for accurate maps display</string> </dict> </plist> Thanks!

Hello all, I'm trying to retrieve geolocation data on the web, but I'm having trouble with the altitude value, which seems to differ from what I get on Android. When using navigator.geolocation.getCurrentPosition in Safari, is the altitude value based on mean sea level, or is it ellipsoidal altitude based on the WGS84 ellipsoid? altitude (WebKit JS): https://developer.apple.com/documentation/webkitjs/coordinates/1631861-altitude altitude (Core Location): https://developer.apple.com/documentation/corelocation/cllocation/altitude ellipsoidalAltitude (Core Location): https://developer.apple.com/documentation/corelocation/cllocation/ellipsoidalaltitude If anyone has any insight into this topic I would greatly appreciate it!

Dear Apple Team, I am reaching out regarding the need for more sophisticated location verification APIs beyond basic IP lookup capabilities. As online fraud continues to evolve, IP-based geolocation has proven insufficient for many business use cases requiring accurate location verification. Would it be possible to discuss this proposal with your API development team? I believe this would be valuable for the entire iOS and macOS developer ecosystem while maintaining Apple's commitment to user privacy.

I am developing a navigation application. My goal is for this navigation app to also work in the background and provide the user with real-time directional updates. When apps request access to location services, users see a TCC (Transparency, Consent, and Control) prompt. This prompt allows the user to choose under what conditions the app can access location services (for example: “While Using the App”, “Always”, etc.). If the user selects the “While Using the App” option, can the navigation app still access location in the background and provide directional information to the user? Is something like this technically possible? Does Apple allow this behavior for navigation apps or similar use cases?

Hello, I'm working on an application that requires the use of significant location changes and visits, in addition to region monitoring and standard continuous location delivery (foreground and background). iOS 17 and iOS 18 introduced changes to how we can monitor distinct regions of interest (with CLMonitor) as well as receive location updates (with CLLocationUpdate). But I couldn't find any information regarding how to work with Significant location changes. Do we still need to create a location manager and call startMonitoringSignificantLocationChanges()? Where are the updates received in this case, in the locationManager(_:didUpdateLocations:) or in the liveUpdates async sequence? Visits. Same question here, for visit monitoring to work, do we still have to create a location manager then call startMonitoringVisits()? Where are the visits being notified? Still in locationManager(_:didVisit:) or in the liveUpdates asynchronous sequence? I just want to be sure I understand correctly how to use the updates, and if some features of Core Location still need to use a location manager and the delegate to receive the events. Maybe additional CLCondition will be added to cover both of these technologies as it seems highly related to monitoring conditions (significant location change, and visit). Thank you, Axel

Hello, I use CLGeocoder to get the CLLocationCoordinate2D and CLRegion for an address. Now that this is deprecated in OS 26, I don't see a replacement for that property on MKMapItem via MKMapItemRequest and PlaceDescriptor. I've filed FB19027378 on this issue. Basically I have some addresses that have a street address, and others that just have a city. With CLGeocoder, when geocoding just the city, the CLRegion was set such that I could show my map zoomed out just right. I'm not sure how to do that now. Thanks!

I created an app. One if its functionalities is receive Remote Notification in the background, while app is monitoring Significant Location Changes (SLC). This functionality worked fine. I was receiving these notifications correctly. Sometimes instantly, sometime with small or large delay. And then I send the app for review. It was rejected with 3 remarks: The app or metadata includes information about third-party platforms that may not be relevant for App Store users, who are focused on experiences offered by the app itself (I wrote that app communication works both for iOS and Android.) The app declares support for audio in the UIBackgroundModes key in your Info.plist but we are unable to locate any features that require persistent audio. EULA (End User License Agreement) is missing for in-app purchases. After the rejection the app is no longer receiving these notifications. They are there, since the app receives them, when I open app, or significant location change is detected. It also works, when I run the app directly from Xcode (in debug mode), not from TestFlight nor in Sandbox. It seem to me like Apple somehow spoiled my background capabilities on purpose or accidentally. Is it possible? What can I do with it? Is it the case that I should just fix the review remarks and send the app back to review, and once the app passes it, it will work again? Or should I not count on it? Any suggestions? I asked Apple using: https://developer.apple.com/contact/topic/#!/topic/select but so far no response.

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

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!

We developed an IMDF indoor map for a client (paid work) which we submitted to Apple a few months ago. Our client is wondering how many months the approval process will take. Also, we would like to get paid for the work. Any estimate from that team would be appreciated. Thank you

Pinned 2 homes address for the same contact Steps Initial check in Apple Maps No saved places or pinned addresses appear. Open Personal Contacts You have two addresses stored in your contact card: Main and Home. Pin & Edit “Main” You pinned the Main address in Maps. Refined the location on the map. Renamed it (but still saved under the type “My Home”). Open “Home” Address in Contacts Refined the location again. Changed the type to “My Home.” Attempted to rename, but no option to change the label. Final Saved Places View Shows two entries both called “Main.” Opening either of them displays the same details for the Home address. Saved Places list only shows the full address text, without the ability to rename them inside Maps. Results Both addresses appear duplicated with the same name (“Main”), even though they point to different underlying addresses. When selecting either entry, Apple Maps incorrectly shows the same Home address details. The Saved Places section does not allow renaming; it defaults to showing the full address string. Issues Identified Sync Conflict Between Contacts & Maps Apple Maps pulls labels/types from Contacts, but the edits don’t update consistently across apps. Duplicate Naming Bug Both “Main” and “Home” collapse into “Main” in Saved Places, making them indistinguishable. One-to-One Mapping Failure Regardless of which saved place you open, Maps shows the same Home entry, meaning the system isn’t correctly binding each saved place to its respective contact address. Renaming Limitation Apple Maps doesn’t allow renaming saved addresses directly — it relies on Contacts. Since Contacts only supports preset labels (Home, Work, School, etc.), custom naming is blocked.

I'm experiencing app crashes when calling the CLMonitor initialization function: let monitor = await CLMonitor("my_monitor") According to WWDC 2023: Meet Core Location Monitor, when creating a CLMonitor object with the same identifier, it should access the existing monitor without any mention of app crashes or buggy behavior. However, in my actual testing, attempting to create a CLMonitor object with the same identifier immediately causes an app crash. Here's part of the crash log: Last Exception Backtrace: 0 CoreFoundation 0x19c4ab21c __exceptionPreprocess + 164 (NSException.m:249) 1 libobjc.A.dylib 0x199945abc objc_exception_throw + 88 (objc-exception.mm:356) 2 Foundation 0x19b7a9670 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 (NSException.m:252) 3 CoreLocation 0x1aa25cbb4 +[CLMonitor _requestMonitorWithConfiguration:locationManager:completion:] + 516 (CLMonitor.mm:516) 4 libswiftCoreLocation.dylib 0x22bf6085c CLMonitor.init(_:) + 488 (CLMonitor.swift:280) 5 libswiftCoreLocation.dylib 0x22bf604b9 <deduplicated_symbol> + 1 6 MiniPlengi 0x106372ec9 closure #1 in static CLMonitor.loplatMonitor.getter + 1 (CLMonitor+Extensions.swift:31) 7 MiniPlengi 0x1062ce325 0x106290000 + 254757 8 MiniPlengi 0x1062f6a29 specialized thunk for @escaping @isolated(any) @callee_guaranteed @async () -> (@out A) + 1 (/<compiler-generated>:0) 9 MiniPlengi 0x1062ce325 0x106290000 + 254757 10 libswift_Concurrency.dylib 0x1a7f75241 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:537) Furthermore, even though I've written code to create CLMonitor objects based on a singleton structure to handle these crash cases, the app still crashes: extension CLMonitor { static var loplatMonitor: CLMonitor { get async { struct Static { static var monitor: CLMonitor? static var initializationTask: Task<CLMonitor, Never>? } // If already initialized if let monitor = Static.monitor { return monitor } // If there's an initialization task in progress, wait for its result if let task = Static.initializationTask { return await task.value } // Create new initialization task let task = Task { let monitor = await CLMonitor("my_monitor") Static.monitor = monitor Static.initializationTask = nil // Clean up task after completion return monitor } Static.initializationTask = task return await task.value } } } Is the CLMonitor API still in a stabilization phase and not recommended for production release? I would appreciate guidance on the correct usage. If these issues are expected to persist, I'm wondering if I should continue using the existing CLCircularRegion API instead. Any insights or recommendations would be greatly appreciated.

Summary While parallel testing Core Location on the new iOS 26.1 beta (23B5044i), I observed what I believe to be a regression of the issue described here: https://developer.apple.com/forums/thread/779192 Specifically, user positioning underground subway stations is noticeably inaccurate on the beta, whereas the same scenarios remain accurate on the unupgraded device below. I work with the MTA (New York City) and work with the OP of that thread. Happy to provide additional testing or details if helpful. Please let me know what else you need. Test Info Riding NYCT from Wall St to 34th St Penn Station on the 2 train carrying two iphones Recording: https://limewire.com/d/dpTWi#pDC3GRYIdE Expected: Consistent underground positioning comparable to prior releases. Actual: Degraded/inaccurate underground positioning on iOS 26.1 beta. Test Devices Left Screen: iPhone 15 Pro Max - iOS 26.1 beta (23B5044i) Right Screen: iPhone 11 - iOS 18.6.2 (22G100) Blue dots show location set by CoreLocation. Red dot on iphone 11 shows the actual location of both devices as I was able to manually place while travelling through a station. Placement through tunnels is not easy to verify and not usually indicated. Timestamps Comparison of when train was actually observed in a station vs when 26.1 and 18.6.2 CoreLocation updated to the station Fulton St 1:48 iOS 26.1 correctly updates (correctly) 2:16 iOS 18.6.2 updates (28sec late) Park Place 4:12 train arrives 4:15 iOS 18.6.2 updates to ~near Park Place 5:04 iOS 18.6.2 updates to Park Place (correctly) 6:07 iOS 26.1 update to ~near Park Place (over 2 mins late) Chambers St 6:02 train arrives / iOS 18.6.2 updates (correctly) 6:14 iOS 26.1 updates to ~near Chambers 6:18 iOS 26.1 update to Chambers (correctly) Franklin St 6:52 train arrives 6:55 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Canal St: 7:16 train arrives 7:18 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Houston St 7:54 train arrives 8:00 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Christopher St 8:37 iOS 26.1 presumably between Houston St and Christopher St 8:40 train arrives / iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update 14 St 9:22 train arrives 9:28 iOS 18.6.2 updates (correctly) 11:01 as train departs station iOS 26.1 updates (1.5 mins late)