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?

I'm calling .startUpdatingLocation() from the background to detect user's location but the updates stop shortly after they start. The issue seem to also be discussed here: https://developer.apple.com/forums/thread/726945 I wonder if any solution has been found? This is a critical feature for our app. I have: kCLLocationAccuracyBestForNavigation allowsBackgroundLocationUpdates = true pausesLocationUpdatesAutomatically = false Location Updates in background modes distanceFilter not set or kCLDistanceFilterNone

While updating my app for iOS 18 I have run into some major issues with how CLMonitor and visit tracking are handled in the background. I have implemented the new CLServiceSession (i think) correctly. In my @main App struct's init method I call CLServiceSession(authorization: .always) to create a session. This is done in the foreground when the app is launched and also in the background. From what i understand this is the intended way to create a session as when the app is relaunched by the system the existing session is terminated a few moments later. What im seeing in iOS 18 vs iOS 17 is drastically less location updates being delivered to the app. i see around the same significant updates being delivered (around 1 per mile - 5 miles) but the CLMonitor.CircularGeographicConditions are being triggered at about 1 per 1 to 2 minutes regardless of the radius. When a zone is left the condition is removed in the background and a new condition is created at the next place it should be tracking. For visit tracking, it only reports a visit correctly about 10% of the time. my guess is the app is getting suspended and/or terminated and the CLServiceSession isn't correctly being reinitialized (or something completely different, i'm really not sure at this point) I would love some guidance as to the correct way to handle these updates in iOS 18. It is unclear if these are intentional limitations imposed in iOS 18, incorrect implementation on my part, or a bug in the betas. Note: startUpdatingLocation is not appropriate for this app as it is way too power hungry.

I have tried to make colored annotations in mapView (shown in the commented sections) but they always appear in black. Any help would be appreciated. func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> MKAnnotationView? { let annotationView = MKAnnotationView(annotation: annotation, reuseIdentifier: "TempAnnotationView") annotationView.canShowCallout = true annotationView.rightCalloutAccessoryView = UIButton(type: .detailDisclosure) let configuration = UIImage.SymbolConfiguration(pointSize: 10, weight: .thin, scale: .default) if annotation.title == "Start" { // let config = UIImage.SymbolConfiguration.preferringMulticolor() // let image = UIImage(systemName: "flag.fill", withConfiguration: config) // // palette // let config2 = UIImage.SymbolConfiguration(paletteColors: [.systemRed, .systemGreen, .systemBlue]) // let image2 = UIImage(systemName: "person.3.sequence.fill", withConfiguration: config2) // // hierarchical symbols // let config3 = UIImage.SymbolConfiguration(hierarchicalColor: .systemIndigo) // let image3 = UIImage(systemName: "square.stack.3d.down.right.fill", withConfiguration: config3) // // color // let image4 = UIImage(systemName: "cone.fill")?.withTintColor(.systemRed, renderingMode: .alwaysTemplate) // annotationView.image = image4 annotationView.image = UIImage(systemName: "poweron", withConfiguration: configuration) } return annotationView }

We are developers of a golf app designed to assist golfers on the course. A key feature of our app is displaying a map of each hole, and we are currently transitioning to using MapKit and camera functionalities for this purpose. However, we are encountering issues with the downloading of map tiles when using the default satellite imagery. We have tried several approaches to diagnose the issue: We have tried several things to diagnose the issue: We implemented the mapViewDidFailLoadingMap delegate method. But it is inconsistent, sometimes triggering offline errors even when map tiles are cached. We implemented, the mapViewDidFinishRenderingMap method, but it always returns false when offline or you won't get the callback. Which doesn't let us know that rendering tiles has failed. We would appreciate your guidance on the following specific questions: Does MapKit provide a way to confirm if a map tile has fully loaded? Is there a method to detect if a portion of the map hasn't loaded or if a tile request has failed? Can we determine whether a map tile is cached, and if so, how long it will remain cached, similar to Cache-Control HTTP headers? Is there a way to trigger the preloading of map tiles when we know the user has a good internet connection? Please see the sample project for steps to reproduce the issue. Thank you for any assistance!

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.

Hello, I'm currently migrating my app location service to use the new CLLocationUpdate.Updates. I'm trying to understand what can fail in this AsyncSequence. Based on the previous CLError, I thought authorisation was one of them for example but it turns out that this is handled by the CLLocationUpdate where we can check different properties. So, is there a list of errors available somewhere? Thanks Axel, @alpennec

We have background location updates enabled in our app that updates the location on our servers to deliver realtime weather alerts. We see that we are receiving these location updates when the app is backgrounded by the user. However, when the user removes our app from the background using the App Switcher, we no longer see notifications happening. We have the app delegate's "didFinishLaunchingWithOptions" method setup to check for .location in the launch options, and start location tracking immediately. Is it the intention of the OS to no longer send our app background location updates if the user manually removes our app from the background?

I'm following: https://developer.apple.com/documentation/applemapsserverapi/creating-a-maps-identifier-and-a-private-key#Create-a-Maps-ID to create map id and private key. On step #4 I can't find "Maps IDs checkbox" on the web page, blow is the screen capture which contains all options I have on my page:

I am unable to do the "Test Indoor Positioning" step in the Indoor Survey map. It says "Indoor Positioning Inactive". The support email for the indoor maps team is not functional.

In reference to this webpage, I'm turning my iPad to an iBeacon device. class BeaconViewModel: NSObject, ObservableObject, CBPeripheralManagerDelegate { private var peripheralManager: CBPeripheralManager? private var beaconRegion: CLBeaconRegion? private var beaconIdentityConstraint: CLBeaconIdentityConstraint? //private var beaconCondition: CLBeaconIdentityCondition? override init() { super.init() if let uuid = UUID(uuidString: "abc") { beaconIdentityConstraint = CLBeaconIdentityConstraint(uuid: uuid, major: 123, minor: 456) beaconRegion = CLBeaconRegion(beaconIdentityConstraint: beaconIdentityConstraint!, identifier: "com.example.myDeviceRegion") peripheralManager = CBPeripheralManager(delegate: self, queue: nil, options: nil) } } func peripheralManagerDidUpdateState(_ peripheral: CBPeripheralManager) { switch peripheral.state { case .poweredOn: startAdvertise() case .poweredOff: peripheralManager?.stopAdvertising() default: break } } func startAdvertise() { guard let beaconRegion = beaconRegion else { return } let peripheralData = beaconRegion.peripheralData(withMeasuredPower: nil) peripheralManager?.startAdvertising(((peripheralData as NSDictionary) as! [String: Any])) } func stopAdvertise() { peripheralManager?.stopAdvertising() } } In Line 10, I'm using CLBeaconidentityConstraint to constrain the beacon. Xcode says that this class is deprecated and suggests that we use CLBeaconIdentityCondition. But if I try to use it, Xcode says Cannot find type 'CLBeaconIdentityCondition' in scope I've just updated Xcode to 16.4. I still get the same error. So how do we use CLBeaconIdentityCondition to constrain the beacon? My macOS version is Sequoia 15.5. Thanks.

when I using MKLocalSearch by japanese character let request = MKLocalSearch.Request() request.naturalLanguageQuery = "東京涩谷地下鉄駅" request.region = mapView.region let search = MKLocalSearch(request: request) search.start {....} ，it can not return the placemark， shows Error : The operation couldn’t be completed. (MKErrorDomain error 4.). Failed to parse font key token: hiraginosans-w6 how can I fix this problem，thankyou！ import UIKit import MapKit class ViewController: UIViewController, MKMapViewDelegate { @IBOutlet weak var resultsTableView: UITableView! var mapView: MKMapView! var searchResults = [MKMapItem]() override func viewDidLoad() { super.viewDidLoad() mapView = MKMapView(frame: CGRect(x: 0, y: 220, width: view.bounds.width, height: view.bounds.height - (tabBarController?.tabBar.frame.size.height ?? 0))) mapView.showsScale = true mapView.showsCompass = true mapView.showsScale = true mapView.showsUserLocation = true mapView.userTrackingMode = .follow mapView.delegate = self view.addSubview(mapView) let selectedCoordinate = CLLocationCoordinate2D(latitude: 35.661777, longitude: 139.704051) // some Coordinate near 東京涩谷地下鉄駅 let selectedLocation = CLLocation(latitude: selectedCoordinate.latitude, longitude: selectedCoordinate.longitude) let coordinateMKCoordinateRegion = MKCoordinateRegion(center: selectedLocation.coordinate, latitudinalMeters: 50000, longitudinalMeters:50000) mapView.setCenter( selectedLocation.coordinate, animated: true) mapView.setRegion(coordinateMKCoordinateRegion, animated: true) drawCircle(radius: 5000, center: selectedLocation.coordinate) searchForStation() } func drawCircle(radius: CLLocationDistance, center: CLLocationCoordinate2D) { let circle = MKCircle(center: center, radius: radius) mapView.addOverlay(circle) } func mapView(_ mapView: MKMapView, rendererFor overlay: MKOverlay) -> MKOverlayRenderer { if let circleOverlay = overlay as? MKCircle { let circleRenderer = MKCircleRenderer(circle: circleOverlay) circleRenderer.fillColor = nil circleRenderer.strokeColor = UIColor.blue circleRenderer.lineWidth = 2.0 return circleRenderer } return MKOverlayRenderer(overlay: overlay) } func searchForStation() { print( "searchForStation" ) let request = MKLocalSearch.Request() request.naturalLanguageQuery = "東京涩谷地下鉄駅" // request.region = mapView.region let search = MKLocalSearch(request: request) search.start { [weak self] (response, error) in guard let self = self else { return } guard let response = response, let mapItem = response.mapItems.first else { print("Error : \(error?.localizedDescription ?? "Unknown error").") return } for mapItem in response.mapItems { print( "mapItem.placemark =",mapItem.placemark) // hope to get 東京涩谷地下鉄駅placemark，the value of latitudeand longitude） } } } }

I'm building a weather map that shows the rain on the map. I'm able to retrieve PNG images that are used as tiles to put onto the map. I then reload all the tiles on the map with each timeframe (tile set for every 10 minutes). I'm able to get the map loaded up and I'm able to place the tiles and reload the data for each time slot. I preload all the PNG data needed for the tiles and store that NSData for them in memory so that they are quick for loading and showing on the map. I have timer's set to reload the overlay with the next set of tiles for each time slot. Giving the view of a moving precipitation map over time (just like you'd see on any weather map.) I have 12 time slots (timestamps) showing every 10 minutes for the past 2 hours. I have it showing each in sequence and then repeating. Over time I get a crash with this error as a Thread 1: signal SIGABRT. Failed to acquire drawable, rendering to temporary texture validateRenderPassDescriptor:782: failed assertion `RenderPass Descriptor Validation MTLRenderPassAttachmentDescriptor MTLStoreActionMultisampleResolve store action at attachment 0 requires resolve texture ' validateRenderPassDescriptor:782: failed assertion `RenderPass Descriptor Validation MTLRenderPassAttachmentDescriptor MTLStoreActionMultisampleResolve store action at attachment 0 requires resolve texture ' Through some searching I've discovered that this seems to be console output from Metal. I assume Metal is used for MapKit to render the overlay tiles? I'm using the same custom overlay where I set the timestamp on it and then tell it to reload. I also reuse the same MKOverlayRenderer as shown here... - (MKOverlayRenderer*)mapView:(MKMapView*)mapView rendererForOverlay:(id<MKOverlay>)overlay { if ([overlay isKindOfClass:[MKTileOverlay class]]) { if (!self.rainRenderer) { self.rainRenderer = [[MKTileOverlayRenderer alloc] initWithTileOverlay:overlay]; self.rainRenderer.alpha = 0.5; } return self.rainRenderer; } return nil; } And here's the function that reloads the overlay... - (void) updateRainFrame { self.currentFrameIndex = (self.currentFrameIndex + 1) % self.timestamps.count; if ((self.currentFrameIndex >= 0) && (self.timestamps.count > self.currentFrameIndex)) { NSLog (@"self.currentFrameIndex = %lu", self.currentFrameIndex); NSString *timestamp = self.timestamps[self.currentFrameIndex]; [self.overlay setTimestamp:timestamp]; [self.rainRenderer reloadData]; } } The time it takes to crash seems arbitrary. Sometimes it's very quick. Less than a minute. But usually it's several minutes. 10 or 20 minutes or more. Feels like some sort of race condition that's occurring. Perhaps ARC is not able to release the images for the tiles quick enough for each overlay reload? That's a wild guess but I think it's something more deeper in Metal as I feel I would see other errors related to memory availability. Some of my searches point to something about MSAA needing to be turned off in Metal to resolve this. However I have no idea how I would do that through MapKit. Any suggestions? Let me know if there is somehow a way to capture more from the crash to give more insight.

Does anyone know how long it usually takes for us to hear back from Apple regarding a request for Location Push Service Extension entitlement?

我目前在做一个防止设备使用的位置是虚拟的,目前通过苹果的api无法直接判断位置来源于真实或虚拟。请问我该如何去判断它呢？

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)")

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?

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!

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

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.