According to the following article, the CLCircularGeographicCondition has a limit whereby only 20 conditions can be monitored by any single app. Monitoring the user’s proximity to geographic regions While I understand the rationale behind this limit, 20 conditions seems quite low for some apps. It would be good if an app could request that the user opt-in to allowing more conditions if they understand the impact this might have on the battery etc. I'm migrating an app presently to use CLCircularGeographicCondition instead of the now deprecated CLCircularRegion. It would be good if there were more guidance on how to use the new Core Location API's to monitor how many conditions are in use within an app and how they can be deactivated when no longer required, allowing the app to free up more of the 20 conditions available.

I'm wondering if setting the correct activityType after initializing CLLocationManager will make the location results more accurate. locationManager = CLLocationManager() locationManager.distanceFilter = 20 locationManager.activityType = .fitness

Does visionOS support mapkit?

When using Search.autocomplete and getting the results, each search result object has coordinate which have 13 decimal places. When you use Geocoder.reverseLookup for these coordinates, it returns the wrong address and different coordinates (6 decimal places and different as well). What works is using Geocoder.lookup (with getsUserLocation as true) and putting in the Search.autocomplete displayLines (as a string) for the query. Am I doing something wrong or is this a bug? Code: const exampleQuery = '<example address>'; const search = new mapkit.Search({ getsUserLocation: true, }); search.autocomplete( exampleQuery, (error, data) => { if (error) { console.error('Search error:', error); return; } const { coordinate } = data.results[0]; console.log("Autocomplete coordinate", coordinate); // Lat and lng are both have 13 decimal places const geoCoder = new mapkit.Geocoder({}); geoCoder.reverseLookup( new mapkit.Coordinate(coordinate.latitude, coordinate.longitude), (error, data) => { const { formattedAddress, coordinate } = data.results[0]; console.log(formattedAddress, coordinate); // Not the same address from example query and from the search autocomplete, also the coordinate has 7 decimal places } ); }, {} );

We applied for Location Push Entitlement on June. It has been several months since then but we still got not any results (either passed or rejected).

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?

I started getting a location error recently. I've never seen this error before and it began happeing randomly. Here is the breakpoint. (if let locationManager........) var currentLocation: Result<CLLocation, Error> { get { #if DEBUG return .success(CLLocation(latitude: CLLocationDegrees(exactly: 0)!, longitude: CLLocationDegrees(exactly: 0)!)) #else if let locationManager = self.locationManager { return locationManager.currentLocation } return .failure(LocationError.unknown) #endif } } I've tried everything I can think of to fix the issue. It has an issue getting the users location when logging in. I've made no changes to the code and everything has worked for years. The bug reports show nothing. I've tried re-installing Xcode, rebuilding the pods etc. I've tried everything that you would normally do in this situation.

I have an application that uses geolocation to track the user’s location and trigger actions when the app is in either the foreground or background. Currently, it seems that region entry is not triggered unless an app like Maps (which actively uses location services) is opened. The location permissions are correctly set to “Always” with precise location enabled. We are using geofencing to setup region and trigger actions when entering or leaving. Is there something I’m missing in the configuration that could be preventing region monitoring from triggering properly when the app is in use or in background?

https://developer.apple.com/documentation/applemapsserverapi/creating-and-using-tokens-with-maps-server-api This doesn't really say what to do with .p8 private key. I know I am a noob but I really don't understand Apple Doc at all. There is no example or anything like that. const appleMapKit = await fetch("https://maps-api.apple.com/v1/token", { headers: { Authorization: `Bearer ${server_api_token}`, }, }); This is what I did but because I created the token on website, server_api_token only lasts 7 days. So, I tried to use Profile - Key to replace that. I have .p8 file and how can I use this to create the token for the server api?

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 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 have seen examples of conducting an Indoor Survey of an IMDF where it has labels on the map. This would help. Our structure is basically a huge hall that gets reconfigured weekly from a horse venue to a car show to a home and garden show. I was thinking of creating a series of walkways to criss cross the floor and then survey them once done. It would be nice to have a label of the features on the map. How is this done? Thank you, Mele

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?

I'm trying to use the new Apple Maps Server API. As far as I can tell I have set up the token correctly, but my web request is still returning 401 unauthorized. The following is my code in TypeScript: import * as jwt from 'jsonwebtoken'; const JWT_SECRET = "-----BEGIN PRIVATE KEY-----\n" + "MIGTAgEAMBMGBy..............................\n" + "..............................................................\n" + "..............................................................\n" + "-----END PRIVATE KEY-----"; const header = { alg: "ES256", kid: "26DYPK65ZK", typ: "jwt" } // Example payload data const payload = { "iss": "7F3PBYWYMS", "iat": Date.now(), "exp": Date.now() + (1000 * 30 * 60), }; export async function getRestaurants() { let token = jwt.sign(payload, JWT_SECRET, { algorithm: 'ES256', header: header}); const response = await fetch('https://maps-api.apple.com/v1/token (https://maps-api.apple.com/v1/token)', { method: 'GET', headers: { 'Authorization': "Bearer " + token }, }); console.log(response); } What am I doing incorrectly here?

When trying the request "hotels" on MapKitJS with searchRegionPriority=default, it will return an hotel in Ramallah even if the searchRegion is very far from there. It can happen if your search region is very broad in most place (above Europe if you zoom out a lot, over Turkey and Middle East even if the bounding box is narrower), but on specific places it happens even with a small search region (like in Tripoli, Lebanon, whatever the zoom level). With searchRegionPriority=required, many hotels can be found in the same area. Reproduce with: https://maps-api.apple.com/v1/search?q=hotels&searchRegion=34.45512816097114,35.849070061159864,34.428418939926146,35.80795182731595&lang=en&searchRegionPriority=default

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.

We’re implementing a feature in our app that allows a certified MFi GPS device to act as the default location source for user positioning, replacing the internal GPS when connected. However, we’re noticing a significant discrepancy between the accuracy values reported by iOS and those directly available from the GPS device. Here’s the issue: When the MFi GPS is in use, it transmits standard NMEA messages (GGA, GSA, RMC, etc.) to the iOS device (providing HDOP and VDOP). However, the accuracy reported by iOS for this “location-system” seems to be less precise than what the GPS device itself reports. For example, here are the readings we observe: Location from iOS device (systemLocation): Position: <+41.4, +1.8> +/- 5.00m (speed 0.05 m/s / course 329.40) Timestamp: 6/11/24, 12:01:50 Central European Standard Time Horizontal Accuracy (from systemLocation): 5.0 meters (16 ft) Vertical Accuracy (from systemLocation): 9.5 meters (31 ft) Location from GPS device directly: Horizontal Accuracy: 9.1 ft Vertical Accuracy: 10.3 ft It’s evident that the accuracy values displayed by iOS differ from the values available from the GPS device, especially in terms of horizontal and vertical accuracy. Question: Is there a known reason for this discrepancy in accuracy values? Is there a way to obtain the GPS device’s native accuracy values in iOS, or is iOS applying additional filtering or adjustments that might explain this difference? If additional filtering is applied can be disabled? Any insights would be greatly appreciated, as accurate location reporting is critical for our app’s functionality.

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

We developed a app in which the I need the app to update the User's location even in background( even after terminating from the recent UI ), Currently I am receiving the location updates when the user has kept the app in open and if minimised, But I want that it should update the location even when it is removed from recent app (minimised UI)(after terminating the app) Is it possible to do so.???

I am working with the CLBackgroundActivitySession and CLServiceSession to figure out why our app is sometimes terminated in the background. I am unable to understand what "insufficientlyInUse" corresponds to, it could be understood as The location data is not being used enough the "While in use" permission is not enough It will be very helpful if the entire enum can be explained, I am attaching the one for CLServiceSession since it is a superset of CLBackgroundActivitySession from CoreLocation extension CLServiceSession { public struct Diagnostic { public var authorizationDenied: Bool { get } public var authorizationDeniedGlobally: Bool { get } public var authorizationRestricted: Bool { get } public var insufficientlyInUse: Bool { get } public var fullAccuracyDenied: Bool { get } public var alwaysAuthorizationDenied: Bool { get } public var serviceSessionRequired: Bool { get } public var authorizationRequestInProgress: Bool { get } } ... } Looking forward to hearing from you