We are developing a mobile-first, browser-only web application that requires users to upload 20–200 images stored inside a single folder (for example, a merchant product directory). On iOS Safari: window.showDirectoryPicker() is not supported. is not supported. File System Access API is not available. Users must manually multi-select images from the Photos picker. This creates significant friction for bulk upload workflows. We are NOT requesting unrestricted file system access. We are asking whether a privacy-preserving, user-granted folder-scoped permission model is being considered for web applications. For example: User explicitly selects a folder. The web app receives scoped access only to that selected folder. Access is session-bound and revocable. No background or global storage access is required. Questions: Is folder-level access for web apps being considered for iOS Safari? Does installing a PWA provide any enhanced file access capability? Are there recommended best practices for handling bulk image uploads in browser-only iOS applications? Is there any roadmap alignment with the File System Access API standard? Our goal is to remain browser-only and maintain strict user privacy while improving usability for high-volume image workflows. Any clarification on intended platform direction would be appreciated.

Issue Description I'm developing a hybrid iOS app and encountering WebView bridge communication issues after updating to Xcode 16 with iOS 18 SDK. App Architecture AViewController: Initial view controller displayed at app launch Handles WebView setup and web-to-native bridge communication Pushes BViewController when receiving "B" bridge message from web BViewController: View controller stacked on top of AViewController Managed by navigation controller AViewController's WebView continues bridge communication even when BViewController is active Problem Behavior Xcode 15 (iOS 18): WebView bridge communication in AViewController works normally while BViewController is active Xcode 16 (iOS 18 SDK): Server communication breaks or hangs without response while BViewController is active Communication resumes only after popping back to AViewController from BViewController Questions Is the current architecture (configuring WebView in AViewController and maintaining bridge communication through AViewController's WebView while BViewController is presented) not a recommended pattern? Is Xcode 16's iOS 18 SDK the cause of this issue? If so, could you help me understand which specific changes are affecting this behavior? This is urgent as we need to deploy soon. I would greatly appreciate a prompt response.

{ "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.

We are encountering a download issue in Safari 18.2 on macOS Sequoia 15.2 where file downloads initiated by our AngularJS application (such as Excel exports) are silently blocked. There are no errors in the browser console, and the download does not occur. Interestingly, after testing on Safari 18.3 with Sequoia 15.3, the downloads worked as expected. However, the problem reappeared on Safari 18.4 with Sequoia 15.4. We suspect that recent changes in Safari’s security or download handling may be preventing downloads triggered via asynchronous JavaScript (e.g., AJAX calls) that are not initiated directly by user interaction. We would appreciate any insights, suggestions, or possible workarounds from the community. Looking forward to your guidance on this matter.

In WKWebView, there is the WKUIDelegate method: func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {} This delegate method provides a callback when a new window (for example, target="_blank") is requested in the web view. However, in native SwiftUI (iOS 26), WebView / WebPage APIs do not provide an equivalent delegate method to handle new window requests. As a workaround, I am using the following method: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {} In this method, when action.target == nil, I treat it as a new window request. My question: Is relying on action.target == nil in decidePolicy a reliable and future-safe way to detect new window requests in SwiftUI’s WebView, or is there a better or more recommended approach for handling target="_blank" / new window navigation in the SwiftUI WebView APIs? Code: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy { guard let webPage = webPage else { return .cancel } // Handle case where target frame is nil (e.g., target="_blank" or window.open) // This indicates a new window request if action.target == nil { print("Target frame is nil - new window requested") // WORKAROUND: Until iOS 26 WebPage UI protocol is available, we handle new windows here // Try to create a new WebPage through UI plugins if handleCreateWebPage(for: webPage, navigationAction: action) != nil { // Note: The new WebPage has been created and published to the view return .allow } } return .allow }

Is iOS WebRTC communication via WebView stable when the app is in the background? I'm implementing SIP communication using JsSIP within a WebView. On iOS, I'm using WKWebView, but I'm concerned that its resources may be limited by the system when the app is backgrounded. Even with the VoIP background mode declared in the Info.plist file, will the system preserve sufficient resources to keep the SIP communication active?

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?

I have compiled some Java code to WebAssembly via TeaVM and wrapped it in a PWA. The resulting code runs nicely in Firefox and Chrome but throws an exception in Safari. CompileError: WebAssembly.Module doesn't parse at byte 1657: invalid extended GC op 24, in function at index 2251 Can anybody tell me what's wrong with that code? I mean it can't be so bad if Firefox and Chrome can parse and run it without problems. I am using the most recent versions of all browsers and the offending code can be found here: Run the demo via: https://mpmediasoft.de/demos/Emmentaler/Emmentaler-Demo-TeaVM-Wasm/index.html The offending wasm file is: https://mpmediasoft.de/demos/Emmentaler/Emmentaler-Demo-TeaVM-Wasm/tvw/ModelBridgeTeaVM.wasm With Safari the demo just shows some empty space instead of a complex polygon. You can see the error in the javascript console of Safari.

We are experiencing a problem that seems to be caused by a specification changes for Safari. We would like to discuss how to solve this problem. Sample JavaScript: <html> <head> <script> function jumpPage(code) { document.main.code.value = code; win1=window.open("","win1","toolbar=no,resizable=yes,menubar=no,scrollbars=yes,status=yes,left=0,top=0"); win1.resizeTo(width=screen.availWidth,height=screen.availHeight); document.main.action="details"; document.main.target="win1"; document.main.submit(); } </script> </head> <body> <form name="main" method="post" action="" target=""> <a href="javascript:jumpPage('001')">details</a> <input type="hidden" name="code" value=""> </body> </html> This JavaScript performs the following actions when a link is clicked. Open a window using window.open in JavaScript Submit the above opened window by post method to the target in JavaScript. When this operation is performed, the process in (2) could submit to the target page with “POST” method before iOS18.1, but will transition to the page with“GET”method from iOS18.2 onward. All protocols are http. This problem does not occur if the URL is specified as an IP address, but it does occur if the host name is specified as. Please let me know how to use with“POST”method as in iOS 18.2 or earlier. Best regards,

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; }

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

Steps to Reproduce 1. Create a native UIViewController with a WKWebView, loading test-1.html (contains position:fixed header that displays correctly). 2. Push another UIViewController also with a WKWebView, this time loading test-2.html. 3. In test-2.html, tap into the to summon the on-screen keyboard. 4. Without calling blur(), perform an interactive swipe-back gesture to go back to the first view controller. 5. Observe that the fixed header in test-1.html is now offset downward by approximately the height of the keyboard and does not return to its original position. demo-link : https://bugs.webkit.org/attachment.cgi?id=476324

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 have programmed a website and struggle to get it to work on safari ios26. 100vh fixed positioned images do not fill the screen anymore. i could live with that, having two background coloured spaces at the top and at the bottom. but elements that scroll out of this new viewport are fully visible, as you can see on the enclosed screenshots. i have no idea how i could fix this and dont find any answer anywhere on the net?

I integrated Apple Pay on the web following the documentation, and verified that the payment works successfully in the sandbox environment using Safari on iOS and Mac. Later, I launched the Apple Pay payment code on a third-party web page that supports Apple Pay, and scanned the code with the camera of an eligible iOS device. The camera then displayed the Apple Pay button; after tapping it, a brief pop-up message saying ‘Service Unavailable’ appeared, and then it closed automatically. How can I troubleshoot and resolve this issue?

Hello, I have an authentication flow where my app communicates with a backend protected by F5 client certificate validation. The client certificate is distributed via MDM and is available in the device keychain, but not accessible directly from the app. When using ASWebAuthenticationSession (or SFSafariViewController) Safari can successfully pick up and present the certificate during authentication, so that part works fine. However, the backend’s authenticate endpoint only supports a POST request with an Authorization header, whereas ASWebAuthenticationSession only accepts a GET URL when starting the session. My questions are: How is this type of flow typically implemented in iOS? Should the backend provide a GET-based endpoint that redirects into the POST, or is there a recommended iOS pattern (e.g., an intermediate HTML page that does the POST after certificate validation)? Are there Apple guidelines on handling certificate-based auth with ASWebAuthenticationSession when the API requires POST, especially for In-House distributed apps? Any guidance or best practices would be very helpful.

I am following up on Thread (https://developer.apple.com/forums/thread/733233). Currently, SFSafariExtensionManager.getStateOfSafariExtension only returns if an extension is enabled, but not if "Allow in Private Browsing" is toggled on. Is there an API in macOS 26 and Safari 19 that allows a native Safari App Extension to detect this specific permission?

We confirmed a problem at Safari on iPadOS 18.2 or after version. For confirmation, we made a HTML document (see below HTML1) what include ‘method="POST" target="_blank"’ and tested the form however server received GET method and there is no parameter, server did not receive “id” parameter. We confirmed that fact in captured packet and log file that on the server. HTML1: We also made another HTML document (see below HTML2) what include submit button, but the server received GET method as above. HTML2: And we also confirmed that it behaves differently depending on the network environment. If the form targets a name that does not exist (ex. target=” A12345”), behaves differently http or https. http: Safari opened new tag, but the server received GET method. Normally, Safari open new tag and the server receive POST method. https: Safari opened new tag, and the server received POST method. It is normally. If the form targets ‘_blank’, the server received GET method on http or https both. We think Safari change the method POST to GET and delete parameters. It is not conformed to the HTML specification if is that true. We confirmed it was not happened at Safari on iPadOS 17.4, and Windows PC (Edge, Chrome). The method what the server received is POST. We find same problem in Apple Support Community (see below URL). https://discussionsjapan.apple.com/thread/255987615 (Described in Japanese) Is it a bug in Safari on iPadOS 18.2 or after version? Do you have plan to fix? Or if fixed the bug, when do you release fixed version.

我使用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/

Hello Community, My application was rejected by Apple App Review, citing Guideline 4.7 and "non-embedded," which I believe is incorrect. All transactions are signed and sent directly through the app with explicit user permission. Additionally, there's an issue with min apps where users can access the functionality via a browser to interact with the service. This feature has been part of my old application and hasn't changed in the new update. It’s the same functionality as used by popular wallets like Metamask Uniswap Coinbase Which also employ web3 technology. Over the past two weeks, I've tried to communicate with Apple's support team but have been ignored or received only generic rejection emails. This has left me frustrated and concerned about the time and resources I’ve invested in developing and supporting this app. Could you please help me find a solution? Your assistance would be greatly appreciated!