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 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,

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.

Hi- I've never posted on here before! But ChatGPT hasn't been helpful with this. I have a call using MKLocalSearch (i have a waddled down version below) let region = MKCoordinateRegion( center: location, // the user's location span: MKCoordinateSpan( latitudeDelta: 0.005, longitudeDelta: 0.005 ) ) let req = MKLocalPointsOfInterestRequest(coordinateRegion: region) req.pointOfInterestFilter = MKPointOfInterestFilter(including: [.nightlife]) let search = MKLocalSearch(request: req) I made the latitude and longitude the lowest they can possibly be without throwing an error. Sometimes (and unreliably) when the user's location is at say, a bar, this list will give me like 10 bars that are not even within the region, and exclude the bar that the user is actually present in. How can i make this not the case? In other words, I just want this to return what I expect: a list of POIs with the category .nightLife within the defined region. Any help would be appreciated!

We have developed an iPad application using the ARCL (AR + CoreLocation) library to render Point of Interest (POI) annotations in both an AR view and a standard MapView. The application performs as expected on standard devices. However, we have some iPad covered with strong magnet. This creates significant magnetic interference, resulting in a 90° to 180° heading offset, rendering the AR POI placement and MapView orientation unusable. Technical Challenges & Constraints: Hardware Lock: The magnetic cover is a mandatory business requirement and cannot be removed during field use. Sensor Failure: The internal magnetometer cannot provide an accurate North reference due to the proximity of the cover’s magnets. While CoreLocation and CoreMotion use sensor fusion, the magnetometer remains the primary source for absolute heading. Alternative Orientation Tracking: Is there a documented method to bypass the magnetometer and derive device orientation using only the Gyroscope and Accelerometer (e.g., relative tracking) while still maintaining alignment with geographic coordinates in CoreLocation? Programmatic Offsets: Are there known APIs or mathematical workarounds to programmatically "nullify" or offset a constant magnetic bias once the device is inside the cover? so we can use that offset for ARView and in Mapview as well.

With iOS 26 deprecations around MKPlacemark, MKGeocodingRequest + MKMapItem is the migration path for forward geocoding. However, geocoding results don’t expose a canonical region/bounding region for the result set (similar to MKLocalSearch.Response.boundingRegion). Any idea how to mitigate this?

Hello, We are trying to understand the requirements for surfacing an action button on an Apple Maps place card for a POI. We created an Advanced App Clip Experience, associated it with a specific Maps location, and the location is marked as Matched. The experience status is green and marked Received. However, the main issue is that no action button appears on the Apple Maps place card for that POI. We do not see any button such as Order, Support, Reserve, Call, or any custom App Clip entry point. At this point, the issue is not only whether the App Clip launches correctly. The issue is that there is no visible Maps button for the user to tap in the first place. Could you please clarify: Does Matched + Received mean the App Clip is eligible to appear on the Maps place card, or does it only mean the association was accepted? What exact conditions must be met for an action button to appear on a POI in Apple Maps? Is button visibility controlled by the Advanced App Clip Experience configuration, the POI category, Apple Maps ranking/eligibility logic, Apple Business Connect, or a separate Maps partner integration? Are action buttons such as Order, Support, or Reserve available to standard Advanced App Clip Experiences, or only to approved Maps/Business Connect partners? If a business has authorized us to provide this experience for their listing, what is the correct process to make the action button visible on that POI? Is there any way to confirm whether a specific matched POI is eligible or ineligible for Maps place-card button surfacing? We want to understand the exact path from: Advanced App Clip Experience created → POI matched → status received → action button visible on Apple Maps place card. Right now we are stuck between “Received” in App Store Connect and no visible button in Maps, and the documentation does not clearly explain what gating step is missing. Related issue: FB23044674 (App Clip does not show up on Maps)

The Maps app exhibits a sophisticated blur effect behind the status bar: map content (labels, POI icons) is hidden map background (roads, buildings) is slightly blurred Can I achieve this effect in MKMapView, too? Just putting a UIVisualEffectView on top doesn't achieve the same effect since it also blurs the labels.

I am currently using Core location to get user's current location and few surrounding coordinates to draw annotations in Augmented reality. It works best on Cellular network and on Wifi network few times it is working ok and sometimes orientation is completely changed when device is connected to WiFi. Checked on Apple map as well, there itself it was giving wrong orientation and even after user is at same location, current location on map got fluctuating. On WiFi only models GPS accuracy is not good.