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.

Hi, I have develop the application in the react native. Now this application is related to truck drivers. So we have added load and when they accept the load then we fetch the location to firebase. Now issue is its not working when app close (background) on physical device. We tried on simulator and its working perfectly in the background. But when i make the build and test on physical device its not working for background task.

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

First of all : Thanks for the great presentation (wwdc2023-10180), Siraj ! This new, simple API looks like what we've been looking for for easy manageable background location updates with 'automatic battery drain minimization' :-) There were two questions that came to my mind. As far as I understood, the CLLocationUpdate.LiveConfiguration is used to help the location services to improve the location fixes. Are there other options planned to specify the granularity of delivered locations e.g., how accurate the locations need to be (as the desiredAccuracy and distanceFilter settings for the olden CLLocationManager)? Does the Implementation switch between significant location changes and regular, more expensive ways (like GPS hardware) or just deliver the most feasible accuracy available at the time of notification? I'm just curious - if I get the most feasible granularity, everything is fine for me anyway :-) Thanks again, Michael

Hi, I'm building an aftermarket solution to enable Apple Maps to support EV routing for any EV. I am going through the documentation and found some gaps - does anyone know how the following properties work? INGetCarPowerLevelStatusIntentResponse - consumptionFormulaArguments INGetCarPowerLevelStatusIntentResponse - chargingFormulaArguments Is there a working example that anyone has seen? Many thanks

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'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:

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.

Issue Summary After calling startRangingBeacons, the didRangeBeacons delegate method does not receive iBeacon scan data when the device display is turned off in the background. Expected Behavior On iOS 17.2.1 (iPhone 14), beacon ranging continues in the background even when the display is turned off. The same behavior is expected on iOS 18, but it is not working as intended. Observed Behavior On iOS 18, once the display turns off, beacon ranging stops, and the didRangeBeacons method is not triggered until the display is turned back on. • Location permission is set to “Always Allow.” • Background Modes are correctly configured (Location Updates enabled). Steps to Reproduce Ensure location permission is set to Always Allow. Enable Background Modes → Location Updates in Xcode settings. Call startRangingBeacons(in:) in the app. Put the app in the background and turn off the display. Observe that didRangeBeacons is not triggered while the display is off. Additional Notes • The issue does not occur on iOS 17.2.1 (iPhone 14), where beacon ranging continues even with the display off. • This behavior change is observed on iOS 18 across multiple devices. Could you confirm if this is an intended change in behavior or a bug? If this is expected behavior, what alternative approach is recommended to maintain continuous beacon ranging when the display is off in the background?

I am working on a duress app and would like to improve location accuracy by encouraging users to enable Wi-Fi. In Apple Maps, I noticed that when Wi-Fi is off, a dialog prompts users to turn on Wi-Fi to enhance location accuracy. I am looking to implement similar functionality in my app. Specifically, I would like to check whether Wi-Fi is enabled on the user's device (even if it is not connected to a network). Despite exploring several methods, I have been unable to determine a reliable way to check the Wi-Fi status. Can you guide me on whether it is possible to access this functionality in iOS, and if so, how I can implement it within my app?

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!

I want to use MapKit with App Intents, but the map does not show up.(See attached image) Can anyone help me solve this? import SwiftUI import MapKit struct ContentView: View {   @State private var region = MKCoordinateRegion(     center: CLLocationCoordinate2D(latitude: 37.334_900,                     longitude: -122.009_020),     latitudinalMeters: 750,     longitudinalMeters: 750   )       var body: some View {     VStack {       Map(coordinateRegion: $region).frame(width:300, height:300)         .disabled(true)     }   } } struct ContentView_Previews: PreviewProvider {   static var previews: some View {     ContentView()   } } import AppIntents import SwiftUI import MapKit struct test20220727bAppIntentsExtension: AppIntent {   static var title: LocalizedStringResource = "test20220727bAppIntentsExtension"       func perform() async throws -> some IntentResult {     return .result(value: "aaa", view: ContentView())   } } struct testShortcuts:AppShortcutsProvider{   @available(iOS 16.0, *)   static var appShortcuts: [AppShortcut]{     AppShortcut(       intent: test20220727bAppIntentsExtension(),       phrases: ["test20220727bAppIntentsExtension" ]     )   } }

Hello (: I have a question regarding the current pricing model for Apple Maps APIs, specifically MapKitJS, the Maps Snapshot API, and the Maps Server API. Previously, the documentation and my understanding indicated that the usage limits were defined per day — for example, 250,000 map loads per day for MapKitJS and 25,000 snapshots per day. However, in the Apple Developer Dashboard, I’m now seeing these limits shown on a per-month basis, such as only 25,000 snapshots per-month. This appears to contradict the publicly available information on the official website, which still states daily limits. Has the pricing model officially changed, or is this just a display issue in the dashboard? I need to know this because we're going into release soon, and then we might have thousands of users.

Hello (: I’m working with MapKitJS and would like to render polylines that follow roads — similar to the behavior seen on maps.apple.com. While I can align polylines to roads manually, I haven’t found a way to render them below street names and road shields. Currently, all polylines appear above labels, which reduces readability when displaying routes in urban areas. On maps.apple.com, polylines are rendered under street labels, which provides a much cleaner appearance. Is there a way to achieve this layering behavior in MapKitJS? If not, are there plans to support this kind of layer control in the future? Thanks in advance! MapKitJS (5.45.0): maps.apple.com:

I have the CarPlay Entitlement "Driving Task" and two of my apps use it. Now, in both apps, I have implemented Navigation. I requested the Navigation CarPlay Entitlement when the feature was mature and builds were available in Test Flight, since I wanted to release the new versions of the apps with navigation available both on the iPhone and in CarPlay. I got no answer to my request, so I decided to release the apps with only navigation in the iPhone and the Driving Task functionality in CarPlay, thinking that maybe being live with navigation in the App Store was a requirement. I have asked permission again, and so far, the request is being ignored again. What are the requirements to get the Navigation CarPlay Entitlement? If the app is approved for navigation, is there something else the app must do to get the entitlement? Requirements for CarPlay Entitlements seem quite obscure, are they listed anywhere? Is there a technical problem to move from an existing CarPlay Entitlement to another? Can that be the reason the entitlement has not been granted? Some of my competitors have the CarPlay Navigation entitlement. My use case is the same (in a better app in my opinion, of course). But I am only getting bad reviews because "the app does not include the map in CarPlay" after the big investment in implementing navigation in the apps. Any help or insight would be appreciated.

Hello, I'm encountering a runtime crash when building my visionOS app with Xcode 16.3 for visionOS 2.5. Our existing AppStore/Testflight app is also instantly crashing on visionOS 2.5 when opened but works fine on e.g visionOS 2.4. The app builds successfully but crashes on launch with this symbol lookup error (slightly adjusted because the forum complained regarding sensitive data): Symbol not found: _$sSo22CLLocationCoordinate2DVSE12CoreLocationMc Referenced from: <XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX> /private/var/containers/Bundle/Application/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/MyApp.app/MyApp.debug.dylib Expected in: <XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX> /usr/lib/swift/libswiftCoreLocation.dylib dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/System/Library/PrivateFrameworks/GPUToolsCapture.framework/GPUToolsCapture:/usr/lib/libViewDebuggerSupport.dylib I've already implemented my own Codable conformance for CLLocationCoordinate2D: extension CLLocationCoordinate2D: Codable { // implementation details... } This worked fine on previous visionOS/Xcode versions. Has anyone encountered this issue or found a solution? System details: macOS version: 15.3.2 Xcode version: 16.3 visionOS target: 2.5 Thank you!

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?

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.