Hi, I'm working on a trip detection and recording app that relies on CLLiveLocationUpdates for the location tracking. We've observed a recurring issue where trip recording eventually stops working if the app is not opened for an extended period of time (approximately 2–3 weeks). What we observe The app continues to be installed on the device. The user does not manually open the app during this period. Eventually, trip detection and recording stop. Location diagnostics indicate: Service Session Required At this point, CLLiveLocationUpdates no longer appears to deliver location events. Recovery attempts We've tried several ways to recover without launching the app: Turning Location Services off/on Rebooting the device Changing location permissions None of these restore location updates. The only reliable recovery method we've found is: Open the app manually. Leave it running for some time. Kill the app again. After doing this, location tracking resumes and works normally for 4-5 days before eventually failing again with the same "Service Session Required" diagnostic. Questions Why would a valid location setup eventually transition into a "Service Session Required" state after the app has not been launched for several weeks? Are there any documented conditions under which an existing CLServiceSession expires, becomes invalid, or requires recreation? Is there a recommended way to recover from this state programmatically without requiring the user to manually launch the app? Is this expected behavior or a potential issue with CLLiveLocationUpdates / CLServiceSession? Additional details iOS version: 26 App uses: CLLiveLocationUpdates, Beacon Ranging & Beacon Monitoring, SLC updates, Motion Activity Updates Background location enabled: Yes Authorization type: Always Device models tested: iPhone 14 Pro Max Service session creation code: private var serviceSession: CLServiceSession? serviceSession = CLServiceSession( authorization: .always, fullAccuracyPurposeKey: "Trip" ) Has anyone else encountered a similar issue after long periods where the app is not launched? Thanks.

Hey everyone, in our project, the architecture sets all location services through one CLLocationManager, configured for navigation accuracy with background updates enabled. Start/stop is condition driven, so we track location while navigating, free-driving, connected to CarPlay or to a BLE device and stop immediately (no timeout) when none of those hold and the app is backgrounded. On stop() we tear down everything, including startMonitoringSignificantLocationChanges . BLE Device connection forces full background location for as long as it's paired and requires “Always authorization”. We keep one continuously-updating CLLocationManager (navigation accuracy, no distance filter, no auto pause) alive in the background whenever we're navigating, free-driving, connected to CarPlay, or to a BLE device using a CLBackgroundActivitySession on iOS 17+. Is a single always-best-accuracy manager the right approach, or should we be downgrading accuracy / using pausesLocationUpdatesAutomatically in some states for battery or performance? Any pitfalls with CLBackgroundActivitySession lifecycle we should watch for? As I wrote above, when the BLE accessory connects we force full background location on for the entire duration it's paired, and we require “Always authorization” for the BLE link to survive backgrounding. Is keeping location running the whole time an accessory is connected the right model? Thanks for the opportunity and have a great day!

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

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)

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

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.

Hi What would be the best way to achieve clustering on MapKit within SwiftUI? We're building a decentralized commerce auction platform that is currently live in Switzerland with 3'500 live auctions that can be discovered on a map. We're now running into the issue that the map gets cluttered, when zooming out and haven't been able to find a way to cluster We moved back to UIKit, where clustering works, but UIKit has other drawdowns. So ideally there is a way to handle it within SwiftUI without having to wrap UIKit or move back entirely to UIKit. Thanks for any help or suggestions! Developer Documentation https://developer.apple.com/documentation/mapkit/mapkit-for-swiftui Julius Ilg AuctionShack

