As per the Suggestion, Created CLBackgroundActivitySession and CLServiceSession in foreground to keep Core Location active. Recreated those sessions on background launch/APNS. Persisted and restored fence definitions so CLMonitor can re‑register fences after background launch. But the restore only re‑registers fences that were already created before. If a fence is first created while the app is terminated and only launched in background, CLMonitor did not deliver the initial “enter” until a foreground session exists. Comparision with old CLLocationManager region monitoring: Old API (CLLocationManager region monitoring) is system‑managed. The OS keeps monitoring even when your app is terminated, and it can accept new region registrations in background because that API was designed around long‑standing background delivery. New API (CLMonitor with CLBackgroundActivitySession/CLServiceSession) is session‑based. Apple expects the session to be created in foreground and then restored in background. It’s optimized for power and privacy, so first‑time background registration is not guaranteed; the system can defer or suppress events until the app has foreground‑initiated sessions. Is there a modern API that reproduces the legacy CLLocationManager behavior of triggering an initial state event (Entry/Exit) while the app is in the background

Hi Is this issue resolved. We are facing similar issue when we started using DeclaredAgeRange Framework .

How are you doing this? The audio system should not be allowing PlayAndRecord to directly activate in a background app. For Notification Tones Audio session category is configured to AVAudioSessionCategoryPlayAndRecord with VoiceChat mode and AllowBluetooth option Tones play using system audio services without an active audio session No background audio session activation occurs for notification tones

Application is using AVAudioSessionCategoryPlayAndRecord category and AVAudioSessionCategoryOptionAllowBluetooth Option to play the Notification tone. But as per the Apple documentation AVAudioSessionCategoryOptionAllowBluetooth Option is Deprecated and the Document suggests to use AVAudioSessionCategoryOptionAllowBluetoothHFP as alternative. But AVAudioSessionCategoryOptionAllowBluetoothHFP Option is not defined in AVAudioSessionCategoryOptions Is there any option to use as alternative of AVAudioSessionCategoryOptionAllowBluetooth option?

Xcode Version 26.2 beta 2 (17C5038g) iOS Version 26.2 (23C5044b) do { let response = try await AgeRangeService.shared.isEligibleForAgeFeatures // Handle response if response { print("Eligible for age features") } else { print("Not eligible for age features") } } catch AgeRangeService.Error.notAvailable { print("isEligibleForAgeFeatures not available error") } catch { print("isEligibleForAgeFeatures Unhandled error: \(error)") } The above code snippet gets hang at the API call isEligibleForAgeFeatures could you please suggest what is wrong here

we did went through the following WWDC video https://developer.apple.com/videos/play/wwdc2025/299/ and it is mentioned that Users can manage the cached responses in settings. We did not see any such settings, not even under the sandbox account "Test Age Assurance". Could you please let us know how do we clear the cached age response

Following feedback submitted for the same - https://feedbackassistant.apple.com/feedback/21097477

Can we achieve playing notification tones through an accessory using HFP profile using an SCO connection on iOS

Thank you for the clear explanation. We must emphasize that, as a Mission critical Push-to-Talk (PTT) application, the perceived volume and clarity of the audio are fundamental user requirements. We currently achieve the necessary amplification and clarity using a custom PCM gain factor. Therefore, the ability for our application to apply a specific gain factor to PCM samples for amplification is essential. Could you please advise on which framework or API Apple recommends for a third-party application to intercept and process the audio stream—specifically, to apply a GAIN factor to PCM samples—during an active CallKit call?

The BLE Peripheral advertising interval is set at a range of 20ms - 40ms.

Issue resolved when presenting the CameraViewController over the root view controller with `UIModalPresentationStyle.fullScreen'. It introduced a new problem: the title color is now black, and the parent view controller's background color needs to be black, making the title unreadable. I have already tried setting tintColor and titleTextAttributes for the UIVideoEditorController's navigation bar, but these did not resolve the issue. Setting the background color for the UIVideoEditorController's navigation bar also does not seem to be a suitable solution, as demonstrated in the attached video. Please refer the sample application for more details in the feedback: FB19754948

The newly uploaded logs in the feedback contain the relevant information regarding the issue. Please disregard the earlier uploaded logs.

[quote='856777022, DTS Engineer, /thread/797563?answerId=856777022#856777022'] Expanding on that, there isn't really any reason for your app to delay anything based on providerDidBegin. Just start using the provider and everything will work fine. [/quote] Without this check in one of the earlier case CallKit session went into a bad state and there was no recovery for the CallKit session until swipe kill(we don't have the logs now for the instance). Anyway, removed this check and proceeding to report to CallKit without providerDidBegin(_:) check. Will update here if any issues observed. Thanks

Yes as mentioned earlier, CallKit gets initialised is in Main queue (the mentioned code init is happening in main queue) [quote='856460022, DTS Engineer, /thread/797563?answerId=856460022#856460022'] That's the queue you're targeting, but is that code also running on the main queue? [/quote] As you suggested,we have now initialised PushKit on the main queue. We are currently monitoring the issue since it is not consistently reproducible. Since the issue is not consistent we are monitoring this issue. I'm still not entirely convinced that initialising PushKit on a secondary queue might led the root cause of this problem. As per Feedback analysis: The user launched the application at [07/31 15:04:45:858]*******{}BEGIN LOGGING{}***** Here user has put app to background [07/31 15:20:41:695][ 0x105147e80]<ALA_SIGNAL>: [OS-PLT] -[AppDelegate applicationDidEnterBackground:] and then received an VoIP APNS and it got crashed, [07/31 15:20:55:639][ 0x122c53680] [Pushnotif] [] <ALA_SIGNAL>: [OS-CCF] Enter -[PushNotificationManager pushRegistry:didReceiveIncomingPushWithPayload:forType:withCompletionHandler:] and did not receive a callback for approximately 15 minutes of the entire app session. so does really initialising PushKit on a secondary queue is the primary concern for this issue?

Yes we did try requesting connectPeripheral() command on receiving disconnect callback but there is one use-case where the behaviour was wrong. Application has issued connectPeripheral() command and is connected with the LE device. User will go and chose "Forget the device " under bluetooth settings. Application will receive didDisconnectPeripheral and because of connectPeripheral() command , it was connecting back again to BLE which was NOT the user wanted Since we saw the above behaviour which will be annoying to user , then we tried scanForPeripheralsWithServices() command with the serviceUUIDs we are interested in. When we use this command is when we saw an issue where our application was not receiving didDiscoverPeripheral() delegate which we were expecting. We did receive didDiscoverPeripheral() delegate the moment we bring our application into foreground