"We are developing an application use case that requires us to prompt the user to restart their device. We plan to use the system uptime value provided by [NSProcessInfo processInfo].systemUptime to determine if a restart has occurred. Apple's documentation defines this API as 'The amount of time the system has been awake since the last time it was restarted.' Our questions are: Can we reliably use this API, in conjunction with persistent storage, to detect a device restart? Are there any known limitations or considerations when accessing or relying on this API while the application is running in the background?"

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.

Let the device is in locked screen Get incoming APNS video request to start video recording we are reporting this APNS to Callkit Accept incoming APNS request We are trying to initialise audio unit. Initialisation is success but starting is failing. Note - This issue is reproduced only if we receive video pull request in locked screen, after accepting callkit call we should not unlock the phone. If we unlock phone everything works as expected.

There consistent build failure in Xcode Beta 26.0 (Build 24112) on a project targeting iOS. The build process fails with an error indicating that the actool utility is unable to decode its own version information, leading to the overall build failure. error: Failed to decode version info for '/Applications/Xcode26.0.app/Contents/Developer/usr/bin/actool': The data couldn’t be read because it is missing. Feedback: FB19969269

Steps To reproduce: Login to application and App has joined the PTC channel. Push the application to background and Lock the device. From the System UI press the talk button which will start transmit. Audio Session has been activated and Audio unit has been initialised properly. On terminator side no media is being played out. Issue observed consistently on specific models which has configured audio codec with Stereo type. More details are added : FB20281626

Application is in foreground state, When a user receives a cellular call and it is in the "ringing" state and application receives a VoIP APNS(video call) which is reported to CallKit. User rejects the Cellular call from CallKit UI, application Video call is also getting rejected (separate feedback - 19017978) and Here the issue is observed that an Application moved to background. Issue is not observed in iOS 18 and older versions. Issue observed only with UISceneDelegate changes. Using traditional UIApplicationDelegate doesn't have the issues. Video and Sysdiagnose logs are added in feedback: FB20187309

When an iOS device is connected to a Bluetooth accessory that utilizes the Hands-Free Profile (HFP), we are encountering an incorrect audio routing behavior specifically for system notification tones. Accessory Connected: The iOS device is successfully connected to a Bluetooth accessory (specifically, a WM500 device) using the HFP profile for voice communication. Voice Audio: Audio streams related to phone calls or voice communication (using the HFP/SCO link) are correctly routed to the WM500. Notification Tones Issue: System notification tones, which are played using the tonetype.systemsounds API, are not being routed to the connected HFP accessory (WM500). Instead, they are incorrectly played through the iOS device's built-in speaker. This causes a poor user experience, as critical application alerts and system notifications are missed when the user is relying on the connected HFP accessory for all audio output.

When an iOS device is connected to a Bluetooth accessory that utilizes the Hands-Free Profile (HFP), we are encountering an incorrect audio routing behavior specifically for system notification tones. Accessory Connected: The iOS device is successfully connected to a Bluetooth accessory (specifically, a WM500 device) using the HFP profile for voice communication. Voice Audio: Audio streams related to phone calls or voice communication (using the HFP/SCO link) are correctly routed to the WM500. Notification Tones Issue: System notification tones, which are played using the tonetype.systemsounds API, are not being routed to the connected HFP accessory (WM500). Instead, they are incorrectly played through the iOS device's built-in speaker. Accessory team has suggested to establish SCO connection to route the tones through WM500. But iOS does not provide an external API (like Android's startBluetoothSco) to explicitly force the establishment of an SCO connection for notification tones. Is there any other approach to establish SCO connection in iOS to route notification tones through WM500

Share Age Range Permission is set to 'Ask First'. Application requested for AgeRange via requestAgeRange API. System presented a consent window where user has to make a choice. User did not acted. Application was pushed to background. Our Application supports PushToTalk Framework and we have successfully joined the channel already. User tapped on the blue-pill , SystemUI will get presented. User tapped on the SystemUI, A New Full Screen SystemUI will get presented. User chosen 'Leave' option and our application left the active channel. 10 User brought the application to foreground and the previous "Share Age Range" system window disappeared. 11. After Step 10, We need to terminate and launch our application in order to get the "Share Age Range" system window. Is "Share Age Range" system window getting disappear is expected here or a BUG

Facing an issue with audio playback using AVPlayerViewController in iOS application. We are using the native player to play recorded audio files. When the AVPlayerViewController appears, the native user interface is displayed correctly, including the playback controls and the volume slider. However, when the user interacts with the volume slider The slider UI moves and responds to touch events. The actual audio output volume does not change. The audio continues playing at the initial volume level regardless of the slider position. We initialize the player and present it modally using the following code: AVPlayerViewController *avController = [[AVPlayerViewController alloc] init]; avController.player = [AVPlayer playerWithURL:videoURL]; // Setting initial volume avController.player.volume = 1.0f; avController.modalPresentationStyle = UIModalPresentationOverFullScreen; avController.allowsPictureInPicturePlayback = NO; // Present the controller [self presentViewController:avController animated:YES completion:nil];