Our current business goal is to improve the success rate of iBeacon wake-up on iOS. Apple's official iBeacon specification recommends a standard broadcast interval of 100ms; Now we are planning to shorten the broadcast frequency to 50ms, and we would like to consult the full dimensional impact of this change, and whether it can really improve the success rate of beacon identification and pull trigger on iOS devices.

We're using the iOS ibeacon APIs to wake up our app for vehicle bluetooth key and to enable the seamless walk-away features; Does the Measured Power value in the advertising packet affect an app’s background launch? If so, what is the mechanism? If not, what is the actual purpose of this field in Core Location? For different beacon devices/vehicle models, does this value need to be adjusted? For example, we have different vehicle models – should each model set this value based on actual calibration data? Our current understanding: Measured Power is typically used for our APP to do the distance estimation but we are not sure whether the system also uses it as a weighting factor for background wake‑ups or region triggers. We have noticed some discussions in forums about similar scenarios where it is mentioned that Measured Power needs to be set correctly.

Hello AD Forums, I am a member of the ADP and am working on an iOS app for the App Store. My app needs to match the user’s current location to one of Germany’s 400 district-level administrative areas: Landkreise and kreisfreie Städte. In Firebase, each region has a geoTagName field. The app compares the detected location name against this geoTagName to load the correct internal region document. I need to understand the recommended Apple/Core Location field for this use case. My current understanding is: CLPlacemark.administrativeArea usually represents the federal state in Germany, for example “Thüringen” or “Bayern”. CLPlacemark.locality usually represents the city, municipality, or town. CLPlacemark.subAdministrativeArea seems to be the most likely candidate for the German Landkreis / kreisfreie Stadt level. However, I need to know whether CLPlacemark.subAdministrativeArea is the correct and reliable field for identifying German Landkreise and kreisfreie Städte. I also tested Apple Maps Server API /v1/reverseGeocode. For district-level locations in Germany, it often returns values such as: administrativeArea: Thüringen locality: Bad Sulza but no value such as: subAdministrativeArea: Weimarer Land Example coordinate tested: 50.9957525, 11.5129989 My questions are: Is CLPlacemark.subAdministrativeArea the recommended field to identify German Landkreise and kreisfreie Städte in an iOS app? Are there known differences between iOS CLGeocoder.reverseGeocodeLocation and Apple Maps Server API /v1/reverseGeocode regarding subAdministrativeArea? Does Apple provide any official list, dataset, or recommended validation method for the exact district-level names used by Core Location / Apple Maps in Germany? How should an app distinguish cases where a kreisfreie Stadt and a Landkreis have the same name, for example: Stadt Augsburg Landkreis Augsburg Stadt Ansbach Landkreis Ansbach Stadt Aschaffenburg Landkreis Aschaffenburg Should administrativeArea be avoided for this use case because it represents the federal state level in Germany? The goal is to create reliable matching between the Apple/Core Location result and our Firebase geoTagName values. Thank you.

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?

Hello, I would like to consult Apple’s technical team regarding how different iBeacon Bluetooth advertising packet configurations impact iOS app background wake-up performance. My specific questions are outlined below: We have two available iBeacon advertising configuration schemes: Scheme 1: Encapsulate the non-connectable iBeacon advertising payload and connectable Bluetooth advertising payload into a single advertising packet for transmission. Scheme 2: Split the two types of advertising payloads above into two separate independent advertising packets and broadcast them respectively. Could you please clarify which packet format enables iOS apps to detect and recognize iBeacon devices more reliably and easily, thereby triggering app background wake-up more effectively? I would appreciate it if you could explain the differences, advantages and disadvantages of these two schemes under iOS’s Bluetooth scanning and app wake-up mechanisms, as well as provide your official recommendations. Thank you very much for your assistance.

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. Feedback Assistant reports have been submitted with sysdiagnose attached. Has anyone seen similar CoreLocation / GeoServices behavior where Wi-Fi scans succeed but knownCount always remains 0 and no location fix is generated? Feedback ID: FB23196632

