1. The Inquiry
Hello,
I have been implementing a background geofencing feature and, during testing, I found a significant numerical difference in event callback frequency between the older CLCircularRegion API and the newer CLMonitor API (CLMonitor.CircularGeographicCondition), introduced in iOS 17.
My testing was strictly conducted using the "Always Allow" location permission (requestAlwaysAuthorization()). I used both APIs in parallel under identical geofencing conditions and within the same implementation environment. Since a clear difference persists in the data, I suspect this may stem from structural differences in the internal mechanisms of the two APIs rather than an implementation error on my part.
2. Environment and Implementation Details (Proof of Integrity)
I have ensured that my implementation adheres to Apple's guidelines and uses modern Swift concurrency features.
A. Development Environment and Permissions
iOS Version: iOS 18.x and later
Xcode Version: Version 17A400 (Version 26.0.1)
Location Authorization: Always permission obtained.
Background Mode: Location updates is configured correctly in Info.plist.
B. CLMonitor Initialization and Lifecycle
I implemented robust lifecycle management to ensure CLMonitor is stable and persists correctly:
Initialization: I performed CLLocationManager object allocation and related service setup (e.g., CLServiceSession set to always) within the call stack frame of didFinishLaunchingWithOptions.
Monitor Management: I use an Actor-based Singleton pattern to guarantee that only a single CLMonitor instance is used application-wide.
Event Monitoring: Following initialization, I allocated a background Task containing the for try await event in await monitor.events loop. This Task is explicitly managed to persist in the background until the application is terminated, ensuring continuous event listening.
C. Registration Limit Management
I manage both APIs to ensure they never exceed the recommended maximum of 20 simultaneously monitored regions/conditions. My logic removes the oldest item (LRU) when the limit is reached.
The average registration counts during the test period were highly similar:
Component
Average Registered Count
CLCircularRegion count
7.02
CLMonitor.CircularGeographicCondition count
7.04
This confirms that registration count is not the cause of the event frequency difference.
3. Data-Based Observation
The test data (bubble_test_data_for_apple_forum.csv) records the event callbacks for both APIs under identical conditions:
Component
Total Count
Percentage of All Events (%)
CLCircularRegion Delegate Total Calls
617
83.56%
CLMonitor Event Total Fires
122
16.44%
Overall Total Count
739
100%
A. Key Findings
CLCircularRegion Operability: 617 calls confirm that core implementation factors (permissions, background setup, etc.) are functioning correctly.
Disparity in Frequency: Despite running in parallel, the CLMonitor event count (122) is approximately 1/5th the frequency of the CLCircularRegion calls (617).
Efficiency per Registration: CLCircularRegion averaged ~0.86 calls per registered item, while CLMonitor averaged only ~0.17 calls per registered item.
4. Questions for Apple Engineering
Based on the robust implementation and the data presented, I request a review of the following potential differences between the APIs:
Internal Mechanism Differences: Are there structural differences in how CLCircularRegion and CLMonitor.CircularGeographicCondition process and schedule geofencing event callbacks? For instance, do they differ in terms of battery optimization priority, event batching, or internal throttling mechanisms?
CLMonitor Event Ratio: Is the phenomenon where CLMonitor records a significantly lower ratio of events compared to CLCircularRegion an intended behavior, or could this be indicative of a specific environmental factor that affects the newer API differently?
Thank you for your time and assistance.
geofence-test-data.csv
Maps & Location
RSS for tagLearn how to integrate MapKit and Core Location to unlock the power of location-based features in your app.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I am experiencing a persistent issue with my CarPlay application where images rendered within the CarPlay Template interface disappear after the application has been used for an extended period, typically during prolonged navigation.
Images used directly within the CarPlay Template framework disappear. In the attached image showing the issue (IMG_1022.PNG), you can see that the icons for 'parking', 'gasstation', 'conveniencestore', and 'favoritespot' are missing. The side bar icons (car, battery, etc.) remain visible, and the text labels are present, but the Template-specific images/icons vanish.
Problem Description
Images displayed on a custom UIViewController remain visible. Some of our screens integrate a UIViewController (e.g., for map display), and any images rendered on that view controller (not the template itself) continue to display correctly without issue.
Example Images
IMG_1021.PNG (Normal/Correct Display): This image shows the SearchMenu screen with all icons displayed correctly next to their respective labels ('word', 'home', 'route', 'history', 'parking', 'gasstation', 'conveniencestore', 'favoritespot').
IMG_1022.PNG (Problem State): This image shows the same screen after prolonged use, where the icons next to 'parking', 'gasstation', 'conveniencestore', and 'favoritespot' have disappeared, leaving only the text labels.
Question
Has anyone encountered a similar issue? This seems to be a rendering or resource management problem specific to images within the CarPlay Template components when the application runs for an extended duration.
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:
Hi, based on https://developer.apple.com/help/account/configure-app-capabilities/create-a-maps-identifier-and-private-key described, I need to create an Identifier before I can create JWT for MapKit JS. However, I cannot find Maps Ids checkbox when I attempt to set up first MapKit JS access.
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?
Topic:
App & System Services
SubTopic:
Maps & Location
Hello,
I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150).
I observed a difference between U1-based and U2-based iPhones:
iPhone 12 Pro (U1 chip)
NINearbyObject.direction returns valid 3D vector (x, y, z).
Distance and direction both work as expected.
iPhone 15 Pro and iPhone 16 Pro (U2 chip)
NINearbyObject.direction is always nil.
Only distance is returned (around 0.35–0.40 m in my test).
Effectively behaves as "distance-only mode".
Environment:
Hardware: iPhone 12 Pro, iPhone 15 Pro
iOS version: 18.5
Accessory: Murata UWB SR040 / SR150
App: Using NINearbyAccessoryConfiguration with BLE-based discovery
Info.plist includes NSNearbyInteractionUsageDescription
Camera assistance was tested both ON and OFF
Expectation:
I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible.
Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly.
Questions:
Is this an intentional limitation for U2 chip + third-party accessories?
Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices?
Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2?
Thanks in advance for any clarification.
Since integrating MapKit JS, we’ve begun receiving production error reports with the following message:
Uncaught DataCloneError: Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': ArrayBuffer is not detachable and could not be cloned.
It appears that MapKit JS’s internal worker occasionally calls postMessage() with an ArrayBuffer that cannot be detached under Chrome 120+. This causes the structured clone to fail and the error surfaces uncaught from within the worker.
MapKit JS Version: 5.79.109
Browser: Chrome 120.0+
OS: Windows 10
Is this a known issue with MapKit JS? If so, are there recommended workarounds or planned fixes?
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?
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
Topic:
App & System Services
SubTopic:
Maps & Location
Tags:
Core Location
Maps and Location
Intents
App Intents
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
hi,
When changing the map to Satellite in Apple Maps and centering it on Ōmuta City, Fukuoka Prefecture, Japan (as shown in the image), the app crashes when swiping to the right. This issue also occurs in MapKit, and I confirmed it happens in Apple Maps as well. It seems that either the satellite map tiles are missing or an error is occurring.
Our application is experiencing a crash, and this has become a serious issue.
Since September 1, crashes have increased significantly. Initially, we suspected that the issue was due to our application’s implementation, but our investigation revealed that the problem lies with the map tiles being called through MapKit.
Could you please investigate this issue and provide a fix?
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?
My app is currently using CLGeocoder to get a CLPlacemark, then using placemark.postalAddress with CNPostalAddressFormatter to get an attributed string for the full address, I then enumerate its attributes to pull out specific elements like just the street or state or zip etc.
This is deprecated in iOS 26 with MKReverseGeocodingRequest being the intended replacement. This API returns an MKMapItem which doesn’t provide a CNPostalAddress - you can get a full address as a String but not structured address data that I’m seeing. Am I missing some way to get the postal address? Or is it a non-goal to provide that anymore? Thanks!
The documentation for CLGeocoder states
Geocoding requests are rate-limited for each app, so making too many requests in a short period of time may cause some of the requests to fail. (When the maximum rate is exceeded, the geocoder returns an error object with the CLError.Code.network error to the associated completion handler.)
And it provides helpful guidance on how and when to submit geocoding requests.
The documentation for MKReverseGeocodingRequest does not mention requests are rate-limited. Does this mean it is not rate-limited? If it is rate-limited, is it similar to CLGeocoder, what is its behavior?
It is important to understand behavior of the API in order to understand impact on my app’s use case and how users will be affected should I change the implementation. Thanks!
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