If we use webView.loadFileURL(indexURL, allowingReadAccessTo: readAccessURL) on an iPad it loads the data and navigation works. But if we place two hands on top of the screen and move a bit, all click events are not working anymore. It works again if we call loadFileURL again. We filled a bug report: FB19812304

Hello, We are experiencing a behavior change with WKWebView related to upgradeKnownHostsToHTTPS. Current application, we explicitly disable automatic HTTPS upgrades: let config = WKWebViewConfiguration() config.upgradeKnownHostsToHTTPS = false Observed behavior iOS 17.5 (built with Xcode 15.3) http:// image URLs are not automatically upgraded to https://, and the behavior works as expected. iOS 18.5 / 18.6.x (built with Xcode 16.4) http:// image URLs appear to be automatically upgraded to https:// by WebKit, even when upgradeKnownHostsToHTTPS is explicitly set to false. This behavior occurs for subresource requests such as <img src="http://..."> inside a WKWebView. Question Has the behavior of upgradeKnownHostsToHTTPS changed in iOS 18 / Xcode 16? Is this property now ignored for certain types of subresource requests (e.g. images), or overridden by new WebKit security policies such as mixed-content HTTPS upgrades? Any clarification or official guidance would be greatly appreciated!.

I’m encountering an issue on iOS when rendering a list using React. Each list item uses the array index as the React key and consists of two parts: a header section that uses position: sticky for dynamic sticking behavior, and a body section whose height is automatically adjusted based on its content. When the list data is updated, I sometimes observe that the sticky header content does not update visually in time, even though the underlying data and DOM have changed. // demo.jsx import React, { useState } from 'react'; import { Button } from '@iftide/mobile'; import './style2.less'; // import data1 from './data1.json'; // import data2 from './data2.json'; const prefixCls = 'im-detaillist'; const data1 = [ { sectionTitle: '2025年05月' }, { sectionTitle: '2025年04月' }, { sectionTitle: '2025年03月' } ]; const data2 = [ { sectionTitle: '2023年08月' }, { sectionTitle: '2023年07月' }, { sectionTitle: '2023年06月' }, { sectionTitle: '2023年05月' } ]; export default function App() { const [list, setList] = useState(data1); const [toggle, setToggle] = useState(true); return ( <div> <Button title="更新2" onClick={() => { setToggle(!toggle); setList(data2); }} /> <div className={`${prefixCls}-container2`} style={{ height: `700px` }}> {list.map((section: any, sectionIdx: number) => { return ( <div className={`${prefixCls}`} key={String(sectionIdx)} // id={section.sectionTitle} > <div className={`${prefixCls}-section-title`} role="text"> {section.sectionTitle} </div> <div style={{ background: 'green', height: `${Math.ceil(400 * Math.random()) + 50}px` }} > 省略 </div> </div> ); })} </div> </div> ); } .@{prefixCls}-section-title { position: sticky; position: -webkit-sticky; will-change: transform; top: 0; z-index: 1; padding-left: 11px; width: 100%; height: 30px; font-size: var(--font-size-s); font-weight: 400; line-height: 30px; color: #000000; background-color: #F4F5F7; letter-spacing: 0; }

Hi! I'm working on a web extension for Safari and I need to send messages from the containing application to JavaScript. For this I use the method class func dispatchMessage( withName messageName: String, toExtensionWithIdentifier identifier: String, userInfo: [String : Any]? = nil ) async throws of the SFSafariApplication class. If the site is opened in Safari in normal mode, everything works as expected. However, if the site is "docked", the messages are not transmitted to this "Web App".

Hello! I have a few questions about integrating an OAuth2 API into my Swift application. I am using this API to access user data from the website (users will authenticate themselves within the app). I have seen other apps use this API in the way that I am describing it so I know that it is possible. However, I am not sure how to implement it. Are there any recommended ways to use an OAuth2 API in my application? The API that I am using does not specifically say that it supports PKCE. However, I have heard from some sources that it does. If it does not support PKCE, how do I still create a secure app infrastructure that will pass App Store Review? At a more basic level, what is the difference between OAuth2 and PKCE? What should I use in my app? Are there any resources to learn a little bit more about these protocols so that I understand them better? Thanks!

WebAuthn can be used in Safari, but when using it with WKWebView, you need to set the default browser definition (com.apple.developer.web-browser). Is this correct? Also, is it possible that the terms of use will change or that it will no longer be available in WKWebView in the future?

How can I make a background image take the entire screen in ios26? I've tried position fixed, sticky, env() css variables but nothing worked. It does it when in PWA mode, but I would like to do so in the browser too.

