Hi all, Our company is applying for the Find My certification for our smartwearable product. Now we submitted the product plan and it's approved. The lab asked us to get the token but we searched on internet and the documents about it are limited. The CSR has approved and we already had .pem and .key file. I wonder what should we do next. Any helps are appreciated

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.

Does DL-TDoA ranging in the Nearby Interaction framework support building a traditional RTLS-style TDoA localization system, where a device’s absolute position is computed from time-difference measurements across multiple deployed anchors, or is DL-TDoA strictly limited to system-managed, relative ranging and direction estimation (distance/direction) between nearby devices? If DL-TDoA ranging in Nearby Interaction is not intended to support traditional RTLS-style TDoA localization, is there any public documentation or reference material that describes the intended DL-TDoA architecture, such as the expected system setup, device roles, and deployment constraints (for example, how ranging is expected to be performed between an iPhone and nearby accessories), beyond the high-level API documentation? Regards.

As title says. Surely rendering bitmaps is something the hardware could handle, right? Please enable MKTileOverlay for watchOS.

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.

I’m hitting a specific edge case with background execution that I can’t figure out. I'm using Flutter for the UI, but all the logic handles are in Swift using CoreBluetooth and CoreLocation. I need the app to wake up from a suspended state when it detects my specific BLE peripheral (OBD sensor), connect to it, and immediately start continuous location tracking for the duration of the drive. If I start this process while the app is in the foreground, or very shortly after going to BG, it works perfectly. The app stays alive for the whole trip. The issue only happens when the sequence starts from the background: The app is suspended. scanForPeripherals wakes the app when the sensor is found. In didDiscover, I immediately call locationManager.startUpdatingLocation(). locationd actually delivers updates successfully. However, 5-15 minutes later, iOS suspends the app again. Crucially, I never see the blue "Location In Use" pill on the status bar, even though I have showsBackgroundLocationIndicator = true set. Also, distance filter is set to None. Logs for reference (around suspending) locationd: {"msg":"Sending location to client","Client":"[appName]:","desiredAccuracy":"-1.000000"} runningboardd: Invalidating assertion ... from originator \\\[osservice<com.apple.bluetoothd>:...\\\] runningboardd: Removed last relative-start-date-defining assertion for process app<[appName]...> runningboardd: Calculated state ... running-suspended runningboardd: Suspending task locationd: Client [appName]: disconnected bluetoothd: State of application "[appName]" is now "suspended" Questions Why does invalidating the Bluetooth assertion cause an immediate suspend even though I called startUpdatingLocation() and am receiving updates? Does the missing blue location pill imply that the OS never fully "accepted" the location session? Is there a specific "handshake" required to transition from a BLE wake-up to a long-running location session? I'm wondering if I need to use a background task identifier to bridge the gap between the BLE wake and the location manager taking over. More context: Digging deeper in the comments, I just noticed the following patterns when the application is not suspended vs when it is recently suspended and got awaken by a BLE event. Not suspended: 303948:Jan 23 20:59:35.640118 locationd[6491] <Debug>: {"msg":"Client is setting ContinuousBackgroundLocationRequested", "Client":"[appName]:", "ContinuousBackgroundLocationRequested":1} 303949:Jan 23 20:59:35.640155 locationd[6491] <Debug>: {"msg":"Allowing process assertion due to foreground-ish status", "ClientKeyPath":"[appName]:"} Recently suspended and awaken by BLE: 564296:Jan 23 21:00:23.179125 locationd[6491] <Debug>: {"msg":"Client is setting ContinuousBackgroundLocationRequested", "Client":"[appName]:", "ContinuousBackgroundLocationRequested":1} 564298:Jan 23 21:00:23.179195 locationd[6491] <Notice>: {"msg":"#Warning Denying process assertion", "ClientKeyPath":"[appName]:"} The assertion fails for the second case and that's why the app could not persist. Most importantly, following the logs in the second case, I see the following: locationd[6491] <Notice>: {"msg":"computing freshAuthorizationContext", "Client":"[appName]:", "ClientDictionary":"{\n AlwaysServiceSession = 0;\n I suspect that the flag AlwaysServiceSession being 0 has to do with process assertion being denied for location.

I want to update coordinate of the lookaround instance object. But mapkit.js does not have LookAroundSceneRequest class, how am I going to do. In swift, there is MKLookAroundSceneRequest class, you can specify a new coordinate with this class, to get a new LookAroundScene object, then attach new LookAroundScene to the existing lookAround object, But how am I going to do the same with mapkit.js ?? it missing LookAroundSceneRequest class in js

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()