Hello everyone, I’m experiencing an issue with App Clips Advanced Experiences and Apple Maps/Siri Suggestions. We have already contacted Apple Support before, but they are investigating the cause of this issue and it has not been resolved til date. The App Clip is bundled with the main app and has been already available on the App Store for several months. The business running the app has several physical shops and wants to offer the App Clip to show up in Apple Maps and Siri Suggestions at each location. The App Clip is correctly exposed in the AASA file, and it's also validated correctly by the AASA APIs available at https://app-site-association.cdn-apple.com/a/v1. { "applinks": { "apps": [], "details": [ { "appID": "TEAMID.bundleid", "paths": [] } ] }, "appclips": { "apps": [ "TEAMID.bundleid.Clip" ] } } (with TEAMID and bundleid being the team and bundle identifiers of the app) The App Clip is displayed correctly when loading the website and when scanning a QR code or App Clip code, but doesn't appear in the Maps app or in Siri suggestions. We have set up the App Clip Advanced Experiences on the App Store Connect page of the app, and each URL has been linked to a physical shop. All URLs are in the "Received" state, so they should appear correctly on Maps. Unfortunately, I don't see any "Order" button in Apple Maps at any location card. We tried with both iOS 17 and 16. According to feedbacks from people in the shops, they don't see the app suggested in the Siri Suggestions. I have just submitted a Custom Action Link on Apple Business Connect for one of the shops, but without success: the App Clip doesn't appear. Any idea why is this happening?

We’re building a new subway/bus app at the MTA. Our system includes roughly 300 underground stations, around 150 elevated stations (i.e., above street level), and about 5 at-grade stations (i.e., at street level). We serve roughly 5 million riders a day. We’re diving deep into Core Location on iOS and have found that the altitude values returned from two fields we’re testing aren’t accurate enough for our use case: CLLocation.altitude CMAbsoluteAltitudeData.altitude We need to reliably distinguish whether a user is: At street level On an elevated platform (see attached picture) On any platform in an underground station — most have a single platform level, but some, like 59 St (see attached), have multiple platforms at different elevations. These levels typically differ by at least 15 feet, which should in theory be well within the precision range of a properly calibrated barometric pressure sensor. However, the absolute altitude values we’re seeing from these APIs are often inaccurate and inconsistent — not only compared to ground truth, but also across devices. For example, holding two phones side-by-side frequently yields altitude readings that differ by more than 15 feet. That level of variation makes the data unreliable for our needs. Please see the below photos for more context. URLs.md

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?

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?

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!

