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?

In my app, I am using geofencing to perform an action when the user enter or leaves a specified location. The geofencing (CLMonitor) is active permanently, and should work across multiple app sessions or after the device is restarted. It should also work after the app was minimized or terminated. This worked perfectly with iOS 17 and prior, but with iOS 18, things changed. As soon as iOS 18 dropped, users were informing me that the app does no longer perform the entry/exit action reliably (without me making any changes to the app). Most of the times, events are missed entirely. Sometimes, after the user opens or resumes the app, duplicate events are delivered and/or events with the current time instead of the correct time of entry/exit. I am making sure that the app has the "Always" location permission before geofencing is enabled The gefocence radius is between 20 and 500m, but even with the max. radius specified, the geofencing is unreliable For the same user and geofence, the entry/exit event is delivered occasionally, but not always I am currently not using CLLocationManager.allowsBackgroundLocationUpdates (even though it's documented as "Apps that receive location updates when running in the background must include the UIBackgroundModes key (with the location value) in their app’s Info.plist file") because it wasn't necessary on iOS 17 and in my tests, using it didn't yield any improvements In my search for what could have caused this change, I found this WWDC video about location authorization: . It appears that with iOS 18, it is now required to have an active CLServiceSession to ensure that location updates are delivered to my app. Even though the video is long (and I've watched it multiple times), some things are still unclear. For example, the docs state: If your app actively receives and processes location updates and terminates, it should restart those APIs upon launch in order to continue receiving updates. Also, in the video it is stated that: ... So your job, ..., is to make sure that your process launch logic knows what features it has been tasked with pursuing, and re-takes session objects... But on the other hand it's also said that: you can only start holding one (a CLServiceSession) when your app is in the foreground and also ... CLMonitor.events won’t yield results when it is not in use, unless a session which was started in the foreground, .... To summarize my questions, for the geofencing to work as described above: when exactly do I need to create a CLServiceSession if the app is launched into the backgorund? Immediately in the applicationDidFinishLaunching method, even though the app is still in the background (applicationState is background)? Or later on, when the app is opened again by the user, e.g. in applicationDidBecomeActive (and applicationState is active)? do I need to specify the background mode capability as noted in the Handling location updates in the background article? do I need to create a CLBackgroundActivitySession as noted in the Handling location updates in the background article? does it matter, which of the four initializer methods I am using to create the CLServiceSession (with CLServiceSessionAuthorizationRequirementAlways)? does it matter if I specify NSLocationRequireExplicitServiceSession in the Info.plist or not when I already do ensure that the app has the "Always" location permission when the feature is being enabled Does a CLServiceSession last indefinitely and should it only be invalidated once the user disables the feature?

Hello. I’m trying to use Core Location Service on any application in Mac (Safari, Maps, Weather, Chrome with Core Location configuration, or just trigger the API with a standalone app) and it seems that all of them constantly fail to provide the geolocation of my device because of the same error (kCLErrorLocationUnknown). I'm using MacBook Pro (M3 Max) with Sonoma 14.7. I’m sure the apps have access in the settings and everything is in order except the Core Location response. I’ve tested the issue on multiple MacBooks and it reproduced 100% of the times on all of them. Did anyone encounter a similar issue?

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.

I’m building an iOS app using MapKit that allows users to create and navigate trails. I need offline map functionality, I was wondering if MapKit supports that. If not I was wondering if MapBox is a viable alternative to MapKit though I would prefer using MapKit. Thanks!

I have an App which needs to monitor one CircularGeographicCondition for a feature. No other location services are required in the moment. Im facing the problem that entry events aren't forwarded to my implementation in every case on real devices. In the simulator everything is working like a charm. Exit events seemed to be working quite reliable on real devices too. Even after resuming the app from background in case of a missed entry event does not trigger the entry event. Only restarting (which recreates the monitor) triggers an entry event. The radius of my geofence is 200 meters What I have done: a. Holding a service session session = CLServiceSession(authorization: .always) b. Creating a Task which holds the CLMonitor, adds the conditions and loops through the events. My questions are: Is this expected behavior? If yes, how can I force the CLMonitor to recalculate the state of the condition? Thank you so much for your help

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!

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?

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.

I updated my phone 14 pro to ios 18 and I faced issue with GPS. it’s show me in next Country and after minutes or hours it’s moved to the correct location how is it can fix it

