Hello Friends, This is my first post so would love any suggestions on how to make posts here. So I have a shopify widget which is type of clone for Instagram stories, with videos but I noticed some issues where my videos are kind of unresponsive or just shuts down. Below is the screen shot of the issue: This problem I noticed on iPhone 11 Pro on clients phone, the IOS version is below 26. Some times my iPhone 13 also faces same issue but only when battery is low and multiple heavy apps are opened. Attached a code block also: {validStories.map((story) => { const videoUrl = extractVideoUrl(story.sv?.[0]?.m); const storyThumbnail = story.tu && story.tu.length > 0 ? story.tu : null; const videoThumbnail = story.sv?.[0]?.m?.[0]?.t && story.sv[0].m[0].t.length > 0 ? story.sv[0].m[0].t : null; const thumbnailUrl = storyThumbnail || videoThumbnail; const hasThumbnail = !!thumbnailUrl; const isPlaying = playingVideoIds.has(story.i); const shouldRenderWrapper = hasThumbnail || isPlaying; return ( <div key={story.i} className="ins-story-item" onClick={(e) => { handleActiveStoryChange(story.i, e); handleActiveVideoId(story.i); }} style={{ position: "relative", zIndex: 1 }} > {shouldRenderWrapper && ( <div className="ins-story-circle-wrapper" style={{ position: "relative", overflow: "hidden" }} > {hasThumbnail && !isPlaying && ( <img src={thumbnailUrl} alt={story.t} className="ins-story-image" onError={() => { console.log( `[Story ${story.i}] Thumbnail failed to load: ${thumbnailUrl}` ); }} /> )} <video src={videoUrl} className="ins-story-video" autoPlay={true} muted playsInline loop onLoadedData={() => handleVideoPlaying(story.i)} onPlaying={() => handleVideoPlaying(story.i)} onError={(e) => { console.log(`[Story ${story.i}] Video error`, e); }} /> </div> )} {story.t !== "New Collection" && ( <span className="ins-story-title">{story.t}</span> )} </div> ); })} </div> {activeStoryId && <StoryModal />} </>```

We operate a native iOS app that authenticates users via the system browser using OIDC against a 3rd party SaaS authentication broker, which then performs authentication against the individual customer IdPs using SAML within the browser session, and then completes the OIDC login between the broker and our application. Our application initiates the OIDC login using ASWebAuthenticationSession, using the broker’s library, against the broker, and at that point the authentication workflow is handled by the broker. At the beginning of the login session, the broker sets a session-identifying cookie for their domain, before redirecting the user to their company’s identity provider to authenticate, which then redirects the user back to the broker. Intermittently, Mobile Safari does not include that previously set cookie on the final communication with the broker, when being redirected from the IdP as the final step of the SAML portion of the login workflow. When the cookie is missing, the broker cannot correlate the authentication response to the original request and the login fails, even though the user successfully authenticated at their identity provider. The same user can sometimes find success after retrying on the same device minutes later, without any changes. When we first started diagnosing this issue, we were seeing about a 20% rate of these errors across all Mobile Safari logins, which we can identify fairly conclusively (from provider logs, based on their guidance) as being caused by the session cookie set in one request not being provided on the subsequent request to the same domain. Our authentication broker provider has indicated, based on their server logs, and logs from an affected device, that this behavior is caused by Mobile Safari’s Intelligent Tracking Protection (ITP) causing Mobile Safari to not send the login session cookie to the broker when handling the SAML redirect from the IdP back to them. Our authentication broker provider recommended that we switch the SAML Request binding setting from POST to Redirect in the SAML configurations against our customer IdPs, which reduced the rate of these errors to about 5% for most of our customers. However, we have at least one customer which is still seeing about a 20% rate in these errors for Mobile Safari logins after this change, and even a 5% error rate seems high. Our authentication broker has not been able to suggest any further remediation options, and has suggested we contact Apple for assistance. Our questions are: Is it reasonable to assume that ITP is causing this issue? Is there any way to confirm, conclusively, that ITP has caused a previously-set cookie to not be provided on a subsequent request to the same domain, i.e. via device logs? If so, are there any steps which can be taken to reduce or eliminate this error? Changes to how ASWebAuthenticationSession is invoked? Changes to the Authentication Broker which would reduce the chance of ITP being triggered? Changes to the Customer IdP configuration which would reduce the chance of ITP being triggered?

I’m a developer working on a Safari Web Extension that’s distributed via the App Store and also tested locally through Xcode. I’m running into an issue that’s affecting my ability to debug errors reported to my Sentry error logging instance from production. The Problem When an error is thrown in one of my extension scripts (e.g., background.js, popup.js, or content.js), the error is sent to Sentry but the captured JavaScript error stack trace replaces the file paths with the webkit-masked-url://hidden placeholder like this: ReferenceError: Cannot access uninitialized variable. at ? (webkit-masked-url://hidden/:14677:28) at ? (webkit-masked-url://hidden/:16307:3) This happens consistently across both App Store builds and local Xcode runs. It prevents me from seeing which script the error came from or resolving the actual source code lines using uploaded source maps in Sentry. My Setup Safari Version: 18.5 (Stable on macOS) Distribution: App Store and local Xcode development Extension Type: Safari Web Extension Error Reporting: Sentry (@sentry/browser SDK) Bundler: Webpack with inline-source-map What I’ve Confirmed I can see the actual source files in Safari’s Web Inspector under the Sources tab when the extension is running. My source maps are uploaded to Sentry correctly and are associated with the matching release. Errors from Safari are being captured by Sentry, but the file URLs are masked, so stack traces cannot be resolved against my original source. My Question Is this behavior (masking file URLs in stack traces with webkit-masked-url://hidden/) intentional for Safari Web Extensions? If so, is there any supported method or workaround to allow exception stack traces to reveal the original script path (e.g., popup.js, background.js) so tools like Sentry or even console logs can point to real locations? I fully understand the privacy/security rationale behind the masking, but as the extension developer, this is making it extremely difficult to debug runtime issues in production. I’d really appreciate any insight into: Whether this masking is expected and permanent behavior If there are any entitlements, debug settings, or Info.plist keys that can alter this behavior for development or for trusted/own extensions If Apple recommends a different way to log extension errors that includes script name or source references Thanks in advance for your help! I’m happy to share more technical details or try out suggestions.

I want to migrate from a Safari App Extension to a Safari Web Extension, but don't know how to get rid of the message, telling users that my extension can access their passwords. Here is a message which I see: I was thinking that this might be because all Safari Web Extension get this type of access, but I have a Safari Web Extension which does not require such level of access: Here is the manifest: { "manifest_version": 2, "default_locale": "en", "name": "__MSG_extension_name__", "description": "__MSG_extension_description__", "version": "1.1", "icons": { "48": "images/icon-48.png" }, "background": { "scripts": [ "background.js" ], "persistent": true }, "browser_action": { "default_popup": "popup.html", "default_icon": { "16": "images/toolbar-icon-16.png" } }, "permissions": [ "nativeMessaging", "tabs" ] } and here is the Info.plist file: Here is the entire code of the extension: https://github.com/kopyl/web-extension-simplified

It seems Safari 18's fetch() does not include credentials even credentials: include and safari extension has host_permissions for that domain. Is there anyone has this problem? I try to request in popup.js like this: const response = await fetch( url, { method: 'GET', mode: 'cors', credentials: 'include', referrerPolicy: 'no-referrer', } ); and it does not include the cookie from host_permissions. Those code worked in Safari 17 (macOS Sonoma).

Hi, We are distributing pk pass files via a web browser. When a user taps Add in the system pass preview, the pass is added successfully, the preview is dismissed, and the user remains in the browser. From a user experience perspective, we would like to better guide users to their newly added pass in Apple Wallet. Is there a supported API, URL scheme, or documented mechanism that allows a web-based flow to transition the user to the Wallet app after a pass has been added? If direct app transitions are not supported in this scenario, what is the recommended best practice for helping users locate and open their newly added pass in Wallet? Thank you for your guidance.

I'm building a progressive web app (PWA) and came to the conclusion that almost nobody knows that this feature exists - Add to Home Screen. Not many people even understand what a PWA is or that you can add it to the home screen. This feels unnatural compared to installing an app from a store. Why do we make it so hard for users? Could we not make this easier by having the ability to call this installation or show an install notification? Right now, when users visit a PWA on iOS, there's no way for developers to let them know they can install it. The "Add to Home Screen" option is tucked away in the Share menu, and most users never find it. I'd really like to be able to show them a friendly prompt. Comparing to other browsers, this is possible via the beforeinstallprompt event. This would make a huge difference for user experience. Right now the only way is to show iOS users a separate set of instructions with screenshots, which feels clunky compared to what's possible on other platforms. I'm curious - is there any reason why this hasn't been added to Safari yet? Other browsers have supported this for years now. Is there any progress being made on this, or is it being considered for the roadmap? It would be really helpful to know if this is something that will be worked on in the future. I know there's a lot on the roadmap, but this would really help developers create better installation experiences for our users. Thanks for considering this!

Please kindly improve the Safari browser side bar implementation further along with what The Browser Company has done with their Arc browser. Arc is about to retire soon too and they're willing to sell their SwiftUI code perhaps too for a decent pile of dollars, not the Jony Ive piles at least it should not. The toggle for side bar is nice and works perfect though!

Here we are facing issue, which is mentioned in detail below: Safari on iOS consistently crashes when loading https://johnsoncontrols.com/. The error shown is: “A Problem repeatedly occurred on https://johnsoncontrols.com/” This happens with multiple iPhone models and iOS versions, suggesting a WebKit rendering or JavaScript execution issue. This occurs occasionally similar behavior on Android, iPhone (Chrome) Environment • Devices: Any iPhone model, we are tested on available models like iPhone 12 mini, iPhone 14, iPhone 15 • iOS Versions: Latest stable releases, occasional occurrence on iOS 13 • Browser: Safari (WebKit) • Network: Both Wi-Fi and cellular tested • Additional Occurrences: Rarely reproduced on Chrome (iPhone, Narzo Android) • Occurs only on physical devices (not observed in Simulator) Steps to Reproduce Open Safari on any affected iOS device. Navigate to https://johnsoncontrols.com/. Sroll page up and down for some time Observe page automatically get reloads, crashed and show error message (A problem repeatedly occurred on “https://johnsoncontrols.com/"). Expected Result Page should be rendered normally without crashing. Actual Result Safari reloads page / blank / crashed and displays errors. Troubleshooting Done • Cleared cache and cookies • Disabled content blockers • Tested in Private mode • Reset Experimental Features • Issue persists across different networks Technical Notes • Suspect JavaScript memory leak or DOM manipulation causing WebKit crash. • Intelligent Tracking Prevention (ITP) or site scripts may conflict. Questions for Community • Can Apple confirm whether this aligns with any known WebKit bugs? • Are there recommended diagnostic steps (e.g., Web Inspector, crash logs, sysdiagnose specifics) for reproducing Safari scroll-related site crashes? • Should the site’s development team adjust JavaScript, rendering approach, or resource handling to improve stability on WebKit?

Here we are facing issue, which is mentioned below: On https://johnsoncontrols.com/, tapping the blue “Scroll to Top” button (up arrow icon) causes the entire page to reload instead of smoothly scrolling back to the top. This issue occurs only on physical iOS devices and is reproducible across multiple models and iOS versions. Similar behavior is rarely/occasionally seen in Chrome on iPhone and some Android devices. Environment • Devices: Any iPhone model, we are tested on available models like iPhone 12 mini, iPhone 14, iPhone 15 • iOS Versions: Latest stable releases • Browser: Safari (WebKit) • Network: Both Wi-Fi and cellular tested • Additional Occurrences: Rarely reproduced on Chrome (iPhone, Narzo Android) • Occurs only on physical devices (not observed in Simulator) Steps to Reproduce Open Safari on a physical iPhone. Navigate to https://johnsoncontrols.com/. Scroll down until the blue “Scroll to Top” button appears on the right side. Then tap on ‘Scroll to top’ button. The page reloads instead of scrolling to the top. Expected Result Tapping the Scroll to Top button should smoothly move the user to the top of the page without reloading. Actual Result Safari reloads the entire page when the button is tapped. Troubleshooting Done • Replaced # with javascript:void(0) in the button’s anchor tag • Tested with e.stopPropagation() • Switched button position from fixed to sticky • Tried overflow-y: scroll; and -webkit-overflow-scrolling: touch; on body • Updated scrollTop logic to match iOS‑compatible standards. Questions for Community • Is this a known WebKit issue on physical iOS devices? • Any recommended debugging or profiling steps to better understand the cause? • Are there best practices or example implementations to improve Safari compatibility for scroll to top interactions?

Hello, I've got Smart App Banner set up on my website. However, I want to be able to measure the traffic coming from this banner to the app store / app (i.e. measure impressions/downloads). Apple documentation (https://developer.apple.com/help/app-store-connect/view-app-analytics/manage-campaigns/) says you can set up a campaign link and use it in the Smart Banner to track those who download / open the app store page using your smart banner (so that we can get attribution). However, there is no documentation at all in terms of how this should be added to the tag when implementing a Smart App Banner. I've tried so many different variations and none have tracked downloads. This includes a structure based on an example taken from WWDC from a few years back which also did not work. I would appreciate any help!

Is there any interest in this forum for those developing for the spatial web and safari. I can't seem to find any posts that are relevant here.

Create shortcut to open chrome with url and put it on the desktop. Tap the shortcut. Tap the username text field. When launching Safari from an iOS shortcut on an iOS device with a valid passkey registered, the passkey suggestion does not appear; instead, the password suggestion appears sometimes.

My team recently released an app to the iOS app store. We are trying to add the Smart App Banner to our website to promote the app, but the banner is not shown. When the page loads, there is a flash of an empty Smart App Banner before it is automatically dismissed. This happens on every page load. If I put use an app ID of other apps the banner appears. I've triple checked that I'm using the correct app ID. So it seems like it is an issue with my app. I can see my app in the App Store, so I know it's available. I've tested on multiple phones.

Hi everyone, I want users not to see the system context menu when long-pressing text on a page in Safari on iOS. I found on MDN that the CSS property -webkit-touch-callout: none; can achieve this. But in reality, it doesn't really work. MDN documents URL: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/-webkit-touch-callout Here’s a minimal example: function preventIOSSafariContextMenu() { if (document.getElementById(STYLE_ELEMENT_ID)) return; if (!IS_TOUCH_DEVICE) return; const style = document.createElement("style"); style.id = STYLE_ELEMENT_ID; style.textContent = ` html, body { -webkit-touch-callout: none !important; } `; (document.head || document.documentElement).appendChild(style); } The context menu persists. Has anyone else encountered this? Is this an intentional change in WebKit, or could it be a regression? If it’s intentional, is there a recommended alternative? Thanks in advance for any insights!

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

The AppleScript script below returns a -600 error (application not running) under STP Tahoe version 231 and macOS 26.1. It functioned flawlessly under previous STP versions under macOS 15.x and 14.x. tell application "Safari Technology Preview" tell front window set _old_tab to current tab set _new_tab to make new tab at after _old_tab set current tab to _new_tab end tell end tell The following version returns a syntax error. Tell application "System Events" Tell process "Safari Technology Preview" tell front window set _old_tab to current tab set _new_tab to make new tab at after _old_tab set current tab to _new_tab end tell end tell end tell How would these scripts need to be fixed for STP 231 for Tahoe?

Apple's WWDC video What’s new for the spatial web says the spatial-backdrop markup may change as it goes through the standards process (at 27:26 mark). I have started adding spatial-backdrops to web pages, so I want to keep an eye out for status updates by Apple and follow the standards progress. Is there any place I can keep an eye on this standards process? Has Apple announced any feature updates or news on spatial-backdrops?

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.

Ever since the iOS and iPadOS 26.2 beta I can’t open Safari at all. Safari tries to open but crashes and goes back to my home screen. I’ve restored my devices and restarted everything and the same issue occurs. I didn’t have this problem on the beta 26.1 but this whole thing started on 26.2.