WeatherKit never returns data for my app. Both the on-device API and the REST API fail at the authentication layer, which points to WeatherKit not being enabled at the backend for my team. On-device: WeatherService.shared.weather(for:including:.current) throws WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 on a real device, every time. REST API: I created a WeatherKit key and called the REST endpoints directly from my Mac (bypassing the app and the device entirely). Both return HTTP 401 {"reason":"NOT_ENABLED"}: GET https://weatherkit.apple.com/api/v1/weather/en/37.5665/126.978?dataSets=currentWeather GET https://weatherkit.apple.com/api/v1/availability/37.5665/126.978?country=KR Identifiers: Team ID: 5L3SCT446M App ID: com.saebom.weathergal (widget: com.saebom.weathergal.widget) WeatherKit REST Key ID: 2BGXGVFDX6 Everything on my side is verified correct: com.apple.developer.weatherkit entitlement is present in the signed binary AND in the embedded App Store provisioning profile (verified via codesign and by decoding the .mobileprovision). WeatherKit is enabled under App Services for the App ID. Apple Developer Program License Agreement accepted; Paid/Free Apps Agreements active. The WeatherKit Usage dashboard shows 0 of 500,000 calls used (the request never authenticates). I toggled the WeatherKit capability off/on and regenerated provisioning profiles; no change after several days. Likely cause: the WeatherKit capability was first enabled on 2026-06-09, while the updated Developer Program License Agreement (issued 2026-06-09) was not accepted until 2026-06-11. The backend WeatherKit token registration appears to have gotten stuck because it was created while the agreement was still pending. Could the WeatherKit/DTS team please verify and re-sync the backend WeatherKit token registration for Team ID 5L3SCT446M? I already filed FB23197482 with the same details. Thank you.

I’m developing a sandboxed macOS app with a Quick Look extension that previews user-selected files. The preview includes an interactive MapKit map showing the route from the file During TestFlight review, Apple rejected temporary entitlement exceptions for: com.apple.security.temporary-exception.files.home-relative-path.read-only /Library/Caches/GeoServices/ com.apple.security.temporary-exception.mach-lookup.global-name com.apple.geoanalyticsd I understand these temporary exceptions are not appropriate for Mac App Store distribution and will remove them. What is the supported sandbox-compliant way to use MapKit inside a macOS Quick Look extension? Should an interactive MapKit view work inside a sandboxed Quick Look extension without temporary exceptions, or is MapKit unsupported in this extension context? If interactive MapKit is not supported, is MKMapSnapshotter the recommended alternative, or should the extension render a route-only preview without Apple map tiles? Any guidance on the expected entitlement/capability setup for this scenario would be appreciated.

I'm creating an APP for the first time in Xcode, I have a part of a place search on a map, it has a card very similar to the iPhone map card, I want it to move to the left when it's horizontal and position itself there to see the information that slides up and down. What should I write in the code?

I generated an Apple Maps API key and Server API test token via Maps services, and checked it has a valid header and payload with jwt. Ive also generated a valid token with my AuthKey_.p8 file via PyJWT, however, I continue to get 401 error returned from my local server when trying to test hitting https://maps-api.apple.com/v1/api/searchAutocomplete?....

Hi, I'm working on a trip detection and recording app that relies on CLLiveLocationUpdates for the location tracking. We've observed a recurring issue where trip recording eventually stops working if the app is not opened for an extended period of time (approximately 2–3 weeks). What we observe The app continues to be installed on the device. The user does not manually open the app during this period. Eventually, trip detection and recording stop. Location diagnostics indicate: Service Session Required At this point, CLLiveLocationUpdates no longer appears to deliver location events. Recovery attempts We've tried several ways to recover without launching the app: Turning Location Services off/on Rebooting the device Changing location permissions None of these restore location updates. The only reliable recovery method we've found is: Open the app manually. Leave it running for some time. Kill the app again. After doing this, location tracking resumes and works normally for 4-5 days before eventually failing again with the same "Service Session Required" diagnostic. Questions Why would a valid location setup eventually transition into a "Service Session Required" state after the app has not been launched for several weeks? Are there any documented conditions under which an existing CLServiceSession expires, becomes invalid, or requires recreation? Is there a recommended way to recover from this state programmatically without requiring the user to manually launch the app? Is this expected behavior or a potential issue with CLLiveLocationUpdates / CLServiceSession? Additional details iOS version: 26 App uses: CLLiveLocationUpdates, Beacon Ranging & Beacon Monitoring, SLC updates, Motion Activity Updates Background location enabled: Yes Authorization type: Always Device models tested: iPhone 14 Pro Max Service session creation code: private var serviceSession: CLServiceSession? serviceSession = CLServiceSession( authorization: .always, fullAccuracyPurposeKey: "Trip" ) Has anyone else encountered a similar issue after long periods where the app is not launched? Thanks.

