Hello Apple Developer Technical Support / Core Location Team, I’m requesting clarification on the effective timing of the Info.plist key NSLocationDefaultAccuracyReduced. We shipped Version A with NSLocationDefaultAccuracyReduced = YES (reduced accuracy by default). In Version B we changed it to NO. After updating to Version B, on devices/users that have not previously granted location authorization for our app, the first authorization flow still behaves as if reduced accuracy is the default (i.e., the same behavior as Version A). Could you please confirm: When iOS evaluates/caches NSLocationDefaultAccuracyReduced (install time, app launch, or at first authorization prompt)? After an update changes this key from YES to NO, should the new value apply to users who have never authorized location for the app? Environment: Iphone 16 (IOS 26.0) I can provide a sysdiagnose and additional logs if needed. Thank you, Jack

Hi everyone, I’m running into an App Store Connect issue that seems to be a misclassification, and I’m hoping someone (or Apple staff) can help clarify or advise. App: Quick Quote Calculator Platform: iOS (built with Expo) App type: Business No navigation, routing, maps, or turn-by-turn directions When submitting a new build, App Store Connect returns: ITMS-90118: Invalid routing app setting To upload a routing app coverage file, you must define the app binary as a routing app. However: There is no “Routing & Navigation” section in App Information There is no “Routing App Coverage File” section under App Store No routing metadata or coverage file has ever been uploaded The app does not provide routing or navigation functionality It appears the binary itself is being classified as a routing app, but there is no UI in App Store Connect to view or remove this classification. What I’ve tried Verified app metadata and screenshots Confirmed no routing/navigation APIs are used Reviewed Info.plist permissions (no routing language) Uploaded a new build with incremented build number Has anyone run into a case where a routing flag is applied at the binary level and the Routing App options are not exposed in App Store Connect? Is the only resolution to have Apple manually remove the routing classification via App Review / Developer Support? Any insight from Apple staff or devs who’ve resolved this would be hugely appreciated. Thanks in advance! Yes — the app is strictly a business quote calculator for trades. It calculates distance (Miles via addresses) but does not display maps, routes, directions, or navigation of any kind.

I just spend the morning debugging LocationButton and the associated CLLocationManagerDelegate only to realise that it works perfectly in iOS 18.5 but no longer works for me in iOS 26.0, 26.2 or 26.2.1 (the latter on-device). It does work when I run my app on macOS 26.2 (Designed for iPad). Is there a change in behaviour or requirements on iOS I am missing? On iOS 18.5 I observe that the authorisation status changes from .notDetermined to .authorizedWhenInUse after the LocationButton has been tapped and my delegate is able to obtain the location through locationManager(_ , didUpdateLocations:). On iOS 26.x the authorisation status remains .notDetermined and my delegate receives locationManager(_:didFailWithError:) with error code .denied. Setting NSLocationWhenInUseUsageDescription in my Info.plistdid not help. Just in case ;) FB21798098 (SwiftUI LocationButton fails to acquire authorization on iOS 26)

I want to update coordinate of the lookaround instance object. But mapkit.js does not have LookAroundSceneRequest class, how am I going to do. In swift, there is MKLookAroundSceneRequest class, you can specify a new coordinate with this class, to get a new LookAroundScene object, then attach new LookAroundScene to the existing lookAround object, But how am I going to do the same with mapkit.js ?? it missing LookAroundSceneRequest class in js