Currently (at least for a few days, maybe longer), when trying to create an Apple Maps Web Snapshot according to https://developer.apple.com/documentation/snapshots/generating_a_url_and_signature_to_create_a_maps_web_snapshot with a custom image marker (passed as Base64 PNG), the Apple server responds with a 500 Internal Server Error. Using the default balloon marker works, but a custom Base64 image marker used to work in the past (and still should according to the documentation).

Hello everyone, I’m facing an issue with my iOS app where the GPS/location services icon appears in the status bar immediately when the app is launched, even though I’m not intentionally accessing location services at that point. Issue Summary: • GPS Icon Activation: When I launch my app, the GPS icon turns on. It turns off when the app is minimized or closed. • No Intentional Location Usage at Launch: I have ensured that no instances of CLLocationManager are created when the app is launched. What I’ve Tried So Far: 1. Checked Controllers and Related Classes: • Reviewed all the code for the controllers that are active at launch. • Verified that none of these controllers create instances of CLLocationManager or call location-related methods. 2. Commented Out startUpdatingLocation: • Commented out all calls to startUpdatingLocation throughout the entire project. 3. Ensured No CLLocationManager Instances at Launch: • Searched for any code that might instantiate CLLocationManager during app launch. • Confirmed that no such instances are being created. 4. Commented Out Google Maps SDK Configuration: • In AppDelegate, commented out the Google Maps SDK configuration, so it’s not initialized with the API key. • No map views (GMSMapView, MKMapView) are initialized or used when the app is launched. 5. Tested Location Permissions: • When I change the location permission for the app to “Never” in the Settings app, the GPS icon does not appear upon app launch. • This suggests that the app is accessing location services when it has permission, even though I haven’t explicitly requested it at launch. Objective: • Control GPS Activation: I want to ensure that the GPS does not turn on when the app is launched. I intend to activate location services only when needed later in the app. Request for Assistance: I’m seeking guidance on the following: 1. Debugging Techniques: • How can I trace the code that’s causing the GPS to turn on at app launch? • Are there tools or methods to identify hidden or indirect calls to location services? 2. Forcing Location Services Off at Launch: • Is there a way to programmatically prevent location services from activating during app launch? • Can I defer any implicit location service initialization until I explicitly enable it? 3. Potential Hidden Triggers: • Are there known scenarios where location services could be activated without direct use of CLLocationManager? • Could frameworks like Google Maps SDK trigger location services even if not fully initialized? 4. Additional Suggestions: • Any other insights or suggestions to prevent the GPS icon from appearing on app launch. Additional Information: • Third-Party Frameworks: • I have not removed third-party frameworks yet, as I wanted to check other possibilities first. • Open to the idea that a third-party framework might be causing this, but need guidance on how to confirm. • Code Availability: • I’m happy to provide specific code snippets if that would help diagnose the issue. Environment: • Xcode Version: Xcode 15.4, Xcode 16.0 • iOS Deployment Target: iOS 15.0 • Devices Tested: iPhone SE 2nd and 3rd gen, iPhone 15, iPhone 15 pro, iPhone 11 • Programming Language: Swift What I’m Looking For: • Assistance in tracing the cause of the GPS activation on app launch. • Suggestions on how to prevent location services from starting until explicitly needed. • Insights into any hidden triggers or indirect usages that might cause this behavior. Thank you for your time and assistance. Any help to resolve this issue would be greatly appreciated.

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, 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!

