Hello, I’m experiencing an issue with my iOS app that uses CoreBluetooth in combination with beacon monitoring. My app is designed to wake via beacon region monitoring and then start scanning for a specific BLE peripheral (with specific service UUIDs). When the device screen is bright (i.e., the device is unlocked, or locked but the screen is active/bright), everything works perfectly—the connection is established and maintained without any issues in both: foreground and background. However, when the device is left alone for a while and the lock-screen dims (sleeps), the app continues to run in the background and range the beacon (I can confirm this via realtime console logs), but the connection attempt fails. Here’s what I observe: The central manager’s delegate method didConnect is called, indicating that the peripheral was connected. Almost immediately afterward, didDisconnect is triggered with the error message: "The specified device has disconnected from us.". The interesting part is (I repeatedly see this error in the console, because the app repeatedly tries to connect to peripheral until a success), when I touch the lockscreen (not unlock, but just touch, which makes the screen to light up brighter), the connection is being established without any further issues! I have the necessary background modes enabled in the app’s capabilities (e.g., bluetooth-central, location-always-mode, etc..). My expectation was that, thanks to beacon monitoring, the app would be awakened when needed, and scanning/connection would work reliably in the background regardless of whether the device is active or dimmed. My questions are: Why might the connection fail with this error when the device is locked/dimmed? Is this behavior expected due to iOS power management policies even if the app remains active in the background? Is there a way to ensure a reliable connection in such cases? Any insights, workarounds, or suggestions would be greatly appreciated. Thank you in advance!

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 have implemented geofencing using CLMonitor. The implementation follows this general structure: private var monitorTask: Task<Void, Never>? private var backgroundSession: CLBackgroundActivitySession? func start() async { backgroundSession = CLBackgroundActivitySession() monitorTask = Task { do { let monitor = await CLMonitor("monitor") for try await event in await monitor.events { handleEvent(event: event) } } catch {} } } func addSpot() async { let monitor = await CLMonitor("monitor") let center = CLLocationCoordinate2D(latitude: 0, longitude: 0) let condition = CLMonitor.CircularGeographicCondition(center: center, radius: 100) await monitor.add(condition, identifier: "sample-1") } When the app is not task-killed, the code inside handleEvent executes as expected. However, after a user-initiated task kill, the functionality does not work properly.

I have App uploaded to app store but it was rejected 5 times because of the location and photo permission purpose string the idea of the app is to add compliment , choose the location on the map and some info and the location is not associated to user identity it just to show his place on the map if the place he want to pick is near him he can refuse location permission the map can open and pick the point he want and need permission for images to add images with compliment , I need help for location and images permission purpose string.

Does visionOS support mapkit?

I keep getting severe weather warnings in CA but I’m in NY. I have checked my locations and I have no CA weather requests selected. I clicked on the alert and it said it was from weatherkit. How do I make these CA go away for good? Thanks!

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.

My app needs to track background location for a period of several hours while the user is using it, and we want to allow the user to switch apps or lock their phone while this is happening. We don't need to track location permanently and because of this, we don't want to request the "Always allow" permission. The app requests "While in use" permission and it has the "Location updates" background mode enabled. The CLLocationManager has 'allowsBackgroundLocationUpdates' set to true, 'pausesLocationUpdatesAutomatically' false, kCLLocationAccuracyBest, kCLDistanceFilterNone, and .fitness for the activity type (we expect the user to be walking). The app also initializes a CLBackgroundActivitySession while it is tracking location and invalidates it when done. When I test this combination on my iPhone, it works fine. I get location tracking in the background for as long as I need it, regardless of what else I do with the phone. However, my customer says it doesn't work for him. He is using a Wifi-only iPad with an external GPS receiver called "BadElf GPS Pro". He says that the external GPS receiver works fine with other apps on his iPad. With my app, he gets background location tracking only for a short time, and then it stops. The app does monitor the "locationManagerDidPauseLocationUpdates" callback and posts a local notification if it gets called, but it doesn't get called. I've also confirmed with him that he is not force-quitting the app and the app is not otherwise being terminated by iOS. Is there something I'm missing?

The https certificate has expired

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!

I have a Nissan Rogue 2021 and iPhone 14 Pro Max. Carplay was working fine until I decided to update to the new beta program and now my carplay does not seem to want to operate at all. I do the fixes online suggest in rebooting both systems, forgetting entirely and reconnecting. In the process of doing so, I can get the prompts to start with "Allow while unlocked?" But once selecting that I am unable to actually use the Carplay from the phone. It doesn't even give option to switch to it when I attempt to change audio output.

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

I have a 2010 F-150 with an Alpine iLX-F509 receiver using CarPlay. Intermittently, and currently, the GPS shows me traveling in the opposite direction that I'm heading which makes the directions completely useless. Happens regardless of wired or wireless connection. Once I unplug from the USB or disconnect from Bluetooth, the map and directions in my iPhone 13 work normally. When plugging back in, even if I've removed the car from CarPlay and reinstall it, the problem comes back. This seems to be a problem with communication between my phone and my truck GPS. Is this a software problem with CarPlay or with the Alpine system? The firmware on the Alpine is current. Could this possibly be a problem with compatibility or my GPS antenna? I do not seem to be having the same issue with my wife's 2020 CR-V. All other features of CarPlay seem to be working fine. It's just the map and the GPS. Doesn't matter which map I use either (Apple, Google).

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!

