Environment→ ・Device: iPad 10th generation ・OS：**iOS18.3.2 I'm using AVAudioSession to record sound in my application. But I recently came to realize that when the app starts a recording session on a tablet, OS automatically sets the tablet volume to 50% and when after recording ends, it doesn't change back to the previous volume level before starting the recording. So I would like to know whether this is an OS default behavior or a bug? If it's a default behavior, I much appreciate if I can get a link to the documentation.

Environment→ ・Device: iPad 10th generation ・OS：**iOS18.3.2 We're using AVAudioPlayer to play a sound when a button is tapped. In our use case, this button can be tapped very frequently — roughly every 0.1 to 0.2 seconds. Each tap triggers the following function: var audioPlayer: AVAudioPlayer? func soundPlay(resource: String, type: String){ guard let path = Bundle.main.path(forResource: resource, ofType: type) else { return } do { audioPlayer = try AVAudioPlayer(contentsOf: URL(fileURLWithPath: path)) audioPlayer!.delegate = self try audioSession.setCategory(.playback) } catch { return } self.audioPlayer!.play() } The issue is that under high-frequency tapping (especially around 0.1–0.15s intervals), the app occasionally crashes. The crash does not occur every time, but it happens randomly — sometimes within 30 seconds, within 1 minute, or even 3 minutes of continuous tapping. Interestingly, adding a delay of 0.2 seconds between button taps seems to prevent the crash entirely. Delays shorter than 0.2 seconds (e.g.,0.15s,0.18s) still result in occasional crashes. My questions are: **Is this expected behavior from AVAudioPlayer or AVAudioSession? Could this be a known issue or a limitation in AVFoundation? Is there any documentation or guidance on handling frequent sound playback safely?** Any insights or recommendations on how to handle rapid, repeated audio playback more reliably would be appreciated.

We are building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Communication between the Angular UI and native Swift code is done using WKScriptMessageHandler. The app mostly works without issues, but in rare edge cases, we’re seeing crashes on the main thread, and the crash is reported in Firebase Crashlytics. The root cause appears related to CFRelease and WKScriptMessageHandler. Here’s the relevant crash stack: Crashed: com.apple.main-thread 0 CoreFoundation 0xbfac CFRelease + 44 1 CoreFoundation 0xa734 __CFURLDeallocate + 128 2 CoreFoundation 0x730c _CFRelease + 292 3 libobjc.A.dylib 0x4e28 AutoreleasePoolPage::releaseUntil(objc_object**) + 204 4 libobjc.A.dylib 0x4cbc objc_autoreleasePoolPop + 260 5 WebKit 0x99f194 WebKit::WebUserContentControllerProxy::didPostMessage(WTF::ObjectIdentifierGeneric<WebKit::WebPageProxyIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, WebKit::FrameInfoData&&, WTF::ObjectIdentifierGeneric<WebKit::ScriptMessageHandlerIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::CompletionHandler<void (std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::String const&)>&&) + 680 6 WebKit 0x1b358 WebKit::WebUserContentControllerProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 392 7 WebKit 0xe86b0 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 8 WebKit 0x23c0c WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 9 WebKit 0xe3f054 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 252 10 WebKit 0x332d4 IPC::Connection::dispatchIncomingMessages() + 744 11 JavaScriptCore 0x58a7c WTF::RunLoop::performWork() + 204 12 JavaScriptCore 0x599a4 WTF::RunLoop::performWork(void*) + 36 13 CoreFoundation 0x56328 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 14 CoreFoundation 0x562bc __CFRunLoopDoSource0 + 176 15 CoreFoundation 0x53dc0 __CFRunLoopDoSources0 + 244 16 CoreFoundation 0x52fbc __CFRunLoopRun + 840 17 CoreFoundation 0x52830 CFRunLoopRunSpecific + 588 18 GraphicsServices 0x11c4 GSEventRunModal + 164 19 UIKitCore 0x3d2eb0 -[UIApplication _run] + 816 20 UIKitCore 0x4815b4 UIApplicationMain + 340 21 APP1 0xa2f80 main + 21 (AppDelegate.swift:21) 22 ??? 0x1c234eec8 (シンボルが不足しています) Steps: WebView: WKWebView Message passing: WKScriptMessageHandler → passing data from Angular → Swift WKWebView is long-lived and reused Native is using WKUserContentController.add(_:name:) to register handlers Crashes are intermittent (hard to reproduce), but often follow: Screen sleep/wake Push notification open Angular calling native immediately after resume Questions: Has anyone seen this specific crash pattern involving CFRelease and WKScriptMessageHandler? Are there known WebKit or CoreFoundation bugs related to WKScriptMessageHandler and retained URLs or message content? Thank you for your help!

