with iOs26 it works so so great, that every time i look something up ChatGPT is the first thing to Seach the web for everything about it then, i can read it an it gives a link for me to go to if i wont to further look inti it ,this on I Phone SE 3 Generation ,it has better Siiri to better on the I Phone SE 3rd Generation.

<script src="https://js.braintreegateway.com/web/3.92.0/js/client.min.js"></script>

We would like to confirm the unsubscribe flow related to recurring payment processing. When a user unsubscribes, does your system send any notification to us? If no notification is provided, we will not be able to detect the unsubscribe event and will continue to send recurring payment requests to the gateway periodically. Would this cause any issues? We would appreciate it if you could share the specific unsubscribe flow with us. Thank you in advance for your support.

Hello Apple App Review Team, We are using Privy to enable sign in with Farcaster in our app. Privy is a 3rd party authentication SDK, and it currently opens the authentication URL using the system browser. Unfortunately, this behavior is handled internally by Privy and we do not have access or control to override it in order to present the sign-in flow in-app using SFSafariViewController. We understand the importance of maintaining a seamless and secure user experience, and we fully support the use of SFSafariViewController or ASWebAuthenticationSession. However, since Privy does not expose an option to change this behavior at the moment, we are limited by their current implementation. We have reached out to the Privy team requesting a change or improvement that would allow us to use SFSafariViewController instead of the external browser. In the meantime, we would appreciate your guidance on how to proceed, or whether an exception could be granted due to this 3rd party SDK limitation. Thank you for your understanding and support.

I’m encountering an issue with CSS not displaying when using WKURLSchemeHandler to load local HTML files. When I package the app using Xcode 15.3 or above, the CSS styles do not display on iOS 17 or higher. However, on iOS 16.7.1, the CSS displays correctly. • If I use Xcode 15.2 to package the app, the CSS loads and displays correctly on all iOS versions. I am using WKURLSchemeHandler to intercept and load the local HTML files. Is there any known issue or workaround for this? You can now post this in the “Safari & Web” section of the Apple Developer forums for further assistance! // // CustomURLSchemeHandler.m // HTMLTest // // Created by lvxue on 2024/9/23. // // CustomURLSchemeHandler.m #import "CustomURLSchemeHandler.h" @implementation CustomURLSchemeHandler - (void)webView:(WKWebView *)webView startURLSchemeTask:(id<WKURLSchemeTask>)urlSchemeTask { NSURL *url = urlSchemeTask.request.URL; //NSString *filePath; NSString *filePath = [[NSBundle mainBundle] pathForResource:@"index" ofType:@"html" inDirectory:@"LoaclHtml.bundle/A4"]; if ([url.lastPathComponent hasSuffix:@".css"]) { filePath = [[NSBundle mainBundle] pathForResource:@"style" ofType:@"css" inDirectory:@"LoaclHtml.bundle/A4/css"]; } else if ([url.lastPathComponent hasSuffix:@".js"]) { filePath = [[NSBundle mainBundle] pathForResource:@"yourJSFileName" ofType:@"js" inDirectory:@"LoaclHtml.bundle/A4/js"]; } NSData *htmlData = [NSData dataWithContentsOfFile:filePath]; NSString *mimeType = [self mimeTypeForPath:filePath]; NSURLResponse *response = [[NSURLResponse alloc] initWithURL:url MIMEType:mimeType expectedContentLength:htmlData.length textEncodingName:@"utf-8"]; [urlSchemeTask didReceiveResponse:response]; [urlSchemeTask didReceiveData:htmlData]; [urlSchemeTask didFinish]; } - (void)webView:(WKWebView *)webView stopURLSchemeTask:(id<WKURLSchemeTask>)urlSchemeTask { } - (NSString *)mimeTypeForPath:(NSString *)path { NSString *fileExtension = [path pathExtension]; if ([fileExtension isEqualToString:@"html"]) { return @"text/html"; } else if ([fileExtension isEqualToString:@"css"]) { return @"text/css"; } else if ([fileExtension isEqualToString:@"js"]) { return @"application/javascript"; } else if ([fileExtension isEqualToString:@"png"]) { return @"image/png"; } else if ([fileExtension isEqualToString:@"jpg"] || [fileExtension isEqualToString:@"jpeg"]) { return @"image/jpeg"; } else if ([fileExtension isEqualToString:@"gif"]) { return @"image/gif"; } return @"application/octet-stream"; } @end code-block