Context: Currently in iOS, both “Allow Once” and “While Using the App” location permission decisions yield .authorizedWhenInUse. This conflation prevents apps from knowing whether the user has provided a one-time allowance or a persistent in-use allowance. Problem Statement Ambiguous App Behavior: After a user selects “Allow Once,” the app remains in .authorizedWhenInUse, making it appear to the developer as if the user granted a more persistent “While Using” permission. Poor User Experience: If the user later indicates they want to upgrade to “Always,” developers must guess whether iOS will show another system prompt. This can lead to “dead” button presses or pointless transitions to Settings. Lack of Transparency: The user’s real intention—“I only trust you this one time”—gets lost in .authorizedWhenInUse with no direct or synchronous detection mechanism. Why This Wouldn’t Violate SRP The CLLocationManager’s` Single Responsibility: Manage and expose the user’s current location authorization state. Adding .authorizedOneTime or an isOneTime property fits neatly into that responsibility. It’s still describing the user’s level of trust for location usage, just with more specificity. No Overreach: This doesn’t add new logic outside location permissions—it merely refines the existing state definitions for clarity. Simplifies the Developer Flow: Instead of co-mingling “Allow Once” and “While Using,” the system returns the precise state, letting developers handle transitions more gracefully while abiding by iOS’s privacy rules. Benefits Improved UX: Developers can present more accurate prompts or guidance. If .authorizedOneTime, the app can immediately direct the user to Settings for a persistent upgrade, rather than futilely calling requestAlwaysAuthorization() again. Less Confusion: A distinctly reported “Allow Once” state eliminates guesswork, polling, or timed approaches that degrade user experience. Consistent with iOS’s Privacy Focus: Providing a read-only flag or status for “One Time” aligns with Apple’s approach to clarity around permissions, without letting apps forcibly bypass user intentions.

I'm working on an in-house iOS app designed to help users accurately track their routes during trips. Currently, I've implemented a method to track users when the app is open in the background. However, I'm facing challenges, as the tracking stops when the device is locked for more than 10 minutes. I'm looking for a solution to continuously track a user's geolocation, even if the app is closed or not in use. Specifically, I want to ensure uninterrupted tracking, especially when the device is locked. Here are some key points: Current Method: I'm currently using the Core Location method and a combination of background tasks and a repeating timer to fetch the user's location and update a log for geolocation tracking when the app is open in the background. Issues Faced: The tracking stops when the device is locked for more than 10 minutes. This limitation impacts the accuracy of the route tracking during longer trips. Objective: My goal is to achieve continuous geolocation tracking, even when the app is closed or not actively used, to provide users with a seamless and accurate record of their routes. Platform: The app is developed for iOS using the .net maui platform, and I'm seeking solutions or suggestions that are compatible with the iOS .net maui environment. If anyone has experience or insights into achieving continuous geolocation tracking on iOS, especially when the app is not in use or the device is locked, I would greatly appreciate the assistance.

Could anybody give me an example how to set the „NSLocationRequireExplicitServiceSession“ in the info.plist correctly? Thank you

I have a Map within a SwiftUI. I initialize a variable like this: var cameraPosition: MapCameraPosition = .userLocation(followsHeading: true, fallback: .automatic) and then I want to zoom map, code like this: let userRegion = MKCoordinateRegion( center: userLocation.coordinate, span: MKCoordinateSpan( latitudeDelta: 0.01, longitudeDelta: 0.01 ) ) cameraPosition = .region(userRegion) But it does't work. How can I solve this problem?

If I change MKMapView's .preferredConfiguration property from .realistic to .flat, or .mapType from .hybridFlyover to .hybrid, subsequent scrolling causes a crash: -[MTLDebugRenderCommandEncoder validateDrawIndexedPrimitives:indexCount:indexType:indexBuffer:indexBufferOffset:instanceCount:function:]:6179: failed assertion `Draw Indexed Primitives Validation indexBufferOffset(0) + (indexCount(864) * 2) must be <= [indexBuffer length] (12). For example, changing: mapView.preferredConfiguration = MKHybridMapConfiguration(elevationStyle: .realistic) to: mapView.preferredConfiguration = MKHybridMapConfiguration(elevationStyle: .flat) Then, scroll the map view, and it will crash. It is OK the other way around. Or change: self.mapView.mapType = .hybridFlyover to: self.mapView.mapType = .hybrid I've tried everything I can think of, including calling functions like these after the change: mapView.setNeedsDisplay() mapView.setRegion(self.mapView.region, animated: false) .mapType and .preferredConfiguration are settable properties, so they should be possible to change. I could create a new MKMapview, but I'd have to perfectly recreate the state which is not trivial and far from ideal. I'm just trying to work around the issue FB14553276 so my map tiles don't show tiling seems in 2D which is a new issue introduced with iOS 18. This potential workaround still shows the seems in 3D, but is better than always showing seems. Seems like whatever I do, I just can't defeat MapKit bugs and puts me in an impossible situation. :( I've submitted Feedback this issue: FB16153802 It seems like others are experiencing the issue: https://forums.developer.apple.com/forums/thread/730780