We are developing a mileage tracking application that depends on continuous background location updates on iOS. Our app has the required background modes enabled: <key>UIBackgroundModes</key> <array> <string>remote-notification</string> <string>processing</string> <string>fetch</string> <string>location</string> </array> We are observing inconsistent behavior with background location tracking in app terminated state. In some cases, after a period of time, location updates stop completely. Sometimes iOS successfully relaunches the app when movement is detected and location updates resume correctly. However, in other cases, the app is not relaunched by the system, and we stop receiving location updates entirely. We reviewed Apple’s documentation on handling background location updates: https://developer.apple.com/documentation/corelocation/handling-location-updates-in-the-background Based on our observations, we would appreciate clarification on the following points: Is this considered expected iOS behavior or a system limitation? Under what conditions does iOS decide not to relaunch a terminated app for location events? Are there recommended best practices to improve the reliability of background location relaunch behavior? Is there any logging, diagnostics, or debugging mechanism available to determine why the app was not relaunched? Apple’s documentation mentions that location updates may be queued while the app is terminated and later delivered after relaunch. However, in some scenarios we do not receive those queued updates after the app restarts. Under what conditions can queued location updates be discarded or not delivered? Additional notes: We are using standard Core Location background updates. “Always” location permission is granted. Background App Refresh is enabled. The issue is observed intermittently across multiple iOS devices.

Hello, I’m planning to use MapKit JS for a production web/mobile application and I’m trying to better understand the quota limits and pricing model. From the documentation, I understand that MapKit JS provides a free daily limit of: 250,000 map views 25,000 service calls per Apple Developer Program membership. However, I’m not clear about what exactly happens if these limits are exceeded. My questions: If my application exceeds 250,000 map views or 25,000 service calls in a day, what happens? Will the API simply start returning errors (for example HTTP 429), or will Apple automatically charge for additional usage? Is there an official pricing model for usage above the free quota, or do we need to contact Apple to request higher limits? Are these limits strict daily hard limits that should never be exceeded in production? I’m trying to design the architecture of my application and would like to understand whether we must strictly stay below these limits or whether scaling beyond them is possible. 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?

I am building a Swift Playgrounds App project on iPad running iPadOS 26.0.1 using the latest version of Swift Playgrounds. I need to access Core Location for a plant location logging app. What I have done: • Created an App project (not a Playground) in Swift Playgrounds • Enabled ‘Core Location When in Use’ in the app capabilities (accessed by tapping the app name) • Implemented a CLLocationManager with CLLocationManagerDelegate • Called manager.requestWhenInUseAuthorization() from .onAppear in a SwiftUI view • Called manager.startUpdatingLocation() immediately after The problem: The location permission prompt never appears when the app runs. The app does not appear in Settings → Privacy & Security → Location Services at all. There are no error messages or crashes — the app simply never requests location access. What I have ruled out: • The capability IS enabled in Swift Playgrounds app settings • The app runs without errors otherwise • This is an App project, not a classic Playground, so it should support capabilities Questions: 1. Is CLLocationManager with requestWhenInUseAuthorization() supported in Swift Playgrounds App projects on iPadOS 26? 2. Has the location authorization API changed in iPadOS 26 in a way that affects Swift Playgrounds? 3. Is there a working code example for Core Location in a Swift Playgrounds App project on iPadOS 26? Any guidance would be greatly appreciated.

We want to implement continuous GPS tracking in a React Native iOS app for security purposes. We need the tracing in the following case scenarios: App is Terminated App is minimised (Not killed) App is open and device is put to sleep mode #Locked App is in minimised and device is put to sleep mode #Locked (sleep mode) Currently it works in following 2 scenarios: Working when the app open in foreground Works when the app is killed (Traces in background) We would like to understand: Is continuous background location tracking during device idle allowed in iOS ? If allowed, what is the recommended approach to ensure reliable tracking? Are there any specific configurations, permissions, or limitations (battery optimization, system restrictions) we should be aware of? We are using React-Native by transistersoft with background location updates enabled and required permissions configured. This use case is specifically for user safety and security tracking. Any guidance on best practices and platform limitations would be helpful.

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.

how to keep BG running while user killed app, because admin want to tracking inside/outside of employee

