iOS Background Location / Geofencing for Automatic Attendance — App Not Triggering Reliably We are developing an enterprise attendance application called Attendo, which uses location-based geofencing for automatic employee check-in/check-out. Business requirement The application needs to work as follows: An employee is assigned an office/work location with a defined radius. When the employee enters the configured radius, the application should automatically record a Check-In. When the employee leaves the radius, the application should automatically record a Check-Out. This should happen without the employee having to open the application. The functionality needs to work even when the application is in the background and, where supported by iOS, after the application has been terminated. For example: «Office geofence = 200 meters Employee enters the 200 m radius → automatic Check-In Employee leaves the 200 m radius → automatic Check-Out» Current iOS implementation We are using iOS location services with: Location permission: Always Precise Location: enabled Background Location capability enabled Background location updates enabled Geofencing / region monitoring The application is intended to respond to location/geofence events without requiring the user to open the app. However, we are seeing cases where the application does not reliably receive/process the required location/geofence event when the application has been in the background for an extended period. The same business workflow works more reliably while the application is active. Our concern Our understanding is that iOS does not allow an application to maintain a continuously running background service in the same way that Android can. However, our requirement does not necessarily require continuous GPS polling if there is an Apple-supported mechanism that can reliably wake/relaunch the application when a user crosses a geofence. We would therefore like to understand the recommended architecture for this use case. Questions Is Core Location Region Monitoring the recommended mechanism for an enterprise geofencing application that needs to detect entry/exit while the app is not running? Can iOS relaunch the application after it has been terminated by the user/system when a monitored region is entered or exited? Is there any supported way to guarantee that an application will continue receiving location/geofence events after it has been in the background for a long period? Does enabling: "UIBackgroundModes = location" "allowsBackgroundLocationUpdates" "CLLocationManager" Region Monitoring provide the expected behavior, or are there additional requirements/configurations we should consider? Are there known limitations regarding: Low Power Mode device movement speed GPS/location accuracy stationary devices iOS terminating/suspending the application force-quitting the application from the App Switcher large/small geofence radius multiple monitored regions Is it possible to use significant-change location updates + region monitoring together for this type of attendance workflow? For an enterprise application where the user explicitly grants Always Allow Location permission and Precise Location is enabled, what level of reliability can realistically be expected from iOS geofencing? Important business constraint We cannot require employees to manually open the application every time they arrive at or leave the workplace. The objective is an automatic attendance system, where the employee's entry and exit from the workplace geofence is detected by iOS and the application records the corresponding attendance event. We understand that iOS is designed to protect battery life and user privacy and that continuous background execution may not be permitted. We are therefore looking for the Apple-recommended architecture for achieving this requirement using supported iOS APIs, rather than trying to circumvent iOS background execution policies. Any guidance from Apple engineers or developers who have implemented reliable enterprise geofencing would be greatly appreciated.

For an application supporting iOS 16 and later, is there a supported public API that exposes a monotonic timestamp for the original determination of a CLLocation, rather than the time it is delivered to CLLocationManagerDelegate? The requirement is to reject observations whose original acquisition age exceeds 10,000,000,000 ns at the final native transport-dispatch check. Exactly 10 seconds is allowed; 10 seconds plus 1 ns is rejected before conversion to milliseconds. This is an arithmetic boundary requirement, not an assumption that location measurements have nanosecond physical accuracy. CLLocation.timestamp is a Date for when the location was determined. Sampling a continuous monotonic clock in didUpdateLocations instead measures callback receipt. Cached observations, batched updates and delayed background delivery can separate those events. Does a public API provide either: A monotonic acquisition/determination timestamp associated with that same CLLocation; or A documented finite uncertainty bound and supported method for relating its Date timestamp to a sleep-inclusive monotonic clock at dispatch? How do the documented guarantees handle wall-clock adjustments between determination and delivery, device sleep, suspension, queued updates and process restarts? If a newer API supplies stronger evidence, what is its minimum supported iOS version? If neither mechanism is available, is there a supported request or delivery mode that establishes a documented lower bound on the original determination time and can reliably reject older cached observations? A recent callback or request by itself would not establish that relationship. I would appreciate documentation describing the guarantees, limitations or supported alternatives. I have not established that such a mechanism is impossible; this is a capability clarification, not a claim of a reproduced operating-system defect.