Hi Apple Devs & WebKit Team, We operate https://excnum.com — a personal website currently under reconstruction. It's HTTPS-secure, hosted on a clean VPS, and now features a simple placeholder page with no active forms, scripts, or external redirects. However, Safari on both iOS and macOS is flagging it as a “deceptive website”, blocking all access. This warning appears even though: The site uses a valid SSL certificate via Cloudflare There are no redirects, tracking scripts, or dynamic code We serve a static landing page (“under maintenance”) with zero interaction No malware, phishing, or obfuscation exists — verified with multiple tools A review request has already been submitted at: https://websitereview.apple.com We believe the site may have been blacklisted previously under past ownership or prior configurations. It has since been completely restructured and cleared, but the Safari warning persists. This false flag is harming visibility and trust for an otherwise neutral website. Any advice on how to expedite re-evaluation or request a manual delisting from the deceptive site list would be much appreciated. Thank you! — Alex Admin, EXCNUM.COM

Hello Apple Developer Team, I would love to see iCloud Keychain Autofill and Touch ID support extended to Chromium-based browsers on macOS (such as Ecosia, Brave, or Vivaldi). Currently, Safari allows autofill of passwords using Touch ID, but when using other browsers, I have to manually copy-paste credentials from Keychain Access, which is time-consuming. Would it be possible for Apple to provide an API or framework that allows non-WebKit browsers to integrate iCloud Keychain autofill while keeping security intact? This feature would make macOS more convenient for users who prefer alternative browsers while keeping security standards high. Thanks in advance for considering this! Best regards, Kilian

Hi, I’m trying to detect whether my Safari Web Extension is running in Safari or Safari Technology Preview. Is there a reliable way to do that? I can get the executable path of the parent process using proc_pidpath(). However, unlike Chrome or Firefox, Safari extensions run under /sbin/launchd as the parent process, not the responsible process (browser’s binary). In this scenario, I need the executable path of the actual browser process, but I haven’t found a way to get it. Also, Safari doesn’t implement the Web Extension API’s browser.runtime.getBrowserInfo(), unlike Firefox. I haven’t tested it yet, but I’m considering checking the user agent string, though I’m not sure how reliable that would be. Use Case Some users use my Safari extension as a web development tool and want to enable some features exclusively in Safari Technology Preview, while using other features only in standard Safari. If I could detect which browser is in use, I could provide the appropriate functionality for them.

