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

Summary While parallel testing Core Location on the new iOS 26.1 beta (23B5044i), I observed what I believe to be a regression of the issue described here: https://developer.apple.com/forums/thread/779192 Specifically, user positioning underground subway stations is noticeably inaccurate on the beta, whereas the same scenarios remain accurate on the unupgraded device below. I work with the MTA (New York City) and work with the OP of that thread. Happy to provide additional testing or details if helpful. Please let me know what else you need. Test Info Riding NYCT from Wall St to 34th St Penn Station on the 2 train carrying two iphones Recording: https://limewire.com/d/dpTWi#pDC3GRYIdE Expected: Consistent underground positioning comparable to prior releases. Actual: Degraded/inaccurate underground positioning on iOS 26.1 beta. Test Devices Left Screen: iPhone 15 Pro Max - iOS 26.1 beta (23B5044i) Right Screen: iPhone 11 - iOS 18.6.2 (22G100) Blue dots show location set by CoreLocation. Red dot on iphone 11 shows the actual location of both devices as I was able to manually place while travelling through a station. Placement through tunnels is not easy to verify and not usually indicated. Timestamps Comparison of when train was actually observed in a station vs when 26.1 and 18.6.2 CoreLocation updated to the station Fulton St 1:48 iOS 26.1 correctly updates (correctly) 2:16 iOS 18.6.2 updates (28sec late) Park Place 4:12 train arrives 4:15 iOS 18.6.2 updates to ~near Park Place 5:04 iOS 18.6.2 updates to Park Place (correctly) 6:07 iOS 26.1 update to ~near Park Place (over 2 mins late) Chambers St 6:02 train arrives / iOS 18.6.2 updates (correctly) 6:14 iOS 26.1 updates to ~near Chambers 6:18 iOS 26.1 update to Chambers (correctly) Franklin St 6:52 train arrives 6:55 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Canal St: 7:16 train arrives 7:18 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Houston St 7:54 train arrives 8:00 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Christopher St 8:37 iOS 26.1 presumably between Houston St and Christopher St 8:40 train arrives / iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update 14 St 9:22 train arrives 9:28 iOS 18.6.2 updates (correctly) 11:01 as train departs station iOS 26.1 updates (1.5 mins late)

Hi, We are using beacon ranging methods to detect beacon in foreground and background in our app. We are using beacon's UUID, major and minor values to create a beacon region and then calling locationManager.startRangingBeacons to range beacons. We listen for beacon updates via the didRangeBeacons delegate method to get beacon data emitted. However, we've observed some inconsistent behavior: The beacon region frequently reports exit events even when the device is within close proximity (approximately 1.5 to 2 meters). There are instances where no beacon updates are received for extended periods (up to 15–20 minutes), despite the beacon being nearby. Generally, The distance between the device and the beacon is approximately 1.5 - 2 meters. What could be the reason for this behaviour and how can we avoid it and continuously receive beacon updates when the beacon is near without any delay? Thanks

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

Since iOS 26 the delegate method locationManager(:didVisit:) is no longer invoked reliably while locationManager(:didUpdateLocations:) continues to be called regularly on the same devices. The issue appears to be directly tied to iOS version updates. Visit callbacks worked consistently under iOS 18.x but in some cases stopped being invoked immediately after updating the same device to iOS 26.0. In other cases didVisit worked on iOS 26.0 but stopped after updating to 26.0.1 and similarly from 26.0.1 to 26.1. The behaviour is inconsistent with no identifiable pattern and affects multiple recent device models. All required configuration is in place: – startMonitoringVisits() is called correctly – location permission is set to “Always”– background mode for location updates is enabled – allowsBackgroundLocationUpdates is enabled – restarting the app or the device does not fix the problem The only workaround that restores visit monitoring is deleting the app and reinstalling the same App Store version which is not a viable solution for end users. Have other developers experienced the same issue and are there any recommended best practices or technical guidelines to handle missing didVisit callbacks after updating to iOS 26?

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?

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.

