Hello, I am trying to gather information on the global availability of the Apple Find My Network. Specifically, I would like to know: Which countries currently support this feature? Is it available worldwide, with only a few specific countries/regions facing usage restrictions or complete unavailability? I have already reviewed the public Feature Availability page, but was unable to find any documentation addressing regional restrictions. Any clarification or pointers to relevant documentation would be greatly appreciated. Thank you!

Hey Apple team, I'd love to see a native wind animation layer added to Apple Maps and MapKit. A built-in, system-level wind visualization — similar to the animated weather layers seen in third-party apps — would be an incredibly powerful tool for developers building weather, aviation, marine, outdoor recreation, and navigation apps. Having this baked natively into MapKit would mean smoother performance, better battery efficiency, and a consistent experience across iOS, iPadOS, and macOS — rather than every developer having to reinvent the wheel with custom particle systems or third-party SDKs. Please Apple — this would be a fantastic addition to the Maps ecosystem. 🌬️🗺️

Our app supports UIScene. As a result, launchOptions in application(_:didFinishLaunchingWithOptions:) is always nil. However, the documentation mentions that UIApplication.LaunchOptionsKey.location should be present when the app is launched due to a location event. Given that our app is scene-based: How can we reliably determine whether the app was launched due to a location update, geofence, or significant location change? Is there a recommended pattern or API to detect this scenario in a Scene-based app lifecycle? This information is critical for us to correctly initialize location-related logic on launch. Relevant documentation: https://developer.apple.com/documentation/corelocation/cllocationmanager/startmonitoringsignificantlocationchanges()

Hello everyone, a few months ago I started building an app using flutter, and a few days ago when I told one of my friends to test it trough Test Flight he asked me why it shows an 🟡 Yellow Circle in front of the app name ? is there an Apple documentation regarding this yellow circle so I can point others to that page ? I googled to find out about this behaviour and it says that my app uses the microphone, but I do not have any code, any library that is using the microphone, it is an Outdoor/GPS Recording app. Thank you.

Recently, we have received continuous feedback from users that the Bluetooth key and digital key are not working properly or are not functioning; Through analysis of App logs, it was found that after the iOS system locks the screen, the iBeacon background keep-alive function fails, Bluetooth connection also fails, and system callbacks cannot be obtained; the digital key also fails, and it fails simultaneously with the Bluetooth key; We have checked the specific permission configuration and it aligns with the recommended configuration in the official documentation, with no abnormalities. Although this type of issue is not a widespread problem, it has been continuously reported by users and is very troublesome. Does the official team have a clear explanation? Why are both Bluetooth keys and digital keys affected after the app is locked? Digital keys should be less affected. The following is a log analysis of a certain user 1: Step 2, the App entered the background; Step 3, the App's Bluetooth was disconnected; 3-4 The App remained in the background for 5 hours before being launched again 2: This type of issue is due to the system disconnecting the Bluetooth connection when the app enters the background; most likely, the app has been killed by the system when the user gets out of the car, and it has not been revived; the car key also does not work; During the time period from 2026-03-23T17:59:33 to 2026-03-23T21:23:49, why didn't carkey work properly 1：2026-03-23T16:52:11.676+08:00 new_carkey: key:, rssi:-89, AUTH_OK 2：2026-03-23T17:55:51.782+08:00 new_carkey: AppMonitor appDidEnterBackground bleStatus: success(Nimbus.NIOCarBLEKey.State.connected) 3：2026-03-23T17:59:33.747+08:00 new_carkey: ibeacon: didExitRegion, vid: NIO BLE Key, uuid: *** bleStatus: failure(Error Domain=CBErrorDomain Code=15 ""Failed to encrypt the connection, the connection has timed out unexpectedly."" UserInfo={key_device_name=NIO Key 0201 , NSLocalizedDescription=Failed to encrypt the connection, the connection has timed out unexpectedly., vehicle_id=}) " 4：2026-03-23T21:23:49.920+08:00 new_carkey: AppMonitor appDidFinishLaunching: [:] bleStatus: success(Nimbus.NIOCarBLEKey.State.disconnected) 5：2026-03-23T22:01:51.235+08:00 new_carkey: key:****, rssi:-90, AUTH_OK

