I was in the webview long according to the pictures, and then select "save image" will lead to collapse, I have passed on the info plist add NSPhotoLibraryAddUsageDescription solved it. Now I have another question, does the last item "query" in the screenshot have a similar problem? Since I couldn't click the button (I don't know why this happened), I couldn't test it on the real machine.

Hello, I'm encountering a persistent issue when building my project with Xcode 26 and iOS 26. The console shows errors related to font file references that don't actually exist in my project. GSFont: file doesn't exist - "file:///private/var/containers/Bundle/Application/...../HiraginoKakuGothic.ttc" After investigation, I found that the issue originates from XIB files incorrectly referencing HiraginoKakuGothic.ttc: <customFonts key="customFonts"> <array key="HiraginoKakuGothic.ttc"> <string>HiraginoSans-W3</string> </array> </customFonts> The problem appears to be triggered when setting UILabel fonts to "ヒラギノ角ゴシック W3 16.0" in Interface Builder, which causes the XIB to reference HiraginoKakuGothic.ttc. Interestingly, when I create a new project and use the same fonts ("ヒラギノ角ゴシック W3 16.0"), it does NOT automatically reference HiraginoKakuGothic.ttc. Here's what I've tried: ①Changed both UILabels' fonts to system font ②Verified in XIB Source Code that the .ttc references were gone ③Cleaned Build Folder ④Cleared DerivedData ⑤Restarted Xcode ⑥Set the labels back to "ヒラギノ角ゴシック W3 16.0" ⑦Checked XIB Source Code again - the non-existent .ttc references reappeared Even if I manually remove the customFonts references from the source code, they get regenerated as soon as I make any font changes in Interface Builder. I've also noticed that Xcode 16.1 has the same underlying issue, though it doesn't produce the console errors that Xcode 26 does. This seems to be a long-standing XIB issue, possibly related to reference caching. While new projects aren't affected, existing projects continue to maintain these incorrect references. My questions: How can I permanently resolve this issue in my existing project? What's the potential impact of these incorrect font references? Is there a way to clean up these cached references without affecting the rest of the project? Any insights or workarounds would be greatly appreciated. Thank you.

Hello We've encountered an issue with WKWebView in the latest iOS 26 beta. When loading a PDF URL, the background of the PDF viewer now displays as a dark gray instead of the expected white. Device: iOS 26 Simulator/Device Component: WKWebView Issue: The background color of the loaded PDF is gray. Expected Behavior: The background should be white, as it has been in all previous iOS versions. Link for Testing: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf We confirmed that the same PDF and code render with a white background on iOS 26 and earlier. Questions: Is this an intentional change in iOS 26's WKWebView? If so, is there a new property or configuration setting available to control the background color of the PDF viewer within WKWebView? We would like to have the ability to set it back to white. Any insights, workarounds, or information on this matter would be greatly appreciated. Thank you.

Hello Apple Developer Community, I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26. Problem Description: I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior: PDF links should remain clickable and functional across all iOS versions. What I've Tried: Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps: Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment: Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2 Questions: Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity? Any guidance or suggestions would be greatly appreciated!