Does Apple provide a supported public API or entitlement for an App Store iPhone app to simulate the system location consumed by other apps entirely on-device? Would using a bundled Network Extension and on-device developer pairing remain restricted to development/testing workflows?

MacBook Air (M4) Current build: macOS 27 Developer Beta (26A5368g) I have a system-wide Location Services failure affecting Apple Maps, Safari geolocation APIs, and any application requesting the current location. Symptoms: Apple Maps cannot determine current location. Safari and browser geolocation APIs fail. Websites report that location cannot be found. Location Services are enabled and permissions are granted. The issue has persisted across: macOS 26.5 beta macOS 26.6 beta macOS 26.6 beta 2 macOS 27 Developer Beta Troubleshooting already performed: Multiple Wi-Fi networks tested. iPhone hotspot tested. VPN enabled and disabled. Location Services reset. Permissions reset and reauthorized. New clean local user account created (no Apple ID, no third-party software). Issue reproduces identically in the clean account. Technical observations: locationd logs repeatedly show: knownCount = 0 AlsWifi = unknown while Wi-Fi scanning itself appears successful: queryMacAddresses.size = 57 The system sees dozens of nearby access points, but none appear to be recognized for Wi-Fi positioning. Additional findings: Wi-Fi hardware functions normally. Internet connectivity is normal. Bluetooth and Find My device presence work. GeoServices resources are present on disk. No successful location fix is ever produced. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated?

I am experiencing a system-wide Location Services failure on my MacBook running macOS 27.0.1. Several days after the problem first appeared on the Mac, my iPad Pro (Wi-Fi-only model) developed a very similar issue. Both devices are in Ukraine and should use the Europe/Kyiv time zone. The Mac unexpectedly selected Cupertino, PDT, while the iPad selected a Chinese time zone. Location detection is now failing in Apple Maps, Weather, browsers, and other applications using Core Location. My iPhone continues to determine its location correctly. The macOS locationd diagnostic logs show that Wi-Fi access points are being discovered but none are recognized as known references in the observed positioning check. Steps to reproduce Connect the affected Mac to a working Wi-Fi network with internet access. Ensure Location Services are enabled. Open Apple Maps and request the current location. Attempt browser-based geolocation using a website that requests the current location. Open System Settings → General → Date & Time and enable automatic time-zone detection. Observe the inability to determine the correct location and the incorrect automatic time-zone selection. The failure persists across multiple Wi-Fi networks, including an iPhone Personal Hotspot. Expected result Core Location should correctly determine the approximate physical location in Ukraine using available positioning information. Apple Maps, Weather, browsers, and other applications should receive valid location data. Automatic time-zone detection should select Europe/Kyiv. Actual result Apple Maps cannot correctly determine the current location. Browser geolocation fails. Weather displays incorrect location-dependent information. Automatic time-zone detection selected Cupertino (PDT) on the Mac instead of Europe/Kyiv. The Wi-Fi-only iPad Pro independently selected a Chinese time zone instead of Europe/Kyiv. Automatic location detection remains unusable across applications. The problem persists after connecting to different Wi-Fi networks. The Mac problem began suddenly during normal use. Around that time, the system automatically transitioned to dark appearance for the evening (as expected), but the automatic time zone also changed unexpectedly. The iPad developed similar symptoms several days later. Troubleshooting already performed Tested multiple Wi-Fi networks. Tested internet access through an iPhone Personal Hotspot. Checked IP-based geolocation using external services; these correctly identify the geographic region. Considered VPN-related causes; the behavior is not explained by the IP geolocation results. Confirmed that Location Services work correctly on my iPhone. The simultaneous involvement of two independent devices, combined with normal iPhone positioning, suggests a possible failure in Wi-Fi-based positioning or the associated system services rather than an isolated hardware issue. Technical diagnostics On October 22, 2026, the following message was obtained from the macOS locationd unified log: 2026-10-22 22:31:00.638 Df locationd[387:2755b6] [com.apple.locationd.Position:GeneralCLX] WifiAps, querycheck, knownCount, 0, unknownCount, 17, knownCountTile, 0, knownToUnknownRatio, 0.0, queryMacAddresses.size, 34, sinceLastServerQuery, 187.15, isQueryNeeded, 1, forceQuery, 0, queryType, 0, reqType, 0 Important diagnostic fields: knownCount = 0 unknownCount = 17 knownCountTile = 0 knownToUnknownRatio = 0.0 queryMacAddresses.size = 34 isQueryNeeded = 1 These values indicate that the positioning subsystem is discovering Wi-Fi access points but has no recognized positioning references in this particular check. This resembles a previously reported Core Location / GeoServices failure. Potentially related existing reports Apple Developer Forums: https://developer.apple.com/forums/thread/835896 The discussion documents a similar system-wide location failure with knownCount = 0 despite successful Wi-Fi scanning. Feedback IDs submitted by another affected user: FB23196632 FB23366087 There are also independent reports from Ukrainian users whose Macs incorrectly determine their location or time zone as China: https://www.reddit.com/r/MacOS/comments/1nt0lli/location_glitch/ These reports may involve the same underlying issue, but a common root cause has not been confirmed. Request for investigation Please investigate whether this issue is related to: Apple's Wi-Fi positioning database or lookup service. Core Location / GeoServices processing of Wi-Fi-based location results. Incorrect, missing, or stale Wi-Fi access-point location records. Local positioning cache or Wi-Fi regulatory-domain problems. I would particularly appreciate investigation of the knownCount = 0 condition and whether it can explain the incorrect time-zone selection on two separate devices. Please route this report to the appropriate macOS Core Location / GeoServices engineering team. I can provide additional diagnostic logs and sysdiagnose data if required.