Is MultiPolygon overlay support going to be integrated with SwiftUI? I have made a post on here previously without a reply :( Any suggestions on how to display multi-polygons within MapKit for SwiftUI(https://developer.apple.com/documentation/mapkit/mappolygon)? At the moment it is not supported and only supported by MapKit for UIKit(https://developer.apple.com/documentation/mapkit/mkmultipolygon).

I have an application that uses geolocation to track the user’s location and trigger actions when the app is in either the foreground or background. Currently, it seems that region entry is not triggered unless an app like Maps (which actively uses location services) is opened. The location permissions are correctly set to “Always” with precise location enabled. We are using geofencing to setup region and trigger actions when entering or leaving. Is there something I’m missing in the configuration that could be preventing region monitoring from triggering properly when the app is in use or in background?

I have a test application I'm working on (so it's a fresh Xcode project under Sonoma - with older map code borrowed from another project). It is a macOS application. And in Obj-C. When the map window is opened the logs contain the following - I've been trying to hunt down and resolve. Thank you in advance for any clues/pointers. Failed to locate resource "default.csv" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite@2x.styl" Failed to locate resource "satellite.styl" Failed to locate resource "satellite.styl" Couldn't find satellite.styl in framework, file name satellite.styl Authorization status: Authorized The application does have MapKit.framework included.

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.

The Uber Driver app is able to get background location and there’s no way to turn it off from settings. Unlike other apps where there’s always an option to turn off background location from settings. Is this a bug or special treatment for big companies? this matters to me because we’re in a similar business but our app has to request background permissions, explicitly. I am attaching both of the screenshots here for you to compare and see. Please note that I verified personally that Uber Driver app is able to get background location.

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

I have tried to make colored annotations in mapView (shown in the commented sections) but they always appear in black. Any help would be appreciated. func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> MKAnnotationView? { let annotationView = MKAnnotationView(annotation: annotation, reuseIdentifier: "TempAnnotationView") annotationView.canShowCallout = true annotationView.rightCalloutAccessoryView = UIButton(type: .detailDisclosure) let configuration = UIImage.SymbolConfiguration(pointSize: 10, weight: .thin, scale: .default) if annotation.title == "Start" { // let config = UIImage.SymbolConfiguration.preferringMulticolor() // let image = UIImage(systemName: "flag.fill", withConfiguration: config) // // palette // let config2 = UIImage.SymbolConfiguration(paletteColors: [.systemRed, .systemGreen, .systemBlue]) // let image2 = UIImage(systemName: "person.3.sequence.fill", withConfiguration: config2) // // hierarchical symbols // let config3 = UIImage.SymbolConfiguration(hierarchicalColor: .systemIndigo) // let image3 = UIImage(systemName: "square.stack.3d.down.right.fill", withConfiguration: config3) // // color // let image4 = UIImage(systemName: "cone.fill")?.withTintColor(.systemRed, renderingMode: .alwaysTemplate) // annotationView.image = image4 annotationView.image = UIImage(systemName: "poweron", withConfiguration: configuration) } return annotationView }

We developed a app in which the I need the app to update the User's location even in background( even after terminating from the recent UI ), Currently I am receiving the location updates when the user has kept the app in open and if minimised, But I want that it should update the location even when it is removed from recent app (minimised UI)(after terminating the app) Is it possible to do so.???

For some background, my app is a Flutter app and I have opened it in xcode to try the following, I can build and run it on a simulator from xcode as well. I want to be able to simulate custom moving locations for my app. I tried going to Debug -> Simulate Location like online tutorials show but it is all greyed out. I have location simulation enabled (I have tried changing the default location too): Within the simulator itself I only have the predefined routes or a custom static location with no option for a moving location. How can I simulate a custom moving location? If it isn't possible is there anyway to simulate the location for a Mac app as I can build the Flutter app for Mac as well?

On iPhone, we can use iBeacon to wake up the APP in the background for Bluetooth scanning connection, now we want to port the function to AppleWatch APP, but the API related to iBeacon is not applicable on watchOS, does watchOS have a similar wake up mechanism?

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?

I’m facing an issue with iOS that I hope someone can help with. I developed an app a few years ago that records GPS tracks. Up until recently, everything worked fine—even when the app was running in the background, the recording continued without problems. However, since releasing an update compiled after the iOS 18 release, users have reported that background tracking no longer works. I’ve reviewed the iOS documentation but haven’t found any relevant changes or solutions. Before the newly compiled release the app was working well on iOS 18 devices as well. Some users have reported that switching to the location permission from "When Using the App" to "Always" solved the issue. This is not the case for all users. Has anyone else encountered this issue? Any recommendations or insights on how to resolve it would be greatly appreciated. Below you can see the code used for the location tracking. Before the issue happened the app was compiled with XCode 15.4. Now I am using XCode 16.2 locationManager.activityType = CLActivityType.fitness locationManager.desiredAccuracy = kCLLocationAccuracyBest locationManager.distanceFilter = 3 locationManager.allowsBackgroundLocationUpdates = true locationManager.pausesLocationUpdatesAutomatically = false if #available(iOS 11.0, *) { locationManager.showsBackgroundLocationIndicator = true } locationManager.startUpdatingLocation() if #available(iOS 17.0, *) { // Create a CLBackgroundActivitySession object backgroundActivitySession = CLBackgroundActivitySession() } Thanks in advance for your help!

We are currently testing the implementation of our Location Push Service Extension (LPSE) in both Ad Hoc and Release environments. We have encountered an issue where LPSE notifications, which were previously working correctly, suddenly fail to be delivered on some devices. After a period of several hours, the notifications resume arriving, but the issue remains intermittent. Notably, during these periods of suspected delivery restriction, regular push notifications (e.g., those using apns-push-type: alert) are delivered and displayed without any problem. [Detailed Situation] Test Environment and Scope We are testing LPSE after obtaining the necessary entitlements, in both Ad Hoc and Release environments. The issue is not observed on all test devices; only certain devices are affected. Observed Behavior Under normal circumstances, LPSE notifications are received and the extension is activated; however, on some devices the notifications suddenly stop arriving. During these periods, even when sending notifications with apns-push-type: location directly via the CloudKit Push Notification Console, no response is observed on the affected devices. The APNs server (api.push.apple.com) always returns a 200 OK response via HTTP/2, and our server-side logs and configurations (DNS resolution performed on every request, using the same JWT token for 59 minutes per session, communication via HTTP/2 with ALPN Protocol: h2) show no issues. Other app functionalities (network communication, UI responsiveness, etc.) work normally. Sending content When sending notifications from our server to APNs (api.push.apple.com), we use the following configuration (over HTTP/2): const payload = { aps: { 'content-available': 1 } }; const headers = { ':method': 'POST', ':path': /3/device/${apnsToken}, 'Authorization': bearer ${jwtToken}, 'apns-topic': 'ot.Here.location-query', 'apns-priority': '10', 'apns-push-type': 'location', 'Content-Type': 'application/json' }; We perform DNS resolution for every request, use the same JWT token for a 59-minute period per session, and communicate via HTTP/2 with ALPN Protocol: h2. Hypothesis on the Cause We suspect that due to an implementation issue, silent push notifications (using content-available: 1) were being sent every few minutes concurrently, which may have triggered an APNs delivery restriction (rate limiting). As a countermeasure, we have completely stopped sending silent pushes and any other background notifications aside from LPSE; however, the issue persists. Additionally, even after resetting affected devices, the delivery problem continues to occur. [Questions for Diagnosis] Given the above situation, is it reasonable to suspect that excessive silent push notifications have triggered an APNs delivery restriction? Does such a silent push restriction affect LPSE notifications (i.e., those sent with apns-push-type: location)? Do APNs delivery restrictions persist even after a device has been reset? Can a high volume of LPSE notifications alone (without silent pushes) also trigger a delivery restriction? → This is our primary concern since it poses a significant implementation challenge. Please let us know if any additional information is required for diagnosis.