<rdar://problem/153131340>

Thanks for reporting this. I tried to override this for an app control (WKWebView, UIWebView) is hardcoded to 60fps last time I tested. But... It was still hard-capped to 60fps -- even if Info.plist setting for CADisableMinimumFrameDurationOnPhone is set. So yes it is a blocker for my ability to release a TestUFO app in the Apple App Store.

+1 for this, I have a painting app that uses webView, it would be great to have 120hz for smoother painting strokes, ideally without the user having to switch a feature flag.

I'd even settle for a feature flag -- the feature flag doesn't even fix this problem at all. As a native app, I can detect a 120Hz device running at only 60Hz, and automatically a dialog with an "Instructions" button (display step by step instructions). There's a redesign of TestUFO underway that makes it more smartphone-friendly despite being originally designed as a desktop/tablet website, and a smartphone app launch would be perfect timing for my TestUFO layout retheming launch at end of year.

If i’m not mistaken, this is the only reason Geforce Now does not offer 120fps support on iOS, iPadOS, and at least 90fps on the Vision Pro. Also has the 60fps lock been confirmed on iOS 26? I get 120fps when installing testufo as a Web App on iOS 26. I would think iOS automatically uses WKWebView for the web app. So maybe iOS 26 fixes this??

> I get 120fps when installing testufo as a Web App on iOS 26 Did you change the "Prefer Page Rendering Updates Near 60fps" setting though? I get 60fps in a Home Screen web app with default settings.

> Did you change the "Prefer Page Rendering Updates Near 60fps" setting though? Yes I changed “Prefer Page Rendering Updates Near 60fps" to Off and then I get 120fps in the web app. Which makes me wonder if with iOS 26 WKWebView does support 120fps if the feature flag is disabled? Another note: If you install testufo as a web app on macOS 26, you will get 60fps even with the above feature flag disabled. It’s possible forced web apps (websites that were not designed specifically to be a web app and the OS automatically wraps it as one) are installed differently on macOS and iOS and one uses WKWebView while the other does not.

I think we should be careful not to mix different concepts here. The original request was about "hybrid apps using WKWebView under the hood" (like capacitor by ionic) rather than web apps (talking about PWAs). Even though there might be an issue concerning web apps too, I could understand the usage of the safari flag there, but not concerning separate apps downloaded on the App Store that use WKWebView. I think those apps should be able to stand alone.

I dont know if macOS 26 fixes it but... The MacOS before it has the problem of where you intentionally configure the Mac everywhere to turn off "Prefer Page Rendering Updates Near 60fps", you have webapp 120fps but WKWebView 60fps. In other words, the same tweak doesn't apply equally to webapps and WKWebView. In other words, webapps are defacto icons that launch a UI-less Safari browser (Apple executable) and WKWebView is a UI control compiled into your own application binary (your own executable with your own .plist file).

I would like to +1 this request. At Ink & Switch, we're researching novel interfaces for notebook apps using the iPad Pro and Pencil Pro as test hardware. We use a hybrid of Swift (for input handling) and a WKWebView with JS code (for most logic and rendering). The 60Hz refresh rate meaningfully degrades the quality of experience when writing and drawing with the Pencil, compared to 120Hz.

Is there any update? Tauri still can't reach 120 fpx.

Bump. Understand that 60fps should be default to conserve battery but please add a flag to enable 120hz, especially for pencil responsiveness this would be a huge improvement.

## Accidental Unintended Apple Enshittification of 120 Hz Also, while my MacBook is my primary TestUFO software development machine, Apple has been (kind of) accidentally enshittfying 120Hz due to: - Slow 120 Hz displays without overdrive (MacBook LCDs, and XDR desktop LCD) - Abysmally slow pixel response so 60Hz versus 120 Hz is only a 1.1x difference. - Safari "Prefer Page Rendering Updates Near 60fps" hides user demos - Lack of 120 Hz support in WKWebView. This reduces pressure for standards discussion, because of status quo Consequently, many can't really see much benefit of 60vs120, in a world where a blind study showed 120 Hz OLED vs 480 Hz OLED is more human-visible than 60Hz LCD vs 120Hz LCD. So there are some missed ergonomic opportunities of 120 Hz too. Many observe more noticeable ergonomic benefits for 60 vs 120, and even for 60 vs 240 differences when it comes to OLEDs, particularly the latter.

I've made a game that runs so optimally it could easily run at 120Hz, I'd love people to be able to play it that way.

A year on, this keeps coming up — both in this thread and across the hybrid app ecosystem (Capacitor, Ionic, Tauri), especially for drawing/stylus and other latency-sensitive apps where the 60Hz cap is directly perceptible next to native apps on the same device. It's gotten to the point where the community is brute-forcing it: there are now published plugins for both Capacitor and Tauri that unlock 120Hz by calling private WebKit API (flipping internal preferences, CADisplayLink pacing, _updateVisibleContentRects). The demand is clearly real, and private-API workarounds shipping in apps seems like the worst outcome for everyone — fragile for developers, unsupported surface for WebKit. What makes it frustrating is that every other context has a path: native apps got preferredFrameRateRange in iOS 15, Android WebView has a public API for it, and Safari runs accelerated CSS animations at full refresh rate. Embedded web content is the one place with no option at all. Even just an opt-in — with 60Hz staying the default — would resolve this for everyone here. Would really appreciate this getting another look.

+1 this would be immense, its very frustrating that a pwa can have better performance then my native app, just because its wrapped. I have to compromise with my drawing app.

WebKit already has the internal preference PreferPageRenderingUpdatesNear60FPSEnabled, along with the implementation needed to render WKWebView content at a high frame rate. I also tested it on a physical device. Disabling this preference easily allows the WKWebView to reach 120 FPS, while the default behavior remains around 60 FPS. So it looks like the main missing piece is a supported public API for embedders. I’d be happy to work on implementing this API if maintainers are open to accepting it. I’d also appreciate guidance on the API shape — for example, whether it should be a Boolean preference on WKPreferences, a frame-rate policy/range, or something else. Maybe this be a reasonable contribution to pursue?

Another thing missing is making it easier for websites to opt-in. Like a Full Screen Permission Request, or a Window Management API Permission Request. "This webpage is requesting access to high performance frame rates at full display refresh rate. Animations will be smoother and more ergonomic. However, more battery power will be consumed." [ALLOW] [DENY] On some displays (e.g. large-screen OLED), some people get more nausea with 60fps animations than 120fps animations, so it's also an ergonomic regression to keep it 60fps default with no ability for web authors (games, testufo, etc) to ask for permission.

[Note -- I am in over 50 research papers. Some of the science behind display-ergonomics is where on big displays, OLED pixel response is so fast, that motion fluidity threshold is equalized to the flicker fusion threshold. In other words, 60fps on large-format OLEDs can look as stuttery on 40fps on LCDs, creating an ergonomic problem with a 60fps cap on ultra high performance displays. This is precisely also why Apple Vision Pro uses 120fps default out of the box. It's an assumption that once Apple releases large-format OLEDs, they may reconsider fixing this ergonomic regression]

[Clarification: Due to its high performance wide-FOV OLED -- Apple Vision Pro's Safari has this Prefer60 setting turned off, defaulting to 120fps in Safari out of box -- to avoid this ergonomic motionsickness regression]

At Scirra we're interested in this to allow high framerate support for content published with Construct 3 (https://www.construct.net/).