Hello! I was looking through Apple's documentation about Core Location and the Location Push Service Extension, and it seems like you can 'pass-off' liveUpdates(_:) to the main app (yes, that's simplified), but they don't seem to explain what that means, and any way on how to do it. Do they just mean like a SLC, or silent push? I am just curious, because it isn't clear at all what they mean. Thanks!

I'm developing a location-testing workflow for an owner-authorized physical iPhone using Xcode 27.0 and CoreDevice 642.16. The installed devicectl device simulate location coordinate and clear commands are available. The installed help states that simulation continues until cleared and describes clearing as returning to actual location. Before proceeding with physical-device testing, I'd appreciate clarification on five questions: Persistence: Does location simulation remain active after USB disconnection, termination of the developer connection, Mac sleep, or Mac shutdown? Find My: Does this simulation affect Find My People / My Location, Find My Devices, both, or neither? Is either behavior officially supported? Recovery: If clearing fails or the initiating Mac is unavailable, what supported procedure restores actual location? Remote control: Can an authorized developer change or clear the simulated location when the Mac and iPhone are geographically separated and on different networks? Standalone operation: Is there any documented API, entitlement, or device-management capability allowing an installed iPhone app to control system-wide simulated location independently of a Mac? I'm seeking documented behavior and a safe, reversible testing procedure, particularly where Find My and recovery are concerned. Thank you for any guidance or official documentation.