Situation: We have an app that only uses location UIBackgroundModes key to restart our app on significant change events as we need it to connect with a BLE device (mounted in the car) when someone starts driving. We cannot use geofence as the car might be used by multiple people so position changes and we don't want to store locations and sent them to multiple users via our servers. So currently we use significant change and just ignore all other location data. During app review we got the following feedback: If the app does not require persistent real-time location updates, please remove the "location" setting from the UIBackgroundModes key. You may wish to use the significant-change location service or the region monitoring location service if persistent real-time location updates are not required for the app features. Question: How to use the significant-change location service without the "location" setting from the UIBackgroundModes key or is there any other way to start the app / connect with the BLE device when it is fully terminated/swiped away? Because the docs state that AuthorizationStatusAuthorizedAlways is required and without the UIBackgroundModes key location that wouldn't be triggered when app is in the background/swiped away. Reference: https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW8

Issue from App Review: My app shows a custom explanation screen before triggering the system location permission dialog. This screen explains why location access is needed. It includes: A “Continue” button → triggers the system permission dialog A “Not Now” button → dismisses the explanation and delays the permission request Apple states that: “The user should always proceed to the permission request after the message.” They are asking me to remove the exit button from the pre-permission message. My Questions Is it now against policy to include a “Not Now” option in a pre-permission explainer screen? Are we required to immediately show the system permission dialog after any pre-permission explanation? What is the recommended UX pattern if the feature depends on location but I don’t want to force the permission immediately at launch? Would it be compliant to: Remove the “Not Now” button, OR Remove the custom pre-prompt entirely and rely only on the system dialog? The feature in question requires location to function properly, but I want to implement it in a user-friendly way that respects user choice and avoids unnecessary denial rates. If anyone has recently resolved a similar 5.1.1(iv) issue, I’d really appreciate hearing how you handled it. Thank you in advance for your help!

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.

Hello, thanks for your effort! I found that when showsUserLocation is set to true (by default), the pulsing blue dot user location annotation is shown, which is cool and beautiful. However, it will automatically and periodically attempt to call the Apple Server API GET https://api.apple-mapkit.com/v1/reverseGeocode within userLocationDidChange() and updateUserLocationAnnotation() to display, I assume, the user's current address when single-tapping on the blue dot. It will significantly use the MapKit service calls quota since the user location is automatically updated. It almost runs out of quota even though the map initialization is plenty enough. Is there any way to disable the bubble behavior but preserve the user location blue dot, which is lovely and better than drawing my own user location dot? It seems I can only turn off all user location features. Many thanks!

I have a desktop application developed in SwiftUI that shows property locations on the map. That's NOT the main feature. IF you give the application permission to access your location, the blue dot will appear on the map. If you don't, the blue user dot won't appear. That's the only difference with location services. In other words, the application has no use of user's current position beyond showing it on the map. Since it's just the matter of showing or not showing the blue dot on the map, the application doesn't really need to use the location service. Anyway, the reviewer is talking about something else by rejecting the application in two aspects. Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Guideline 5.1.5 - Legal - Privacy - Location Services As I said earlier, the application only wants to show the blue dot on the map so that you can see your property locations relative to your current location. In code, it's something like the following. Map(position: $propertyViewModel.mapPosition) { ForEach(propertyViewModel.properties) { property in Annotation("", coordinate: CLLocationCoordinate2D(latitude: property.lat, longitude: property.lon)) { ... } } UserAnnotation() } So I'm hit with two rejection reasons with this one line. UserAnnotation() And the reviewer is talking about something like the app is not functional when Location Services are disabled. To resolve this issue, please revise the app so that the app is fully functional without requiring the user to enable Location Services. Well, I can remove the UserAnnotation() line if I want to put this application through the review process. Nothing will become dysfunctional, though, if you decide to reject permission request. So would you remove it or would you play along with this reviewer if you were me? It's been three or four days since rejection. As you can imagine, the reviewer doesn't bother to answer as to What are the exact coordinates that the application has allegedly collected What won't work as a result of location permission request refusal. This isn't the first time I get my app rejected. I've probably had 150 to 200 of them rejected in the past 15 years. And just because a reviewer rejects your app for a bizarre reason, would you give in? Remove this feature and that feature because the reviewer is incompetent such that he or she makes his or her decision based on imagination? What do you think?