Hi everyone, I’m encountering a strange issue with GPS tracking in my app, and I’m hoping for some insights. I’m developing an app that records users' GPS activities (walking, biking, etc.) with app in the foreground and/or background. Most activities are outdoors, sometimes in areas with poor GPS reception, such as mountains. To track user location, we’re using: locationManager = CLLocationManager() locationManager.distanceFilter = 3 locationManager.activityType = .fitness locationManager.pausesLocationUpdatesAutomatically = false locationManager.allowsBackgroundLocationUpdates = true The Issue In certain scenarios, the GPS behaves unexpectedly. For example (see attached image below): A user followed a normal route (brown line), then reached an intersection and turned right (blue arrow). However, the GPS continued straight for about 200 meters (brown line) before correcting itself and resuming accurate tracking. Here’s a snippet of the recorded coordinates during this misbehavior: time,latitude,longitude,elevation,verticalAccuracy,horizontalAccuracy 10:17:17,47.92408,7.10438,950.82375,4.74865,4.80005 10:17:33,47.92410,7.10435,950.14966,4.74865,4.10799 10:17:44,47.92412,7.10431,943.63913,4.74865,4.46287 10:17:53,47.92413,7.10427,939.51380,4.74865,4.60644 10:17:59,47.92415,7.10424,934.82986,4.74865,4.52599 10:18:02,47.92417,7.10420,932.53145,4.74865,4.823035 10:18:05,47.92418,7.10416,927.84917,4.748655,4.59619 10:18:09,47.92420,7.10413,924.89886,4.748655,4.50172 10:18:13,47.92422,7.10409,923.35354,4.74865,4.77356 10:18:18,47.92424,7.104055,920.16327,4.74865,4.78286 10:18:22,47.92426,7.10400,915.23174,4.74865,4.66226 10:18:28,47.92427,7.10397,906.08626,4.74865,4.97331 10:18:31,47.92429,7.10394,903.25157,4.74865,4.81649 10:18:35,47.92431,7.10390,895.27948,4.74865,5.15392 10:18:38,47.92433,7.10386,889.71076,4.74865,5.25283 10:18:42,47.92435,7.10382,881.74041,4.74865,5.49089 10:18:46,47.92437,7.103785,874.34945,4.74865,5.55564 10:18:49,47.92439,7.10374,869.63184,4.74865,5.37537 10:18:53,47.92441,7.10370,861.26690,4.74865,5.39344 10:18:57,47.92443,7.10366,854.67646,4.74865,5.30404 10:19:01,47.92445,7.10362,848.48881,4.74865,5.59742 10:19:06,47.92447,7.10359,836.48915,4.74865,5.65666 10:19:08,47.92449,7.103555,835.72566,4.74865,5.54957 10:19:10,47.92450,7.10352,834.41579,4.74865,5.63540 10:19:13,47.92452,7.10348,830.17080,4.74865,5.65795 10:19:16,47.92454,7.10344,828.17052,4.74865,5.72169 10:19:19,47.92456,7.10340,824.93658,4.74865,5.62606 10:19:24,47.92458,7.10337,818.40503,4.74865,5.23265 10:19:34,47.92460,7.103335,804.42539,4.74865,4.683855 10:19:38,47.92462,7.10329,799.51747,4.74865,4.47590 10:19:48,47.92464,7.10324,784.97044,4.74865,4.59459 10:19:50,47.92466,7.10320,782.04750,4.748655,4.71036 10:19:57,47.92468,7.10317,777.49314,4.74865,4.60504 10:20:05,47.92469,7.10313,771.30168,4.74865,4.35574 10:20:09,47.92472,7.10308,766.64446,4.74865,4.94510 10:20:13,47.92474,7.10304,757.33384,4.74865,5.39175 10:20:15,47.92476,7.10300,753.52157,4.74865,5.442045 10:20:20,47.92477,7.10297,742.66179,4.74865,5.52391 10:20:23,47.92479,7.10293,735.38369,4.74865,5.44657 10:20:25,47.92480,7.10290,732.19367,4.74865,5.519945 10:20:28,47.92482,7.10286,725.15380,4.748655,5.58173 10:20:31,47.92484,7.10282,717.08813,4.74865,5.37805 10:20:34,47.92486,7.102785,710.35208,4.74865,5.27918 10:20:37,47.92488,7.10274,706.16774,4.748655,5.53270 10:20:40,47.92490,7.10270,702.84802,4.74865,5.71088 10:20:41,47.92648,7.10356,940.27115,6.600805,10.78768 10:20:43,47.92651,7.10355,940.24665,6.61807,10.45243 At 10:17:44, the location data was correct. Shortly after, CLLocationManager started returning inaccurate coordinates. Despite the system reporting good horizontal and vertical accuracy, the altitude readings drop progressively from 940m to 702m, even though the user remained at 940m in reality. (We also recorded barometric elevation, which confirms that he stayed around 900m) Then, at 10:20:41, the GPS corrected itself. Questions Is it possible that GPS could "lock onto" the wrong path, generating valid-looking but incorrect coordinates? Can we force CLLocationManager to use GPS exclusively (disabling other sensors like Wi-Fi)? I assumed that setting activityType = .fitness would prioritize outdoor tracking, but I’m still being located indoors. Could adjusting the activityType improve this behavior? Could having multiple CLLocationManager() instances in our app cause issues? (We use one to save the GPS coordinates, but MapBox also creates a CLLocationManager with lower accuracy for its Telemetry framework, for example) Thanks in advance for any help or suggestions!

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.???

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?

This is a standalone SwiftUI app w/ watchOS 11. To make things simple, I'm using the new concurrent API, like that: for try await update in CLLocationUpdate.liveUpdates() { … } watchOS is supposed to show the auth dialog, but it doesn't show up, even though update.authorizationRequestInProgress is true. What could be the reason? (Note that I also tried with the procedural old CLLocationManager API, it doesn't work that way as well)

I am able to fetch the location in foreground and background. I need just confirmation that can we get location apps killed state. If It's possible then how can I do that.

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