Hello, I am currently working with the Nearby Interaction framework on iOS and exploring the capabilities of UWB-based communication. I would like to ask whether Nearby Interaction supports multicast communication over UWB. Specifically, is it possible for one device to interact simultaneously with multiple peer devices using UWB (e.g., broadcasting ranging or spatial information to multiple devices at once), or is the framework strictly limited to one-to-one peer interactions? If multicast is not supported, are there any recommended approaches or best practices for achieving similar functionality using the current APIs? Thank you for your help. Best regards,

Dear Apple Developer Support Team, We are experiencing a crash in our iOS application that appears to originate within Apple's MapKit/VectorKit framework. Based on the crash logs, the failure occurs during map rendering operations inside VectorKit. The crash stack contains only Apple framework calls and does not include any application business logic methods. Crash Summary: Exception Type: NSMallocException Framework: MapKit / VectorKit Crash Location: VectorKit map rendering pipeline Observed Behavior: Application crashes while rendering map-related data Our analysis indicates that the crash occurs within Apple's native map rendering engine. Since the stack trace does not contain any application-specific code, we are unable to determine whether the issue is caused by framework behavior, an OS/device-specific condition, or a framework-level defect. We would appreciate your assistance in reviewing this issue and advising whether there are any known MapKit/VectorKit issues related to this crash signature. We can provide additional crash logs, device details, and reproduction information if required. Thank you for your support. Kind Regards, Yogesh Raj Ushyaku Software Solutions LLP

Native WeatherKit fails for our app on both development and TestFlight distribution builds, with the WeatherKit service enabled. Team ID: YCF2TGZAX8 Bundle ID: org.walktalkmeditate.pilgrim Call: try await WeatherKit.WeatherService.shared.weather(for: location, including: .current) Error (immediate, every call): Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" What we've verified: WeatherKit enabled under BOTH the Capabilities tab AND the App Services tab for this App ID. com.apple.developer.weatherkit entitlement confirmed in the signed binary (codesign -d --entitlements). Fails identically on (a) Xcode-direct development builds and (b) TestFlight distribution builds. Physical device (iPhone SE 3rd gen) signed into iCloud / an Apple Account. Survives app delete + reinstall AND a device reboot, on both build types. GPS/CoreLocation works fine; only WeatherKit auth fails. Not a timeout or rate-limit. First appeared on Xcode 26 beta; never resolved on stable Xcode 26.3 (17C529), iOS 18.x. This matches the pattern in threads 786126, 810137, 811225, and 789900, where the WeatherKit auth backend hasn't registered/synced the bundle ID for JWT issuance even with App Services on, and Apple resolves it server-side. Could someone check the backend WeatherKit registration for org.walktalkmeditate.pilgrim? Happy to provide a sysdiagnose. Will also file a Feedback report and add the FB number here.

Regarding significant locations, how long does it take for an iOS device to learn locations? We've done some testing and when we turned on stolen device protection and try to turn it off, it activated the security delay with significant locations on.

Why do I receive MKErrorDirectionsNotFound for transit directions even though the Maps app does provide transit directions for the same source/destination pair? Other transport types such as driving or walking return results just fine.

I'm facing a persistent location error on real iOS device: Error Domain=kCLErrorDomain Code=1 The operation couldn’t be completed. (kCLErrorDomain error 1.)

I have use cases where I want to specifically query against postal address and other properties that existed on CLPlacemark. With the new address type those are not exposed there. It might be contained in the text, so general string token searching is fine, but my data model saves postal code as an individually queryable component in my Swift Data model. FB16064707 FB20007974 FB20008112

It seems that with the latest update ellipsoidalAltitude of the CLLocation is always 0.0 where it had the correct value before. Also, velocity used to be -1 when not moving. The regular altitude still has sensible values. Did anybody else experience this ? Rgds Lob

I use location a lot in my app, and I've found that if the user moves far away (i.e. on vacation to a different country), the app shows a permission popup asking the user if they really want to keep location permission as always soon after. I've also found that providing some message from the app (i.e. in notifications) helps a lot more than what I can put on the permission popup to remind the user what this permission is used for, and helps my users make more informed decisions when they are asked about the location permission. Is there any best practices or heuristics I can use to decide when to show this notification? I just have some pretty simple logic in my app today, but would love to be able to provide a better experience.