This is my first post here. Please guide me, if I need to provide more information to answer this post. I write a simple application, that monitors GPS position (location). I followed Apple documentation for LiveUpdates: https://developer.apple.com/documentation/corelocation/supporting-live-updates-in-swiftui-and-mac-catalyst-apps My app can monitor location in foreground, background or it can completely stop monitoring location. Background location, if needed, is switched on when application changes scenePhase to .background. But it is in the foreground, that memory leaks occur (according to Instruments/Leaks. Namely Leaks points to the instruction: let updates = CLLocationUpdate.liveUpdates() every time I start location and then stop it, by setting updatesStarted to false. Leaks claims there are 5x leaks there: Malloc 32 Bytes 1 0x6000002c1d00 32 Bytes libswiftDispatch.dylib OS_dispatch_queue.init(label:qos:attributes:autoreleaseFrequency:target:) CLDispatchSilo 1 0x60000269e700 96 Bytes CoreLocation 0x184525c64 Malloc 48 Bytes 1 0x600000c8f2d0 48 Bytes Foundation +[NSString stringWithUTF8String:] NSMutableSet 1 0x6000002c4240 32 Bytes LocationSupport 0x18baa65d4 dispatch_queue_t (serial) 1 0x600002c69c80 128 Bytes libswiftDispatch.dylib OS_dispatch_queue.init(label:qos:attributes:autoreleaseFrequency:target:) I tried [weak self] in Task, but it doesn't solve the leaks problem and causes other issues, so I dropped it. Anyway, Apple doesn't use it either. Just in case this is my function, which has been slightly changed comparing to Apple example, to suit my needs: func startLocationUpdates() { Task() { do { self.updatesStarted = true let updates = CLLocationUpdate.liveUpdates() for try await update in updates { // End location updates by breaking out of the loop. if !self.updatesStarted { self.location = nil self.mapLocation = nil self.track.removeAll() break } if let loc = update.location { let locationCoordinate = loc.coordinate let location2D = CLLocationCoordinate2D(latitude: locationCoordinate.latitude, longitude: locationCoordinate.longitude) self.location = location2D if self.isAnchor { if #available(iOS 18.0, *) { if !update.stationary { self.track.append(location2D) } } else { // Fallback on earlier versions if !update.isStationary { self.track.append(location2D) } } } } } } catch { // } return } } Can anyone help me locating these leaks?

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?

We (at the NYC MTA) are building a new subway/bus app and diving deep into location tracking on iOS. We’re encountering an issue with how Core Location functions in the subway, specifically regarding how long it takes to update a passenger’s location as they travel from station to station. As an example, please see this video: https://drive.google.com/file/d/1yaddkjyPEETvTEmClPAJ2wks8b-_whqB/view?usp=sharing The red dot is set manually (via a tap gesture) and represents the ground truth of where the phone actually is at that moment. The most critical moment to observe is when the train physically arrives at a station (i.e., when I can see the platform outside my window). At this moment, I update the red dot to the center of the station on the map. Similarly, I adjust the red dot when the train departs a station, placing it just outside the station in the direction of travel. The trip shown is from Rector St to 14 St. All times are in EST. I’d like to investigate this issue further since providing a seamless underground location experience is crucial for customers. As a point of comparison, Android phones exhibit near-perfect behavior, proving that this is technically feasible. We want to ensure the iOS experience is just as smooth.

In the last few months we have seen a lot of the following errors in which it fails to retrieve location information. This seems to happen across multiple browsers and feels related to apple/mac OS more than the browsers. Error: "CoreLocationProvider: CoreLocation framework reported a kCLErrorLocationUnknown failure." Any suggestions or an ETA on when this can be fixed? I have seen other threads/posts on this but wanted a new one to highlight the issue is prevalent.

I am encountering a coordinate rendering issue using MKMapView in my iOS app. I have a GPS coordinate in WGS84 format, which corresponds to a location in Hong Kong. When my device is physically located in Hong Kong, MKMapView displays the map with the "Apple Maps" label, and the WGS84 coordinate is rendered at the correct position. However, when the device is in Mainland China, MKMapView switches to display "Amap" (Gaode Maps) branding, and the same WGS84 coordinate is rendered at an incorrect position. I understand that Amap in Mainland China uses the GCJ-02 coordinate system, while Apple Maps typically uses WGS84. This discrepancy suggests a potential coordinate system mismatch, but I cannot definitively confirm which map type (and corresponding coordinate system) MKMapView is actually using in different regions. My key questions are: How can I programmatically or visually confirm the underlying map type (Apple Maps vs. Amap) and its coordinate system within MKMapView? Is there a way to simulate the Apple Maps environment for testing when physically located in Mainland China?