I'm experiencing issues with audio playback in my React video player component specifically on iOS mobile devices (iPhone/iPad). Even after implementing several recommended solutions, including Apple's own guidelines, the audio still isn't working properly on iOS Safari. It works completely fine on Android. On iOS, I ensured the video doesn't autoplay (it requires user interaction). Here are all the details: Environment iOS Safari (latest version) React 18 TypeScript Video files: MP4 with AAC audio codec Current Implementation const VideoPlayer: React.FC<VideoPlayerProps> = ({ src, autoplay = true, }) => { const videoRef = useRef<HTMLVideoElement>(null); const isIOSDevice = isIOS(); // Custom iOS detection const [touchStartY, setTouchStartY] = useState<number | null>(null); const [touchStartTime, setTouchStartTime] = useState<number | null>(null); // Handle touch start event for gesture detection const handleTouchStart = (e: React.TouchEvent) => { setTouchStartY(e.touches[0].clientY); setTouchStartTime(Date.now()); }; // Handle touch end event with gesture validation const handleTouchEnd = (e: React.TouchEvent) => { if (touchStartY === null || touchStartTime === null) return; const touchEndY = e.changedTouches[0].clientY; const touchEndTime = Date.now(); // Validate if it's a legitimate tap (not a scroll) const verticalDistance = Math.abs(touchEndY - touchStartY); const touchDuration = touchEndTime - touchStartTime; // Only trigger for quick taps (< 200ms) with minimal vertical movement if (touchDuration < 200 && verticalDistance < 10) { handleVideoInteraction(e); } setTouchStartY(null); setTouchStartTime(null); }; // Simplified video interaction handler following Apple's guidelines const handleVideoInteraction = (e: React.MouseEvent | React.TouchEvent) => { console.log('Video interaction detected:', { type: e.type, timestamp: new Date().toISOString() }); // Ensure keyboard is dismissed (iOS requirement) if (document.activeElement instanceof HTMLElement) { document.activeElement.blur(); } e.stopPropagation(); const video = videoRef.current; if (!video || !video.paused) return; // Attempt playback in response to user gesture video.play().catch(err => console.error('Error playing video:', err)); }; // Effect to handle video source and initial state useEffect(() => { console.log('VideoPlayer props:', { src, loadingState }); setError(null); setLoadingState('initial'); setShowPlayButton(false); // Never show custom play button on iOS if (videoRef.current) { // Set crossOrigin attribute for CORS videoRef.current.crossOrigin = "anonymous"; if (autoplay && !hasPlayed && !isIOSDevice) { // Only autoplay on non-iOS devices dismissKeyboard(); setHasPlayed(true); } } }, [src, autoplay, hasPlayed, isIOSDevice]); return ( <Paper shadow="sm" radius="md" withBorder onClick={handleVideoInteraction} onTouchStart={handleTouchStart} onTouchEnd={handleTouchEnd} > <video ref={videoRef} autoPlay={!isIOSDevice && autoplay} playsInline controls crossOrigin="anonymous" preload="auto" onLoadedData={handleLoadedData} onLoadedMetadata={handleMetadataLoaded} onEnded={handleVideoEnd} onError={handleError} onPlay={dismissKeyboard} onClick={handleVideoInteraction} onTouchStart={handleTouchStart} onTouchEnd={handleTouchEnd} {...(!isFirefoxBrowser && { "x-webkit-airplay": "allow", "x-webkit-playsinline": true, "webkit-playsinline": true })} > <source src={videoSrc} type="video/mp4" /> </video> </Paper> ); }; Apple's Guidelines Implementation Removed custom play controls on iOS Using native video controls for user interaction Ensuring audio playback is triggered by user gesture Following Apple's audio session guidelines Properly handling the canplaythrough event Current Behavior Video plays but without sound on iOS mobile Mute/unmute button in native video controls doesn't work Audio works fine on desktop browsers and Android devices Videos are confirmed to have AAC audio codec No console errors related to audio playback User interaction doesn't trigger audio as expected Questions Are there any additional iOS-specific requirements I'm missing? Could this be related to iOS audio session handling? Are there known issues with React's handling of video elements on iOS? Should I be implementing additional audio context initialization? Any insights or suggestions would be greatly appreciated!

Problem Safari requires tabindex="0" for keyboard access to scrollable containers. Chrome (v130+) and Firefox (v4+) handle this automatically. Current Behavior Chrome/Firefox: Scrollable div with overflow: auto → automatically keyboard-accessible (Tab to focus, Arrow keys to scroll) Safari: Same element → NOT keyboard-accessible unless: Add tabindex="0", OR Container has focusable children Workaround <div style="overflow-y: auto; height: 300px;" tabindex="0"> <!-- content --> </div> Issue: Adds unnecessary tab stops on Chrome/Firefox where not needed. Request Will Safari support auto-focus for scrollable containers? (matching Chrome/Firefox) If not planned: Any official Apple guide for cross-browser scrollable accessibility? Timeline? If on roadmap, estimated Safari version? Can I subscribe for updates? Use Cases Dropdown menus Modal dialogs Tab panels Data tables Chat interfaces Reference: WCAG 2.1 Keyboard Accessible: https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html Example component: https://www.radix-ui.com/themes/docs/components/scroll-area

WebRTC and Web Audio are essential for modern web applications, powering everything from real-time voice communication to accessibility tools. However, in iOS Safari, these technologies are suspended as soon as the screen locks or Safari goes into the background. This makes web-based calling, live audio spaces, broadcast sessions and assistive applications unreliable for iOS users. Why This Matters: It’s impractical and inefficient. Asking users to keep their screen on to continue a WebRTC call wastes more battery, as the display is one of the most power-intensive components of a device. Allowing WebRTC audio to run in the background would be more battery-efficient than forcing the screen to stay lit for extended periods. Competing platforms allow WebRTC to run in the background. Safari’s restriction puts web-based applications at a disadvantage compared to native apps. Many industries depend on persistent WebRTC audio, including telehealth, live broadcasting, and accessibility tools. This restriction forces developers to build native iOS apps instead of using the open web, limiting web innovation and increasing development costs. Proposed Solution: Apple could implement an explicit user permission for background WebRTC, similar to how background audio playback is already handled for media apps. This would balance user security with the need for uninterrupted real-time communication—without forcing users to keep their screens on unnecessarily. I would love to hear if anyone has found workarounds or if Apple has commented on potential improvements in future iOS versions.

hi, I'm having an issue with Safari devlop menu "Web Extension Background Content" menu item being grayed out. I cant do any debugging right now and its becoming mission critical for us. Any help is appreciated. Thank you,

Dear Apple Developer Support Team, I am writing regarding critical issues we are facing with Safari web push notifications in our application iLiveMyLife.io, which is severely impacting our ability to maintain reliable communication with our users. Issue Description: We are experiencing persistent problems with Safari push notification tokens expiring or becoming invalid without any notification to our server. This creates several critical issues: Users stop receiving notifications without any indication of failure Our notification delivery system has no way to detect token expiration The expiration appears to happen frequently (seemingly almost daily in some cases) There is no reliable mechanism to re-establish push communication without users manually revisiting the app Technical Impact: Our messaging functionality becomes completely unreliable We must resort to email or SMS as fallback mechanisms, which is not feasible for a real-time communication platform This makes building any reliable messaging application on Safari practically impossible The Broader Context: What makes this situation particularly challenging is that all potential alternative browser APIs that could help address this issue appear to be deliberately disabled or restricted in Safari: Background Service Workers don't function in the background on iOS Safari Background Sync API is not supported WebSockets cannot operate when the app is closed There's no way to programmatically check the validity of push tokens The combination of these limitations creates a situation where developers have no viable technical path to build reliable notification systems for PWAs on Safari. This appears to be a systematic restriction rather than individual API limitations. Requested Information: Is there a recommended approach to detect Safari push token expiration? Are there alternative notification mechanisms for PWA applications on Safari that offer more reliability? Is there documentation on the lifecycle of Safari push tokens that could help us implement proper handling? Are there plans to improve the Web Push API implementation in Safari to address these reliability issues? Could you clarify if these limitations are intentional design decisions or technical constraints that might be addressed in future updates? Business Impact: This issue fundamentally undermines our platform's core functionality. For a collaborative tool, reliable notifications are essential - users cannot collaborate effectively if they miss updates because their push tokens silently expired. The current state creates confusion among our users, who don't understand why they suddenly stop receiving notifications. Any guidance or assistance you could provide would be greatly appreciated. We're committed to providing an excellent experience on Safari, but the current push notification limitations make this extremely challenging. Thank you for your time and consideration. Best regards, Ilya

Hi! My team and I are developing an education platform. One of our features is a auto-play flashcard feature where users can listen to their flashcards hands free. We are having an issue where the autoplay wont work for users with iPhone's. I think the rule is that user's are supposed to give consent to the auto-play. We do make the user hit play before it starts so that should be the "constent" but it's still not working. Anyone have ideas?

I am currently developing a Chrome, Firefox and Safari web extension, and I am facing a CSP issue on the content script on Safari. The extension I develop has a content script that injects an img tag in the DOM of web pages the user is visiting. That img tag fetches its content at a specific URL. On Chrome and on Firefox, the img tag content fetches the content at the URL with no issue on every web pages, including those that set the CSP header img-src. On Safari, I'm getting the following error on web sites that set the img-src CSP header: Refused to load https://axxlfrmnpq.cloudimg.io/www.macifavantages.fr/wp-content/uploads/2021/06/Garmin-logo.png?func=bound&w=225&h=113 because it does not appear in the img-src directive of the Content Security Policy. Here is the actual CSP img-src header content of the web page where, on Safari, the injected img tag does not load the content at https://axxlfrmnpq.cloudimg.io/www.macifavantages.fr/wp-content/uploads/2021/06/Garmin-logo.png?func=bound&w=225&h=113: Content-Security-Policy: img-src https://secure.adnxs.com https://www.facebook.com https://.garmin.cn 'self' data: .garmin.com .trustarc.com .truste.com https://static.garmincdn.com https://www.google.com https://www.google.co.uk https://prefmgr-cookie.truste-svc.net https://res.cloudinary.com https://res.garmin.com https://.criteo.com https://.doubleclick.net https://www.googleadservices.com https://px.adentifi.com https://rtb.adentifi.com https://.teads.tv https://www.googletagmanager.com https://bat.bing.com https://.yahoo.com https://sync.outbrain.com https://*.google-analytics.com https://stats.g.doubleclick.net https://static.hotjar.com https://script.hotjar.com .akamaihd.net https://.tealiumiq.com https://deploytealium.com https://pixel.mediaiqdigital.com; My question is, is the page CSP blocking the img tag injected in the web page by the extension's content script? If so, is this behavior documented somewhere, or is it a Safari bug? I saw there is a similar post on the forum, but I couldn't find if the issue is a bug or if it's the expected behavior on Safari: https://developer.apple.com/forums/thread/651542?login=true. Thank you very much for your help.

Posting this here since Apple Discussion Forums kept deleting this citing it was a "developer issue" even though it's not and there's no way to appeal. Can someone help me? I can't get 2FA SMS/Email Codes to autofill in Brave or Chrome as of this writing. Has anyone else had this issue?

ios drop file wrong file name I use the following simple JS code to drag file from the browser to the desktop. Works perfect on MacOS. onDragStart(event, ucpView) { let file = new BrowserFile([this.file.fileContent], this.file.displayName, { type: 'application/ucp-scenario' }); const fileURL = URL.createObjectURL(file); event.dataTransfer.setData("DownloadURL", `application/octet-stream:${file.name}:${fileURL}`); event.dataTransfer.setData("text/uri-list", fileURL); } but on iOS it keeps nameing the file Text1.txt Text2.txt ... and ignores the DownloadURL whats the best way to get it workng on both OS?

Hello from Leipzig, Germany! I noticed that when vertically scrolling in Safari 26 on my Mac, the content of the website I am currently working on is visible in the tab and URL bar with a liquid glass effect. I then looked at various other websites. Some websites have an opaque top bar. Some websites have a transparent top bar where content is visible when scrolling. On the Apple website, the top bar is opaque in light mode but transparent in dark mode. Unfortunately, I can't find a way to control this behavior. Has anyone found out more about this?

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!

I want to confirm the specifications and behavior of Safari. We have a system built on Microsoft Azure that uses Azure AD B2C for authentication. When we logging in, there is a phone authentication feature where a call is made to the registered phone number. However, this phone authentication does not work properly only on iPhone's Safari. The specific situation is listed below: When performing phone authentication on iPhone's Safari, a call is made from Azure AD B2C, and pressing the # button on the Safari screen can be done. But then, it transitions to an error screen. We tried multiple iPhone devices and multiple iOS versions, but the result was the same. But when accessing the system on a PC, and performing phone authentication, it works without any errors. Also when we use browsers other than Safari (for example, Google Chrome and Firefox) on the iPhone, the phone authentication works without any errors, too. Even with Safari, if the device displaying the login screen and the device making the call are different, phone authentication works without any errors, too.(it fails if they are the same device). We reached out Microsoft about this issue, and they responded that: The Azure resource called FrontDoor at the front end of Azure AD B2C supports the HTTP/2 protocol, and HTTP/2 protocol is used in communication with Safari. In Safari's HTTP/2 communication, when a call is received while the screen is displayed, a reset packet is sent to the web server (in this case, the web server is FrontDoor). This interrupts the session, causing a session termination error on the Azure AD B2C side, and phone authentication fails. Therefore, we would like to ask you the following two points: In HTTP/2 communication, does the Safari browser send a reset packet to the web server when it receives a phone call? If so, what is the cause of this behavior? And are there any measures to prevent the reset packet from being sent?