I’m hitting a specific edge case with background execution that I can’t figure out. I'm using Flutter for the UI, but all the logic handles are in Swift using CoreBluetooth and CoreLocation. I need the app to wake up from a suspended state when it detects my specific BLE peripheral (OBD sensor), connect to it, and immediately start continuous location tracking for the duration of the drive. If I start this process while the app is in the foreground, or very shortly after going to BG, it works perfectly. The app stays alive for the whole trip. The issue only happens when the sequence starts from the background: The app is suspended. scanForPeripherals wakes the app when the sensor is found. In didDiscover, I immediately call locationManager.startUpdatingLocation(). locationd actually delivers updates successfully. However, 5-15 minutes later, iOS suspends the app again. Crucially, I never see the blue "Location In Use" pill on the status bar, even though I have showsBackgroundLocationIndicator = true set. Also, distance filter is set to None. Logs for reference (around suspending) locationd: {"msg":"Sending location to client","Client":"[appName]:","desiredAccuracy":"-1.000000"} runningboardd: Invalidating assertion ... from originator \\\[osservice<com.apple.bluetoothd>:...\\\] runningboardd: Removed last relative-start-date-defining assertion for process app<[appName]...> runningboardd: Calculated state ... running-suspended runningboardd: Suspending task locationd: Client [appName]: disconnected bluetoothd: State of application "[appName]" is now "suspended" Questions Why does invalidating the Bluetooth assertion cause an immediate suspend even though I called startUpdatingLocation() and am receiving updates? Does the missing blue location pill imply that the OS never fully "accepted" the location session? Is there a specific "handshake" required to transition from a BLE wake-up to a long-running location session? I'm wondering if I need to use a background task identifier to bridge the gap between the BLE wake and the location manager taking over. More context: Digging deeper in the comments, I just noticed the following patterns when the application is not suspended vs when it is recently suspended and got awaken by a BLE event. Not suspended: 303948:Jan 23 20:59:35.640118 locationd[6491] <Debug>: {"msg":"Client is setting ContinuousBackgroundLocationRequested", "Client":"[appName]:", "ContinuousBackgroundLocationRequested":1} 303949:Jan 23 20:59:35.640155 locationd[6491] <Debug>: {"msg":"Allowing process assertion due to foreground-ish status", "ClientKeyPath":"[appName]:"} Recently suspended and awaken by BLE: 564296:Jan 23 21:00:23.179125 locationd[6491] <Debug>: {"msg":"Client is setting ContinuousBackgroundLocationRequested", "Client":"[appName]:", "ContinuousBackgroundLocationRequested":1} 564298:Jan 23 21:00:23.179195 locationd[6491] <Notice>: {"msg":"#Warning Denying process assertion", "ClientKeyPath":"[appName]:"} The assertion fails for the second case and that's why the app could not persist. Most importantly, following the logs in the second case, I see the following: locationd[6491] <Notice>: {"msg":"computing freshAuthorizationContext", "Client":"[appName]:", "ClientDictionary":"{\n AlwaysServiceSession = 0;\n I suspect that the flag AlwaysServiceSession being 0 has to do with process assertion being denied for location.

Downloaded example app from here Xcode version: Version 26.1.1 (17B100) Simulator iOS Version: 26.1 & 18.5 Set custom location in the simulator to the center of the condition being monitored in the example. The only log entry was "Setup Monitor". Tried a custom gpx starting at the same point and moving 500m away. Same logs. Didn't change any of the source code, granted always permissions, allowed notifications, tapped "AddCircularGeographicCondition". Let me know if there is something I am missing or more information I can provide.

As title says. Surely rendering bitmaps is something the hardware could handle, right? Please enable MKTileOverlay for watchOS.

Does DL-TDoA ranging in the Nearby Interaction framework support building a traditional RTLS-style TDoA localization system, where a device’s absolute position is computed from time-difference measurements across multiple deployed anchors, or is DL-TDoA strictly limited to system-managed, relative ranging and direction estimation (distance/direction) between nearby devices? If DL-TDoA ranging in Nearby Interaction is not intended to support traditional RTLS-style TDoA localization, is there any public documentation or reference material that describes the intended DL-TDoA architecture, such as the expected system setup, device roles, and deployment constraints (for example, how ranging is expected to be performed between an iPhone and nearby accessories), beyond the high-level API documentation? Regards.