We developed an IMDF indoor map for a client (paid work) which we submitted to Apple a few months ago. Our client is wondering how many months the approval process will take. Also, we would like to get paid for the work. Any estimate from that team would be appreciated. Thank you

The easiest way to explain this is to show it. On any device, open Maps, set it to Driving (which will show traffic). Go to Baltimore Maryland. In the water just south east of the city there is a bridge (Francis Scott Key Bridge). . On Apple Maps the road is colored dark red. At certain zoom levels, there is a "button" (red circle with a white - in it). When you click on that "button", it says 1 Advisory (Road Closed). How do I show this "button" on my map. My map shows the dark red color, but no "button" appears. The only "advisory" that I've been able to find is when you create a route. Of course you can't create a route over a road that fell into the water. struct ContentView: View { @State private var position = MapCameraPosition.region( MKCoordinateRegion( center: CLLocationCoordinate2D(latitude: 39.22742855118304, longitude: -76.52228412310761), span: MKCoordinateSpan(latitudeDelta: 0.05407607689684113, longitudeDelta: 0.04606660133347873) ) ) var body: some View { Map(position: $position) .mapStyle(.standard(pointsOfInterest: .all, showsTraffic: true)) .cornerRadius(25) } } Is this a WCDWAD, or is there a way to show the "button" (We Can't Do What Apple Does)

Hey All, Seem to be in a loop and unable to proceed. New app specific for iOS being built on xCode. Project is configured only to deploy and use iOS, not macOS or anything else. Trying to create a new App iD always see it default to all platforms which means "Background Modes" is not visible or available. Automatic signing etc in xcode can't seem to get around this and just continues to flag I'm missing the entitlement for locations.background. Not sure what I am missing as I cannot manually configure the ID for iOS only and xcode is also generating new ID's with the same platform structure and constraints. Any thoughts or insights here please?

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!

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?

Hello, I upgraded my Apple Developer account from free to paid (Individual), but I cannot enable “Background Modes” (specifically “Location updates”) for any of my App IDs—including both old App IDs created while on the free account and brand new App IDs created after upgrading. When I go to Apple Developer Portal > Identifiers > [select App ID] > Edit, the option for “Background Modes” is missing from the list of capabilities. This is preventing me from enabling required entitlements for background location in Xcode, and all provisioning profiles fail with errors such as: Provisioning profile "iOS Team Provisioning Profile: [my bundle id]" doesn't include the com.apple.developer.location.always and com.apple.developer.location.background entitlements. Steps I’ve Taken: Upgraded to a paid Apple Developer Program (verified in my account). Created new App IDs after upgrading—Background Modes is still missing. Created new Xcode projects with new App IDs and bundle identifiers—same result. Refreshed provisioning profiles, cleaned Xcode, logged out/in—no change. Contacted Apple Support; advised to file a Code-Level Support request, but the issue is with the portal/App ID capabilities, not my code. My Question: Has anyone experienced this issue where Background Modes capability is missing for all App IDs, even after upgrading to a paid account? Is there any workaround, or does this require intervention from Apple Developer Support to “unlock” the missing capabilities for my developer account? Any insight or advice would be appreciated! Thank you.

Hello, I'm currently implementing code to track routes and determine if users have arrived at their destination using CLServiceSession, CLBackgroundActivitySession, and CLLocationUpdate.liveUpdates. I want to obtain location data across all app states: foreground, background, and terminated. I have two questions: Background Location Indicator Issue: I'm using CLBackgroundActivitySession to get location updates in the background. Normally, the background location indicator (blue bar) doesn't appear at the top left of the screen for my app. However, when another app (e.g., LiveUpdatesSample) activates CLBackgroundActivitySession, my app's background location indicator suddenly becomes visible. Can you explain why this happens? or Can I Control showsBackgroundLocationIndicator in CLBackgroundActivitySession Session Management: Is there a way to terminate all currently active CLBackgroundActivitySessions? I understand that when CLBackgroundActivitySession is activated and the app is terminated and then relaunched, a new CLBackgroundActivitySession needs to be created. In this case, are the previously created and running CLBackgroundActivitySessions automatically released when the app is relaunched?

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