I’m currently developing an iOS app that relies heavily on location details. I'm using MapKit and MKMapItem as my primary data source, which works perfectly for standard metadata. However, I’ve hit a roadblock: I want to display opening hours inline within my location details, but it seems Apple doesn't expose a public API or property for this in MKMapItem (even though the data is clearly visible in the native Apple Maps app). Since I'm building this as an indie developer/startup, the Google Places API is unfortunately too expensive for my current budget. ⁠Is there any legitimate, native way to get opening hours from Apple that I might have missed? ⁠If not, what are your best practices or recommended indie-friendly alternatives (e.g., Yelp Fusion API, OpenStreetMap, Foursquare)? Any tips on how to handle this elegantly and cost-efficiently would be highly appreciated! Thanks in advance.

I am using Significant Location Change (SLC) monitoring to relaunch my app after it has been terminated. I have implemented SLC in two separate apps installed on the same device, and I would like to understand how the system delivers SLC events in this scenario. Specifically: Will both apps receive the SLC event at the same time, or can there be differences in the timing of delivery? If there are differences, what factors influence when each app receives the event? What criteria or system conditions determine how and when SLC events are delivered to different apps on the same device? Any clarification on the event delivery behavior would be greatly appreciated.

When iterating over a CMSensorDataList (which conforms to NSFastEnumeration) returned by CoreMotion's CMSensorRecorder's accelerometerData(from:to:) method, we sometimes see the crash below, with the frame above pointing to the close brace of the for loop iterating over the list. 0 CoreMotion 0x000000019fcf01dc CLInternalGetPinnedLocationAuthorizationState + 423316 1 CoreMotion 0x000000019fcf036b CLInternalGetPinnedLocationAuthorizationState + 423715 2 CoreMotion 0x000000019fcf02cb CLInternalGetPinnedLocationAuthorizationState + 423555 3 CoreMotion 0x000000019fbb8553 CLMotionActivity::isStatic() const + 1751823 It has been incredibly difficult to reproduce. We managed to reproduce a similar crash stack twice in a separate app that misused accelerometerData(from:to:) by providing a from and to Date that were more than 12 hours apart and iterating over the returned data, but it only occurred twice in many hours of testing. We hope to know if this could be a bug in Core Motion or it is definitely in our SDK, or if there is any way to fail gracefully in this scenario.

how to tracking location service while user killed app

how to keep BG running while user killed app, because admin want to tracking inside/outside of employee

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.

I am developing an app used by public safety agencies. Part of the app is used to determine live agency staffing using geofences. For example, a geofence exists around a station, and when a user enters or exits that geofence, the app updates the staffing count at that station in real time. The issue I am having is reliably detecting when a user enters or exits the geofence while the app is killed (meaning the user force quit the app from the app launcher). I understand that iOS can relaunch an app in the background if the system terminated the process using Region Monitoring, but I haven't gotten a clear answer about whether or how this is possible if the user kills (force quits) the app. Thank you in advance for your assistance.

Situation: We have an app that only uses location UIBackgroundModes key to restart our app on significant change events as we need it to connect with a BLE device (mounted in the car) when someone starts driving. We cannot use geofence as the car might be used by multiple people so position changes and we don't want to store locations and sent them to multiple users via our servers. So currently we use significant change and just ignore all other location data. During app review we got the following feedback: If the app does not require persistent real-time location updates, please remove the "location" setting from the UIBackgroundModes key. You may wish to use the significant-change location service or the region monitoring location service if persistent real-time location updates are not required for the app features. Question: How to use the significant-change location service without the "location" setting from the UIBackgroundModes key or is there any other way to start the app / connect with the BLE device when it is fully terminated/swiped away? Because the docs state that AuthorizationStatusAuthorizedAlways is required and without the UIBackgroundModes key location that wouldn't be triggered when app is in the background/swiped away. Reference: https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW8