We are experiencing a failure in CLMonitor event delivery when the application is launched into the background via an APNS (Remote Push Notification). Even when a CLBackgroundActivitySession is instantiated immediately upon background launch, CLCircularGeographicCondition "Enter" events are suppressed. The system fails to deliver these events until the user manually brings the application to the Foreground. This indicates that CLBackgroundActivitySession does not correctly maintain background persistence when the session begins in a background state rather than transitioning from the foreground. Comparison of API Behavior (Background State) Launch via APNS: CLMonitor: Fails to trigger "Enter" events until the app is manually brought to the foreground. Legacy API: Successfully triggers and delivers "Enter" events immediately upon background launch. Exit Event Reliability: CLMonitor: Reliably triggers exit events even in the background. Legacy API: Reliably triggers exit events. Foreground Dependency: CLMonitor: Requires a foreground transition to "flush" or activate the delivery of pending entry events. Legacy API: No foreground transition required; events are delivered directly to the background process. Event Recovery: CLMonitor: Relies on the developer re-instantiating the CLMonitor and awaiting the events stream, which appears to "stall" during warm-starts. Legacy API: Relies on the CLLocationManagerDelegate which remains active as long as the manager instance exists. Steps to Reproduce Preconditions: Location Permissions: Set to "Always Allow". Background Modes: "Location updates" and "Remote notifications" enabled. App State: Terminated or Killed (by the user or the OS). Reproduction Path: Trigger Background Launch: Send a silent push notification (APNS) to wake the app in the background. Initialize Session: Within the background launch sequence (e.g., didFinishLaunchingWithOptions), immediately create and hold a strong reference to a CLBackgroundActivitySession. Register Monitor: * Initialize CLMonitor using requestMonitorWithConfiguration. Add a geofence using addConditionForMonitoring with a CLCircularGeographicCondition. Simulate Entry: Move the physical device (or simulate location) into the geofence boundary while the app remains in the background state. Observe: No "Enter" event is received in the CLMonitor event stream. Foreground Transition: Bring the app to the foreground. Actual Result: The "Enter" event is only delivered the moment the app enters the Foreground. Expected Result: The CLBackgroundActivitySession should enable CLMonitor to deliver "Enter" events immediately in the background, parity with the deprecated startMonitoringForRegion API.

I've suddenly started seeing hundreds of the same block of four error messages (see attached image) when running my app on my iOS device through Xcode. I've tried Cleaning the Build folder, but I keep seeing these messages in the console but can't find anything about them. Phone is running iOS 26.1. Xcode is at 16.4. Mac is on Sequoia 15.5. The app is primarily a MapKit SwiftUI based application. Messages below: Connection error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.PerfPowerTelemetryClientRegistrationService was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.PerfPowerTelemetryClientRegistrationService was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} (+[PPSClientDonation isRegisteredSubsystem:category:]) Permission denied: Maps / SpringfieldUsage (+[PPSClientDonation sendEventWithIdentifier:payload:]) Invalid inputs: payload={ isSPR = 0; } CAMetalLayer ignoring invalid setDrawableSize width=0.000000 height=0.000000 I'm also seeing the following error messages: CoreUI: CUIThemeStore: No theme registered with id=0

Hi all, Our company is applying for the Find My certification for our smartwearable product. Now we submitted the product plan and it's approved. The lab asked us to get the token but we searched on internet and the documents about it are limited. The CSR has approved and we already had .pem and .key file. I wonder what should we do next. Any helps are appreciated

Hey there, is there a way to set the z-index for MarkerAnnotations in MapkitJS? I'm loading up to 200 markers dynamically as the map moves or the user zooms and I want a few specific markers to always be at the top (the best search results). The only way I found is to always remove all markers and then add them again in the right order, but that's visually so annoying to see them disappear and animate in with every tiny movement. I thought about using a default Annotation and setting the z-index myself and trying to rebuild the balloon, including the animation when it's clicked, but the big downside is probably the performance because I won't be able to use shadow DOM elements and have 200 real DOM elements instead. Is there a solution to this right now or is it planned to add a feature like that to Mapkit JS? It's a real blocker for me right now because all the bad content always gets rendered on top when a user zooms in, because I obviously want to show the best content first when the user isn't zoomed in yet. Thank you so much in advance. I really appreciate it. Manuel

We have developed an iPad application using the ARCL (AR + CoreLocation) library to render Point of Interest (POI) annotations in both an AR view and a standard MapView. The application performs as expected on standard devices. However, we have some iPad covered with strong magnet. This creates significant magnetic interference, resulting in a 90° to 180° heading offset, rendering the AR POI placement and MapView orientation unusable. Technical Challenges & Constraints: Hardware Lock: The magnetic cover is a mandatory business requirement and cannot be removed during field use. Sensor Failure: The internal magnetometer cannot provide an accurate North reference due to the proximity of the cover’s magnets. While CoreLocation and CoreMotion use sensor fusion, the magnetometer remains the primary source for absolute heading. Alternative Orientation Tracking: Is there a documented method to bypass the magnetometer and derive device orientation using only the Gyroscope and Accelerometer (e.g., relative tracking) while still maintaining alignment with geographic coordinates in CoreLocation? Programmatic Offsets: Are there known APIs or mathematical workarounds to programmatically "nullify" or offset a constant magnetic bias once the device is inside the cover? so we can use that offset for ARView and in Mapview as well.

