Environment: MacBook Air M4 macOS 27 Beta Safari Safari Technology Preview Issue: I am experiencing an issue where mouse/trackpad clicks are intermittently ignored near the bottom portion of a webpage. The trackpad hardware appears to be functioning normally, as physical clicks are registered and the issue does not occur consistently across all browsers. Steps to Reproduce: Open Safari or Safari Technology Preview. Navigate to a webpage with interactive elements near the bottom of the visible page. Attempt to click links, buttons, or text fields located in approximately the bottom quarter of the browser window. Observe that clicks are sometimes not registered. Resize the Safari window so that the affected area is no longer located in the bottom portion of the screen. Attempt the same clicks again. Expected Result: Clicks should be consistently registered regardless of their position within the webpage. Actual Result: Clicks in the lower portion of the webpage are sometimes ignored. Resizing the window may temporarily resolve the issue. Additional Information: The trackpad itself appears to function normally. Physical clicks are detected. I have observed the issue in both Safari and Safari Technology Preview. I tested the same website in Perplexity Comet, where the issue does not appear to occur. This suggests the issue may be related to Safari’s rendering, hit-testing, event handling, or window management rather than the website itself. Has anyone else been able to reproduce this on macOS 27 Beta?

We are investigating a web application performance issue observed in iOS Safari/WKWebView after a recent iOS/Safari update. In the network waterfall, the main backend/document request completes within an acceptable time, but JavaScript resources appear to load late and in a more sequential pattern. We also noticed duplicate requests for some static JavaScript assets, which further delays full page rendering. The issue is more visible in iOS Safari/WKWebView compared with other browsers/environments.

Dear Apple Product Team, I would like to propose a usability enhancement for Safari on iOS that, in my opinion, would significantly improve the user experience. Current Situation: Currently, to change the default search engine in Safari, users must navigate to Settings → Safari → Search Engine, select their preferred option, and return to browsing. This workflow requires multiple taps and interrupts the user's flow. Proposed Solution: Add a quick search engine selector to the bottom toolbar in Safari (adjacent to the Smart Search field). Tapping this control would display a compact menu allowing users to instantly switch between available search engines (Google, DuckDuckGo, Bing, Yahoo, Ecosia, etc.) without leaving the browser. Key Benefits: ⚡️ Time-saving: Instant switching without navigating through Settings 🎯 Flexibility: Use different search engines for different query types (e.g., DuckDuckGo for privacy, Google for local results) 📱 Intuitive UX: Consistent with iOS design patterns and gesture-based navigation 🔧 Enhanced productivity: Streamlines research workflows for power users Implementation Suggestion: Long-press or tap-and-hold on the search field could trigger the selector Alternatively, a small chevron/icon next to the search field could open the menu Selected engine could persist per-tab or session-based, based on user preference I believe this feature aligns with Apple's commitment to privacy, efficiency, and user-centric design. Thank you for considering this suggestion for future iOS releases.

I'm building a macOS app that registers itself for HTTP(S) url handling and would like it to participate in the ASWebAuthenticationSession fow. I did: update the plist to register as a handler for URL shemes (http, https, file) use NSWorkspace setDefaultApplication API to set this app as a default handler for urls in question wrote custom ASWebAuthenticationSessionWebBrowserSessionHandling implementation and set it as SessionManager's sessionHandler I launched this app from Xcode, then I triggered authentication flow from a third-party app. When the sign in flow is initiated, I can see that my app is activeated (willBecomeActive and didBecomeActive callbacks are both called), but there is no call for sessionHandler's begin() method. With some additional debugging I see that my app receives an apple event when the flow is started: {sfri,auth target=SafariLaunchAgent {qntp=90/$627......},aapd=TRUE If I switch system default browser back to Safari and then start the login flow, it correctly displays a sign in web page. What do I miss? PS. I'm on Tahoe 26.2

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

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!

The application crashes immediately when the system attempts to display the automatic password input view controller (_SFAutomaticPasswordInputViewController). This occurs during the login or password-filling process. OS Version: iOS 26.2 Beta 1 Build Number: (23C5027f) Fatal Exception: NSInvalidArgumentException *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil

Currently I am struggling to find a way to read the status of Safari Web Extension from settings as I can not find any public api listed for iOS as it is already available for macOS.

I have observed Safari App starts crashing when running with my safari extension. Our Safari extension polls the host app every 60s. The extension receives and completes requests in func beginRequest(with context: NSExtensionContext) (we always call context.completeRequest(...)). The crash is intermittent: beginRequest itself does not throw. Looking for guidance about likely causes. I am attaching the snippet from crash report. Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace RUNNINGBOARD, Code 3490524077 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1856f5c34 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1857083a0 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x1856fe764 mach_msg_overwrite + 484 3 libsystem_kernel.dylib 0x1856f5fa8 mach_msg + 24 4 CoreFoundation 0x185822cbc __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1858215d8 __CFRunLoopRun + 1208 6 CoreFoundation 0x185820a98 CFRunLoopRunSpecific + 572 7 HIToolbox 0x1912c327c RunCurrentEventLoopInMode + 324 8 HIToolbox 0x1912c64e8 ReceiveNextEventCommon + 676 9 HIToolbox 0x191451484 _BlockUntilNextEventMatchingListInModeWithFilter + 76 10 AppKit 0x189745a34 _DPSNextEvent + 684 11 AppKit 0x18a0e4940 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 12 Safari 0x1b801cce4 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 228 13 AppKit 0x189738be4 -[NSApplication run] + 480 14 AppKit 0x18970f2dc NSApplicationMain + 880 15 Safari 0x1b83dd0b0 SafariMain + 468 16 dyld 0x185396b98 start + 6076

Hello everyone, We've had our app rejected twice under Guideline 3.2.2 regarding charitable donations, and we're seeking clarification on the correct implementation. We've read the guidelines but want to confirm the technical approach with the community's experience. The Rejection Reason: Apple states: "We still noticed that your app includes the ability to collect charitable donations within the app..." They specify that since we are not an approved nonprofit, we must use one of the alternatives, primarily: "provide a link to your website that launches the default browser or SFSafariViewController for users to make a donation." Our Current (Rejected) Implementation: User taps a "Help" button in our native app. A native modal appears inside our app where the user enters their donation amount and email address for the receipt. The user clicks "Donate," which then opens an SFSafariViewController to our website's payment page (e.g., Stripe, PayPal). The amount and email are passed as URL parameters to pre-fill the form. Our Questions for the Community: Is the issue solely the fact that we have a native modal for data entry? We understand we cannot process the payment in-app, but we thought collecting the intent (amount, email) was acceptable before handing off to Safari. What is the definitive, compliant flow? Option A: Should the "Help" button do nothing more than open an SFSafariViewController to a generic donations landing page on our website (https://ourwebsite.com/donate), with no data pre-filled? The user must then navigate and enter all information on the website itself. Option C: The rejection also mentions SMS. Has anyone had success implementing a "Text-to-Donate" link instead of a web flow? Wording: The button in our app currently says "Donate". Should this be changed to a more passive call to action like "Visit Website to Donate" to make it absolutely clear the transaction is external? We want to ensure our next submission is successful. Any insight, especially from developers who have successfully navigated this exact rejection, would be immensely helpful. Thank you.

Video in Landscape takes 2 taps on X to close.This issue can be replicated on iphone 14 ios 18.5.There is no issue on iPhone 15 ios 18.5.