Description: In our app, we have login page which displayed in WKWebView. In that page, there is an Remember my Device cookie option which user can select, so next time it OTP page will not be displayed. Problem Statement: Recently we found that some issue happened with this cookie. Especially, when users upgraded their OS versions to 18.6 or 26.1 or 26.2. Need to understand, any changes related to Cookie part in latest OS Versions?

我使用Apple Pay on the Web Interactive Demo构建了一个web应用使用的是Payment Request API方式，但是遇到了几个问题： 拉起的web Apple Pay 底部一直转圈圈无法付款，这个是什么问题？ 如何设置sandbox测试付款呢？ 如何异步、同步获取支付结果（后端代码获取支付结果）？demo只有await response.complete("success");前端代码获取支付结果的操作 demo网址: https://shop.wowseer.com/rsolomakhin/pr/applepay/

Since the transition to iOS 18.4, we have been having an issue where when loading an m3u8 file specified in the src attribute of a video tag in WKWebView, the ts file is loaded repeatedly. Are there any good ideas for this? Also, if there have been any changes to the specifications of WKWebView, we would appreciate it if you could let us know.

Safari Extension Error: “Non-persistent background content cannot listen to webRequest events.” after macOS 15.4 / Safari 18.4 Update We’re seeing the following error in the Safari Extensions tab after updating to macOS 15.4 and Safari 18.4: “Non-persistent background content cannot listen to webRequest events.” This error did not appear prior to the update, and we haven’t found any official documentation stating that webRequest API is no longer supported in Safari. In our extension (Manifest V3), we are using the webRequest.onHeadersReceived callback to intercept response headers and read updated cookies. While the functionality itself still works as expected. we’re able to access the response headers and this error is now shown in the Extension settings page. We are not seeing this issue in other browsers (Chrome, Firefox) using the same Manifest V3 setup. Is there any plan to deprecate webRequest support in Manifest V3 for Safari? We’d appreciate any clarification or guidance on how to handle this going forward.

iOS18的app中加载了自己开发的H5页面，H5页面有个input输入框，每次输入框聚焦的时候，都会弹出键盘滑行键入的提示：“滑动手指将字母拼成词以快速键入”，应该怎么修改，达到不每次都弹出这个提示呢

Doc URL: https://aninterestingwebsite.com/documentation/applepayontheweb/requesting-an-apple-pay-payment-session How can I send a POST request using PHP, and what certificates are required? Currently, I have downloaded the following files on the backend: merchant_id.cer, apple_pay.cer, and a local cert.p12 file This my code: But,run error:cURL Error: unable to set private key file: '***/private.pem' type PEM%

Bit of an odd one here, just keen to understand if it’s just me or a more generic issue. For all other apps, I can drag the icon from the dock to place into stage manager left, centre or right. However when I try to do the same with Safari (and only Safari), it just doesn’t work at all. I can repeat this 100%, has been an issue with 26.0, 26.1 and now 26.2. Can confirm this isn’t a problem on my 11” M4 iPad pro running same O/S. Here is a video showing the issue (YouTube) https://youtu.be/0WBGBZVHsfs

{ "epochTimestamp": 1755169981033, "expiresAt": 1755173581033, "merchantSessionIdentifier": "SSH4ADF1D97A60B47FC8537037BE9892237_FF777A9CB5E9EDAB38A01E4EDF71CB5572F19153853DAC70ADC5AA3E75877CB4", "nonce": "b6f1e016", "merchantIdentifier": "7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120", "domainName": "1960-ikffk.checkout.trypeppr.com", "displayName": "peppr", "signature": "308006092a864886f70d010702a0803080020101310d300b0609608648016503040201308006092a864886f70d0107010000a080308203ee30820394a00302010202080e7210e510586e34300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3231303131303032313632395a170d3236303130393032313632395a306b3131302f06035504030c286563632d736d702d62726f6b65722d7369676e5f5543342d50524f445f4b727970746f6e5f45434331143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d0301070342000466e0ea0e787dcb3f66bc533189da2bda08ed9574e421117aa1af2cc310f6a8b19ca3e77ed00fa84e8df2ac8688e529866e76ebad89eda5b7c336e0f0d8a7d05da38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e0416041457c735942abd9ea2feccd3cbe7ede0a37c8cc5fa300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020348003045022100f2fa622622128cd1e1642084bc4117ccdede7289690e864cfb88abb43e04338e022065f85a90b82711d1fd762e0b59c45496e9e683c265c8279998e37872feae46ec308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018930820185020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b300906035504061302555302080e7210e510586e34300b0609608648016503040201a08193301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3235303831343131313330315a302806092a864886f70d010934311b3019300b0609608648016503040201a10a06082a8648ce3d040302302f06092a864886f70d010904312204209378ff57580c3205e9ea38d985a2e9ca2db7f06db29b7560f585561a23894402300a06082a8648ce3d04030204483046022100fad47e840779070d097ef91cd4bfa5381d77426071cb38c1cdc77ff9460ba1470221009215c246893bff0983052caaae610a16117237e73ab36d859008e7b234670eaa000000000000", "operationalAnalyticsIdentifier": "peppr:7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120", "retries": 0, "pspId": "7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120" } This is generated in the onvalidatemerchant event handler, and passed into session.completeMerchantValidation. Using a sandbox account with linked cards, the next thing that happens is a "payment not completed" message in the ApplePay popup on the page, and the oncancel event is hit Inspecting the event, I don't see anything that hints at the issue. There is a sessionError object, but its code is "unknown" and the info object is empty.