I am new to Find My network development and i am going to use Nordic solution for my FMN application. I have asked the MFi representative to enable the "Find My network" in our MFi portal. But there are just a sets of PDF in the "Find My network" under "Technology" in MFi Portal. Is there any Find My network Supplementary Agreement in MFi portal? Is it a PDF or where can i find it? Because I need to sign this document back to Nordic solution representative. But it seems there are no such FMN Supplementary Agreement.

Hello, This is my first post in the forums, and I'm still learning my way with iOS Development and Swift. My apologies if the formatting is not correct, or If I'm making any mistakes. I'm currently trying to implement an iOS App where the device needs to share the location with my server via an API call. The use case is as follows: the server expects location updates to determine if a device is inside/outside a geofence. If the device is stationary, no locations need to be sent. If the device begins moving, regardless of whether the app is in foreground, background, or terminated, the app should resume posting locations to the server. I've decided to use the CLLocationUpdate.liveUpdates() stream, together with CLBackgroundActivitySession(). However, I have not been able to achieve the behavior successfully. My app either maintains the blue CLActivitySession indicator active, regardless of whether the phone is stationary or not, or kills the Indicator (and the background capability) and does not restore it when moving again. Below I've attached my latest code snippet (the indicator disappears and does not come back). // This method is called in the didFinishLaunchingWithOptions func startLocationUpdates(precise: Bool) { // Show the location permission pop up requestAuthorization() // Stop any previous sessions stopLocationUpdates() Task { do { // If we have the right authorization, we will launch the updates in the background // using CLBackgroundActivitySession if self.manager.authorizationStatus == .authorizedAlways { self.backgroundActivity = true } else { self.backgroundActivity = false self.backgroundSession?.invalidate() } // We will start collecting live location updates for try await update in CLLocationUpdate.liveUpdates() { // Handle deprecation let stationary = if #available(iOS 18.0, *) { update.stationary } else { update.isStationary } // If the update is identified as stationary, we will skip this update // and turn off background location updates if stationary { self.backgroundSession?.invalidate() continue } // if background activity is enabled, we restore the Background Activity Session if backgroundActivity == true { self.backgroundSession = CLBackgroundActivitySession() } guard let location = update.location else { continue } // Do POST with location to server } } catch { print("Could not start location updates") } } } I'm not sure why the code does not work as expected, and I believe I may be misunderstanding how the libraries Work. My understanding is that the liveUpdates stream is capable of emitting values, even if the app has gone to the background/terminated, thus why I'm trying to stop/resume the Background Activity using the "stationary" or "isStationary" attribute coming from the update. Is the behavior I'm trying to achieve possible? If so, I'm I using the right libraries for it? Is my implementation correct? And If not, what would be the recommended approach? Regards

Hello, I’d like to ask about best practices for handling interactive snippet intents when working with the user’s location. My use case is: 1. Get the user’s location 2. Fetch nearby data 3. Display it My current flow is: try to show the snippet view in "loading" state while waiting for Core Location Manager, then fetch data and reload() the view. BUT I’m running into an issue where I sometimes receive Core Location error 1 (not authorized), even though the main app has “While In Use” authorization. It seems that in some cases, especially when the app has been force-closed, App Intents are unable to start location updates, even though I’m using supportedModes = .foreground(.dynamic). Any guidance would be appreciated. Cheers, Ondrej

In MapKit, the MKAnnotation takes a CLLocationCoordinate2D. However, in 3D/Flyover mode, the user marker has a height position on the map. We are currently plotting points which have altitude, speed, heading, etc, and I have a method for creating a CLLocation with this information. What I'm trying to figure out is if there's a way to pass that information along to the MapKit rendering engine / annotations / AnnotationViews to recognize and show when in 3D mode. Is there any support for that currently?

Recently I noticed an app called “Lookus”. Even if I force‑kill it, it still seems to obtain information such as my charging status and network status, and it can even send real‑time notifications. I’m curious how this is technically possible. Does anyone know how this could be achieved?

Hi, this is a series of questions for the Apple developers, and also for anyone that would like to speculate. How are they able to get trees marked on the in-app map? And how come they are fairly but not completely accurately marked?

I'm trying to simulate GPS in the iOS Simulator, but Debug → Simulate Location is greyed out even though I'm: Running the iOS scheme On an iPhone simulator only (no watch paired) Build configuration = Debug allowLocationSimulation="YES" in the scheme