Hello, I’m planning to use MapKit JS for a production web/mobile application and I’m trying to better understand the quota limits and pricing model. From the documentation, I understand that MapKit JS provides a free daily limit of: 250,000 map views 25,000 service calls per Apple Developer Program membership. However, I’m not clear about what exactly happens if these limits are exceeded. My questions: If my application exceeds 250,000 map views or 25,000 service calls in a day, what happens? Will the API simply start returning errors (for example HTTP 429), or will Apple automatically charge for additional usage? Is there an official pricing model for usage above the free quota, or do we need to contact Apple to request higher limits? Are these limits strict daily hard limits that should never be exceeded in production? I’m trying to design the architecture of my application and would like to understand whether we must strictly stay below these limits or whether scaling beyond them is possible. Thank you.

I display the BackgroundLocationIndicator (blue/white bubble in status bar) in all my apps, that use background location service. Up to iOS 18 it allowed the user to tap on the bubble from within any other non fullscreen app and bring the app using the background location service to the foreground. In iOS26 this only works from the home screen. Is this intended behaviour or a bug ? If intended, please provide us with an option to allow the user to keep the pre iOS26 behavour. This was a quite convenient shortcut to jump directly to the locationservice using app.

Issue: MapKit Snapshot API returning blank dark blue images instead of satellite tiles as of March 4, 2026. This is affecting production and we need urgent assistance. Endpoint: snapshot.apple-mapkit.com/api/v1/snapshot Symptoms: HTTP 200 response with a valid image file, but image is a solid dark navy frame with only the Apple Maps watermark — no satellite data. Occasionally a correct satellite image is returned, but the vast majority are blank. Parameters: t=satellite, 640x640. Confirmed not caused by code changes (none made), auth errors or rate limiting (status is 200), or an invalid image format (image is well-formed, just blank). API keys have been rotated and the issue persists. The intermittent correct responses suggest a backend tile-serving issue on Apple's side rather than anything client-related. Started: March 4, 2026. Same requests that worked prior to this date now consistently fail. Please see the attached sample images for reference. ASAP resolution is appreciated as this is actively impacting production. Thanks, Tristan

I use MapKit and MKDirections for driving directions. The error "Directions Not Available" appears when the two points (A and B) are outside mainland China (e.g. Tokyo → Osaka). For routes inside China (e.g. Shanghai → Beijing), the same code works. let req = MKDirections.Request() req.source = MKMapItem(placemark: MKPlacemark(coordinate: origin)) req.destination = MKMapItem(placemark: MKPlacemark(coordinate: destination)) req.transportType = .automobile MKDirections(request: req).calculate { response, error in // Tokyo–Osaka (outside China): "Directions Not Available" // Shanghai–Beijing (inside China): works } Questions: Is MKDirections intended to support only routes within the device’s region (e.g. China)? When A/B are abroad, is "Directions Not Available" expected? Is this documented? For cross-country or overseas routes (e.g. Tokyo–Osaka), what is the recommended approach—third-party routing API + drawing on MapKit? Thanks.

aka MKLocalSearch.Request in Swift. Today my users reported that our address auto-complete functionality was returning strange results. We narrowed the issue down to pointOfInterestFilter being set. Sample code below: MKLocalSearchRequest *request = [[MKLocalSearchRequest alloc] init]; request.region = self.region; request.naturalLanguageQuery = addressString; request.resultTypes = MKLocalSearchResultTypeAddress; request.pointOfInterestFilter = [MKPointOfInterestFilter filterIncludingAllCategories]; That last line is the problem. When I stopped setting request.pointOfInterestFilter the MKLocalSearch started working as it always had. To further hammer home the point, with request.pointOfInterestFilter unset I set resultTypes to MKLocalSearchCompleterResultTypePointOfInterest (aka .pointOfInterest) and the issue returned. It seems Apple made a change on their backend recently such that pointOfInterestFilter now overrides resultTypes.

iOS | 26.3 specific | Google Map hangs after sharing the location to other app which open the location in new app Device: iPhone 13 Pro Max
iOS Version: iOS 26.3
Google Maps Version: 26.08.2 Steps to Reproduce: Open Google Maps. Select any location Tap Share. Share the location to another app (e.g., navigation app, co - pilot or any third party apps). Return to Google Maps. Expected Result:
Google Maps should continue functioning normally. Actual Result:
Google Maps becomes unresponsive and hangs.

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.