We’re building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Recently, we encountered a crash related to UIKeyboardStateManager in UIKit when switching between text inputs continuously within an Angular screen. Scenario The screen contains several text input fields. A “Next” button focuses the next input field programmatically. After about 61 continuous input field changes, the app crashes. It seems like this may be related to UIKit’s internal keyboard management while switching focus rapidly inside a WebView. crash stack: Crashed: com.apple.main-thread 0 WebKit 0xfbdad0 <redacted> + 236 1 UIKitCore 0x10b0548 -[UITextInteractionSelectableInputDelegate _moveToStartOfLine:withHistory:] + 96 2 UIKitCore 0xd0fb38 -[UIKBInputDelegateManager _moveToStartOfLine:withHistory:] + 188 3 UIKitCore 0xa16174 __158-[_UIKeyboardStateManager handleMoveCursorToStartOfLine:beforePublicKeyCommands:testOnly:savedHistory:force:canHandleSelectableInputDelegateCommand:keyEvent:]_block_invoke + 52 4 UIKitCore 0xa36ae4 -[_UIKeyboardStateManager performBlockWithTextInputChangesIgnoredForNonMacOS:] + 48 5 UIKitCore 0xa160f0 -[_UIKeyboardStateManager handleMoveCursorToStartOfLine:beforePublicKeyCommands:testOnly:savedHistory:force:canHandleSelectableInputDelegateCommand:keyEvent:] + 440 6 UIKitCore 0xa07010 -[_UIKeyboardStateManager handleKeyCommand:repeatOkay:options:] + 5760 7 UIKitCore 0xa2fb64 -[_UIKeyboardStateManager _handleKeyCommandCommon:options:] + 76 8 UIKitCore 0xa2fb08 -[_UIKeyboardStateManager _handleKeyCommand:] + 20 9 UIKitCore 0xa30684 -[_UIKeyboardStateManager handleKeyEvent:executionContext:] + 2464 10 UIKitCore 0xa2f95c __42-[_UIKeyboardStateManager handleKeyEvent:]_block_invoke + 40 11 UIKitCore 0x4b9460 -[UIKeyboardTaskEntry execute:] + 208 12 UIKitCore 0x4b92f4 -[UIKeyboardTaskQueue continueExecutionOnMainThread] + 356 13 UIKitCore 0x4b8be0 -[UIKeyboardTaskQueue addTask:breadcrumb:] + 120 14 UIKitCore 0x4a9ed0 -[_UIKeyboardStateManager _setupDelegate:delegateSame:hardwareKeyboardStateChanged:endingInputSessionIdentifier:force:delayEndInputSession:] + 3388 15 UIKitCore 0xfa290 -[_UIKeyboardStateManager setDelegate:force:delayEndInputSession:] + 628 16 UIKitCore 0xf617c -[UIKeyboardSceneDelegate _reloadInputViewsForKeyWindowSceneResponder:force:fromBecomeFirstResponder:] + 1140 17 UIKitCore 0xf5c88 -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] + 88 18 UIKitCore 0x4fe4ac -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] + 84 19 WebKit 0xfbe708 <redacted> + 100 20 WebKit 0xfbf594 <redacted> + 340 21 WebKit 0x8a33d8 <redacted> + 32 22 WebKit 0x8cee04 <redacted> + 144 23 WebKit 0x1c83f0 <redacted> + 22692 24 WebKit 0x73f40 <redacted> + 264 25 WebKit 0x162c7c <redacted> + 40 26 WebKit 0x1623b4 <redacted> + 1608 27 WebKit 0x73298 <redacted> + 268 28 WebKit 0x72e48 <redacted> + 660 29 JavaScriptCore 0xdb00 WTF::RunLoop::performWork() + 524 30 JavaScriptCore 0xd744 WTF::RunLoop::performWork(void*) + 36 31 CoreFoundation 0xf92c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 32 CoreFoundation 0xf744 __CFRunLoopDoSource0 + 172 33 CoreFoundation 0xf5a0 __CFRunLoopDoSources0 + 232 34 CoreFoundation 0xff20 __CFRunLoopRun + 840 35 CoreFoundation 0x11adc CFRunLoopRunSpecific + 572 36 GraphicsServices 0x1454 GSEventRunModal + 168 37 UIKitCore 0x135274 -[UIApplication _run] + 816 38 UIKitCore 0x100a28 UIApplicationMain + 336 39 APP1 0xa2ed0 main + 21 (AppDelegate.swift:21) 40 ??? 0x1aa889f08 (シンボルが不足しています) From reviewing the crash log, it appears that the crash occurs inside UIKeyboardStateManager while handling keyboard or cursor updates. Questions Has anyone seen this specific crash pattern involving UIKeyboardStateManager? Are there known UIKit or WebKit bugs related to UIKeyboardStateManager when continuously changing focus between text fields (especially in WKWebView)? Any insights or workarounds would be greatly appreciated. Thanks!

We have a login flow where the user authenticates in Safari, and at the end of the process the authentication server redirects back to our app using a Universal Link. On most devices, the app opens automatically without any confirmation banner. However, on several iPads, Safari always shows the “Open App A?” banner after the redirect. The user must tap Open every time. Other devices running the same iOS version do not show this issue. Expected Flow (working devices): Start authentication Safari login Authentication server redirects using a Universal Link App A opens automatically Problematic Flow (several iPads): Start authentication Safari login Authentication server redirects using a Universal Link Safari shows “Open App A?” confirmation banner User must tap Open App A starts Questions: Is this a known issue in iOS? Or is this expected behavior under certain conditions (i.e., is there a specific Safari/iOS specification that causes this banner to appear)? Is there any way to prevent Safari from showing the “Open App A?” banner and allow automatic redirection? ＊This issue did not occur on iOS 16, but it started appearing after updating to iOS 17. Devices : iPad 9th Gen/iPad 10th Gen