Our app connects to the headend to get a IDP login URL for each connection session, for example: “https://myvpn.ocwa.com/+CSCOE+/saml/sp/login?ctx=3627097090&amp;acsamlcap=v2” and then open embedded webview to load the page. (Note: the value of ctx is session token which changes every time). Quite often the webview shows blank white screen. After user cancel the connection and re-connect, the 2nd time webview loads the content successfully. The working case logs shows: didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called twice didReceiveAuthenticationChallenge is called decidePolicyForNavigationResponse is called didReceiveAuthenticationChallenge is called But the failure case shows: Filed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x11461c240 {Error Domain=RBSRequestErrorDomain Code=3 "No such process found" UserInfo={NSLocalizedFailureReason=No such process found}}} didReceiveAuthenticationChallenge is called decidePolicyForNavigationAction is called decidePolicyForNavigationResponse is called If we stop calling evaluateJavaScript code to get userAgent, the blank page happens less frequently. Below is the code we put in makeUIView(): func makeUIView(context: Context) -&gt; WKWebView { if let url = URL(string: self.myUrl) { let request = URLRequest(url: url) webview.evaluateJavaScript("navigator.userAgent") { result, error in if let error = error { NSLog("evaluateJavaScript Error: \(error)") } else { let agent = result as! String + " " + self.myUserAgent webview.customUserAgent = agent webview.load(request) } } } return self.webview } Found some posts saying call evaluateJavaScript only after WKWebView has finished loading its content. However, it will block us to send the userAgent info via HTTP request. And I don’t think it is the root cause since the problem still occurs with less frequency. There is no problem to load same web page on Windows desktop and Android devices. The problem only occurs on iOS and macOS which both use WKWebview APIs. Is there a bug in WKWebview? Thanks, Ying

Hello, why is Safari blocking my domains? https://fitgel.ru https://fittoma.ru https://ohota.pro There are no errors in them, other browsers respond normally.

In my application, I use HTML pages to display the interface. Since it’s a cross-platform app, the pages and interactions work properly on other platforms. However, in WebKit, because HTTPS protocol is used, JS requests from the page cannot use the ws protocol but must use the wss protocol under HTTPS. Is there any way to allow a webpage under HTTPS to use ws requests normally? Google Chrome can do this.

Scenario Overview: In our app, we open an in-app browser to complete a third-party consent flow. The sequence is: App → Website A (set cookie and redirect) → Google → Website A (check cookie) → App After upgrading the app, the first consent attempt fails because the cookie cannot be written, causing the check cookie step to fail. However, if we use the native Safari browser, this issue does not occur. Observed Behavior: Scenario Result Upgrade app → Consent ❌ Fail Upgrade app → Consent fail → Consent again immediately ✅ Pass Upgrade app → Consent fail → Upgrade again after 1–2h → Consent ✅ Pass Upgrade app → Consent fail → Upgrade again after 1d → Consent ❌ Fail Install a new app → Consent ✅ Pass Upgrade app → Consent, cancel flow → Consent again ✅ Pass Install new app → Wait for upgrade → Upgrade app → Consent ✅ Pass Install new app → Wait 1–2h → Upgrade app → Consent ✅ Pass Investigation: From Safari documentation, this seems related to Intelligent Tracking Prevention (ITP), which restricts cross-site cookie behavior during first-party interactions. However, I haven’t found a clear mitigation strategy yet. Question: Has anyone encountered similar issues with Safari ITP after app upgrades? Are there recommended approaches to ensure cookies persist across this redirect flow?

When our Safari Web Extension makes a api request from its background script (registered via "scripts" in manifest.json, e.g., "background": { "scripts": ["js/background.bundle.js"] }) to our authenticated API endpoint (https://api-domain/user), the Cookie header is not included in the request. This occurs only when the extension is running within a non-default Safari User Profile. This causes our API to treat the user as unauthenticated. The exact same extension code, manifest, and API call work correctly (Cookie header is present and user is authenticated) when the extension is running in the Default Safari User Profile.