There is a post out on the main community page (https://discussions.apple.com/thread/256371563?answerId=262162384022&sortBy=rank#262162384022) that discusses several users with issues around the GPS not working after the iPadOS 27 update on Gen 9 iPads. I also ran into this. I did everything mentioned in the community post (including completely wiping my iPad) and nothing worked. However, I did try updating to 27.2 Beta 4 and it seems to have fixed the issue. Is there a specific fix for the GPS not working on an iPad Gen 9 after upgrading to iPadOS 27 in 27.2? I'm thrilled it is working again, but wondering if it's just a fluke or if something really was addressed?

Hello, I'm encountering an issue with UNLocationNotificationTrigger in my iOS app. I've scheduled three local notifications using UNLocationNotificationTrigger, each tied to a distinct geographic region. These regions are significantly distant from one another and should not trigger simultaneously under normal movement conditions. However, during testing, the user received all three notifications within one second, despite being physically located near only one of the regions. This behavior is unexpected and defeats the purpose of using location-based triggers. Could you please clarify why this might be happening? Is there a known issue with UNLocationTrigger, or is there a possibility that iOS preemptively triggers all scheduled location notifications? Any guidance or recommended practices to avoid this behavior would be greatly appreciated. Thank you!

I'm working on a navigation app. Since updating to iOS / iPadOS 27, several users have reported that location updates stop during navigation, or that the displayed location is far from where they actually are. Some users say the same thing happens in Apple Maps and Google Maps, so the cause seems to be in the OS rather than in any particular app's implementation. Reported symptoms The current location stops updating, or updates intermittently, during navigation The current location is shown far away from the user's actual position Reported devices and OS versions Almost all reports come from the iPad (9th generation), but the issue also occurs on iPhone. iPad (9th generation) Wi-Fi + Cellular / iPadOS 27.0 iPhone 16 Pro Max / iOS 27.0 iPhone 16 Pro / iOS 27.2 Public Beta iPhone 17 / iOS 27.0 Suggested workarounds (none resolved the issue) None of the following steps suggested to users helped: Checking location permissions ("While Using the App" or "Always", with "Precise Location" turned on) Turning Location Services off and on again Restarting the device Using "Reset Location & Privacy" Questions Has anyone else received similar reports on iOS / iPadOS 27? Any app-side workarounds would be greatly appreciated.

I am the developer of the Progressive Web App (PWA) FindMeSAR which displays the user’s coordinates in several different formats. https://findmesar.com When this PWA is not installed on my iPhone 17 Pro then I can use Safari to open this webpage and give permission for it to use my location. FindMeSAR works fine and displays my coordinates as latitude longitude in decimal degrees. I can also use Safari to open Google maps and geolocation there also works fine. But if I install FindMeSAR for use offline as a PWA then I get an error message saying location is denied. My iPhone has the latest iOS 26.0.1 I should add that I recently traded in an iPhone 13 Pro with iOS 17. FindMeSAR worked fine on that device as a PWA including the geolocation feature. Has anyone else with iOS 26 tried a PWA that does geolocation? Results?

MapKit offers showsTraffic: Bool, which is great for displaying live traffic data on the map. However, MapPolyline sits above it, which makes it quite useless. Is this the expected behaviour?

I'm building a two-iPhone app that times a 40-yard (36.576 m) sprint — one phone at the start, one at the finish. Before timing, I need to verify the phones are at least 40 yards apart (no external hardware, no Wi-Fi infrastructure — they talk over my own relay, clocks already synced). I want this to work on as many iPhone models as possible. Questions, by device generation: iPhone 11–14 (1st-gen Ultra Wideband): can these reliably range at ~36.6 m outdoors with Nearby Interaction, or does precise ranging at this distance effectively require 2nd-gen? iPhone 15+ (2nd-gen UWB / Extended Distance Measurement): has anyone measured real-world accuracy at ~30–40 m outdoors? Can it reliably distinguish ~39.9 yd from ~40.1 yd? Which distance-quality signals do you gate a hard pass/fail on (when to trust NINearbyObject.distance, convergence/averaging)? No Ultra Wideband (e.g., iPhone 16e): any Apple-supported approach for approximate phone-to-phone distance at this range, or do you mark the feature unsupported there? After hands-on results at 30 m+ especially — most threads cover indoor/short range. Thanks!

Apple Watch Ultra 2, watchOS 27.0, Xcode 27. I use CLLocationManager.startUpdatingHeading(), headingFilter=1 and CLHeading.magneticHeading directly, with no offset or GPS course. During surfing, my app and Apple Compass both showed an apparent error of about 180 degrees. The iPhone was not nearby or connected. Later, outside water, readings returned to normal. An analog compass on the opposite arm differed by about 30 degrees initially, then agreed. All saved Int(headingAccuracy) values were 89; it still displays 89 while the heading is correct. Raw fractional values were not saved. Is this an expected or sentinel value on watchOS? What calibration and diagnostics are recommended for the intermittent reversal? The app also uses an underwater-depth extended runtime session; its errors have not been linked to the heading issue.

We 7develop a location-tracking backend for sailing regatta tracking (RegattaHero, GPS tracking of racing sailboats via a Flutter iOS app). We rely on CLLocationManager for continuous position updates during races that can last several hours. Problem: In light wind conditions, a sailboat can move at low but steady speed (e.g. 1-2 knots) with essentially no acceleration signature - unlike automotive or fitness activities, which involve intermittent acceleration/deceleration (starting, braking, footstrikes). We suspect Core Location's motion-based heuristics (built on accelerometer/motion coprocessor data, not solely GPS delta) interpret this near-constant, low-acceleration motion as "stationary" or low-priority, resulting in reduced update frequency or unexpected pausing of location updates. We have already set pausesLocationUpdatesAutomatically = false explicitly, which per documentation should prevent automatic pausing entirely - but we still observe degraded update behavior in these conditions. This suggests the effect is not limited to the auto-pause mechanism but also influences other parts of the positioning/update-frequency pipeline that key off activityType. We currently use activityType = .otherNavigation (the closest existing match, covering "boats" alongside cycling/trains/off-road vehicles), but this activity type appears tuned around vehicles with more typical acceleration profiles, not low-speed, low-acceleration marine drift. Steps to Reproduce: Set activityType = .otherNavigation, pausesLocationUpdatesAutomatically = false, desiredAccuracy = kCLLocationAccuracyBestForNavigation Track a device moving continuously at 1-3 knots with minimal acceleration variance (e.g. sailboat drifting/sailing in light wind, or equivalent slow, smooth continuous motion) over an extended period (30+ minutes) Compare update frequency/consistency to a scenario with typical stop-and-go motion (e.g. driving in traffic) Expected: Consistent location update delivery reflecting actual continuous movement, independent of acceleration variance, when pausesLocationUpdatesAutomatically is explicitly disabled. Actual: Update frequency/consistency appears to degrade during sustained low-acceleration, low-to-moderate-speed motion at sea, despite auto-pause being disabled. Suggestion: Either: (a) Add a dedicated CLActivityType case for marine/nautical navigation, with pause/throttling heuristics based on speed-over-ground rather than acceleration signatures, or (b) Document/expose a way to fully decouple update-frequency behavior from the motion-coprocessor-based heuristic when pausesLocationUpdatesAutomatically = false is set, so this flag reliably covers all related throttling behavior, not just the auto-pause feature itself.

I'm looking to access Apple Maps place metadata, particularly opening hours to route a user between 3 points. Suppose point C opens in the morning and B in the evening, I'd make sure to route the user based on which place is open at the time, eg A => C => B I understand from this thread that opening hours is not something app integrations can export. I was also checking out the batch endpoint. While its not necessary to export the data or display it inline, I'm looking for ways that my app can consume or consider this when routing between multiple places.

Apple's Location Services & Privacy notice (https://www.apple.com/legal/privacy/data/en/location-services/) describes per-app sharing of Visited Places and Preferred Routes/Predicted Destinations where available. We are investigating a transit companion with a watchOS app and an optional iPhone companion. We have checked public developer documentation and installed SDK interfaces but have not identified the API that delivers these shared records. Which public SDK interface, entitlement or enrollment process implements this capability for third-party apps? A documentation or sample link, with supported platforms and eligibility requirements, would let us build a minimal probe. We are asking about delivery of the shared records, rather than monitoring new visits with Core Location or supplying relevance hints to the system.

Hello, I develped underground GNSS solution. The goal of this is to achieve seamless GNSS for navigation and autonomous driving. The solution we developed has been installed in tunnel in Korea. We tested it using an Android phone and iPhone. We check the Android phone's response using the GNSSLogger App. however, there is not one for the iPhone. I want to make PERFECT solution in tunnel. So, how can I get GNSS log from and iPhone? Thanks.

We are seeing a reproducible issue on a physical iPhone with Dynamic Island. Steps to reproduce Install and launch version 1 of the app locally. Start background location tracking using CLLocationUpdate.liveUpdates() together with CLBackgroundActivitySession. Move the app to the background. The blue location indicator appears in the Dynamic Island. While tracking is still active, install version 2 over the existing app. Open the updated app. Stop all location tracking: Cancel the CLLocationUpdate task. Call invalidate() on the CLBackgroundActivitySession. Release all references to the session. Move the app to the background again. Expected behavior The blue background location indicator disappears after the location updates and background activity session have been stopped. Actual behavior The blue location indicator remains permanently visible in the Dynamic Island, even though: No location updates are being received. No CLBackgroundActivitySession is retained. Starting and stopping another location session does not remove it. Force-quitting and reopening the app does not remove it. Only restarting the iPhone makes the indicator disappear. The problem occurs when a new build is installed over an existing installation while a background location session is active. Starting and stopping the same session normally within one installed version works as expected. Comparison with Live Activity background location The app also has a separate location feature that uses an active Live Activity to support background location updates without creating a CLBackgroundActivitySession. Installing a new build while that feature is active does not cause the blue location indicator to become stuck. The problem has only been reproduced when a CLBackgroundActivitySession is active during the installation. This suggests that the issue is specifically related to transferring or cleaning up CLBackgroundActivitySession state across an app update, rather than to CLLocationUpdate.liveUpdates() itself. Questions Is this a known issue with CLBackgroundActivitySession or CLLocationUpdate.liveUpdates()? Is there a supported way for the newly installed app process to invalidate or clean up a background location session created by the previous app process?

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!