System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
WebKit
RSS for tagDisplay web content in windows and implement browser features using WebKit.
Posts under WebKit tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
1. System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
2. System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
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.
It‘s called Track Configuration API found in the iOS 26.0 Public Beta 5. No explanation anywhere on the web Or release notes, it’s not mentioned anywhere. I‘m very interested in new tracking innovations.
And another small thing I‘ve never found out, what is „fingerprint related quirk“ is that an insider joke Or something? I don‘t know it‘s actions.
Thank you for answering
Hello,
In iOS 26 beta, we are seeing an unexpected behavior when using SwiftUI WebView (or a custom WKWebView via UIViewRepresentable).
When an alert is presented above the WebView, the WebView immediately reloads to its initial page. The alert itself also disappears instantly, making it impossible for the user to interact with it.
This issue occurs both with the new SwiftUI WebView / WebPage API and with a wrapped WKWebView. The problem was not present in previous iOS versions (iOS 17/18).
Steps to reproduce:
Create a SwiftUI view with a WebView (pointing to any URL).
Add a toolbar button that toggles a SwiftUI alert.
Run the app on iOS 26 beta.
Tap the button to trigger the alert.
Expected behavior:
The WebView should remain as-is, and the alert should stay visible until the user dismisses it.
Actual behavior:
As soon as the alert appears, the WebView reloads and resets to the initial page. The alert disappears immediately.
Minimal Example:
struct ContentView: View {
@State private var showAlert = false
var body: some View {
NavigationStack {
WebView(URL(string: "https://apple.com")!)
.toolbar {
ToolbarItem(placement: .topBarTrailing) {
Button("Close") {
showAlert = true
}
}
}
.alert("Confirm close?", isPresented: $showAlert) {
Button("Cancel", role: .cancel) {}
Button("Close", role: .destructive) {}
}
}
}
}
I'm using Xcode Version 26.0 beta 7
Thanks for your help.
Create an Installer Plug-in project and Add a WebView control to the pane’s .xib file.(Just the simple functionality of local HTML in reality.)
add .bundle file into Installer Package A.
Run Installer Package A on macOS 26.
Result: The WebView displays correctly, and the installation completes successfully, but the system produces crash reports.
I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up).
Here's a demo of the issue:
Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar):
Code:
struct ContentView: View {
var body: some View {
NavigationStack {
WebView(url: URL(string: "https://apple.com")).toolbar {
ToolbarItem(placement: .primaryAction) {
Button("Top content covered, unaccessible.") {}
}
}
}
}
}
Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?
Hello,
I need some help. I’m creating an application, but in fact it is just an instance of a web page built with WordPress and Elementor.
When submitting it for review, the following adjustment is required:
4.2.2 Design: Minimum Functionality
App example:
https://applink.com.br/appfortrade
Topic:
App Store Distribution & Marketing
SubTopic:
App Store Connect
Tags:
App Store
WebKit
HTML
Safari and Web
As you see in the image, when I fullscreen in WKWebView, it shows black instead of the webpage in full screen. It works fine in Sequoia. It has happened to me since beta 1, but I post it now, because we’re in beta 8 and it’s not fixed. What’s going on? Can somebody tell me if they have the same issue?
Hey,
very strange problem I have on iOS when shared web as an app (pwa) to home screen.
Whenever I use it via safari browser on iPhone, it works 100% fine every time. However, when I put it as an app on home screen, first time I open it it works fine, when i close it and reopen again, it just doesnt start recording. I have to restart my phone for it to work. So it works one time, I guess somehow it doesnt end stream or something, but in code I've tried all the possible ways to close and clean the track. tried GPT, Claude, Gemini solutions. nothing worked, it just works 1 time as PWA. my last hope is someone else encountered this issue and may try to help me ?
https://pastebin.com/85i2L2vH
I’ve got the new SwiftUi webview in a sheet. When I pull down the contents from the top of the page I expect it to dismiss the sheet, but it does not.
Is there a workaround or modifier I’m missing?
I'm creating an iPad app using Xcode 26 Beta 6. I have the following simple code and web page, but when I tap the file selection button, nothing appears. Do I need to add any additional code?
code
struct SwiftUIWebView: View {
@State private var webPage = WebPage()
private let url = URL(string: "https://www.xxxx.com/")!
var body: some View {
WebView(webPage)
.onAppear {
webPage.load(URLRequest(url: url))
}
}
}
web page
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Test</title>
</style>
</head>
<body>
<div id="container">
<input type="file" />
</div>
</body>
</html>
Since the ios 26 beta our app is crashing when calling LoadRequest() on the wkwebview class.
The app crashes out completely when it occurs even in the debugger, I was able to get a stack trace from our Sentry crash handler. See below
It seems that calling LoadRequest from the mainthread fixes the issue but I don't understand why, theres no documentation to suggest this must be done.
Any ideas?
Below is the stack trace I got from Sentry:
WebKit
+0x0054e00
WebKit::allDataStores
WebKit
+0x0bf34f4
WebKit::NetworkProcessProxy::preconnectTo
WebKit
+0x0acef64
WebKit::WebPageProxy::preconnectTo
WebKit
+0x0b0d92c
WTF::Detail::CallableWrapper::call
WebKit
+0x0ab6cf8
WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle
WebKit
+0x0ab84dc
WebKit::WebPageProxy::loadRequestWithNavigationShared
WebKit
+0x0ab7adc
WebKit::WebPageProxy::loadRequest
WebKit
+0x05d0704
-[WKWebView loadRequest:]
Grid3iOS
+0x5240944
xamarin_dyn_objc_msgSendSuper
In App
Grid3iOS
+0x187dec4
wrapper_managed_to_native_ObjCRuntime_Messaging_NativeHandle_objc_msgSendSuper_NativeHandle_intptr_intptr_ObjCRuntime_NativeHandle
In App
Grid3iOS
+0x512fac4
Microsoft_iOS_WebKit_WKWebView_LoadRequest_Foundation_NSUrlRequest (WKWebView.g.cs:572)
If we use webView.loadFileURL(indexURL, allowingReadAccessTo: readAccessURL) on an iPad it loads the data and navigation works.
But if we place two hands on top of the screen and move a bit, all click events are not working anymore.
It works again if we call loadFileURL again.
We filled a bug report:
FB19812304
On iOS 26 Beta, WKWebView consistently crashes when interacting with pages that use -webkit-user-select: none.
This issue does not reproduce in Safari, but only when the same content is loaded inside a WKWebView.
Steps to Reproduce:
Install iOS 26 Beta.
Open a WKWebView that loads a webpage with the following style applied globally:
-webkit-user-select: none;
Perform the following gesture sequence inside the WKWebView:
Double tap anywhere in the web content.
On the second tap, keep your finger pressed (do not lift).
While still holding the second tap, drag your finger across the screen (pan).
This sequence reliably produces the crash.
Expected Result:
No crash. The gesture should either be ignored or handled gracefully.
Actual Result:
The app crashes 100% of the time with the following exception:
#0 0x000000013f1a0874 in __pthread_kill ()
#1 0x00000001357522ec in pthread_kill ()
#2 0x00000001801ad950 in abort ()
#3 0x00000001802fa26c in __abort_message ()
#4 0x00000001802ea1a4 in demangling_terminate_handler ()
#5 0x0000000180077218 in _objc_terminate ()
#6 0x00000001802f9758 in std::__terminate ()
#7 0x00000001802fc7c0 in __cxxabiv1::failed_throw ()
#8 0x00000001802fc7a0 in __cxa_throw ()
#9 0x000000018009c1bc in objc_exception_throw ()
#10 0x00000001804f38f8 in +[NSException raise:format:] ()
#11 0x000000018c5fb570 in -[CALayer setPosition:] ()
#12 0x0000000185d02414 in -[UIView _backing_setPosition:] ()
#13 0x00000001867ec978 in -[UIView setCenter:] ()
#14 0x0000000186666468 in -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ()
#15 0x0000000186666088 in __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke ()
#16 0x00000001867b3ed4 in -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] ()
#17 0x0000000186665fb0 in -[_UIEditMenuContentPresentation _displayMenu:reason:] ()
#18 0x0000000186665de4 in -[_UIEditMenuContentPresentation displayMenu:configuration:] ()
#19 0x00000001867b3260 in __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ()
#20 0x00000001867b4c98 in __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ()
#21 0x000000018653ff80 in __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ()
#22 0x0000000186540448 in __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke ()
#23 0x000000018dba84f8 in WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call ()
#24 0x000000018dca14cc in WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call ()
#25 0x000000018e2d5c54 in IPC::Connection::dispatchMessage ()
#26 0x000000018e2d6118 in IPC::Connection::dispatchIncomingMessages ()
#27 0x00000001997f9c58 in WTF::RunLoop::performWork ()
#28 0x00000001997fa930 in WTF::RunLoop::performWork ()
#29 0x000000018044d4dc in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#30 0x000000018044d424 in __CFRunLoopDoSource0 ()
#31 0x000000018044cc0c in __CFRunLoopDoSources0 ()
#32 0x000000018044bd84 in __CFRunLoopRun ()
#33 0x0000000180446e24 in _CFRunLoopRunSpecificWithOptions ()
#34 0x00000001924c19bc in GSEventRunModal ()
#35 0x00000001862217a8 in -[UIApplication _run] ()
#36 0x00000001862259d0 in UIApplicationMain ()
Same issues below.
https://developer.apple.com/forums/thread/796799
https://developer.apple.com/forums/thread/796501
https://developer.apple.com/forums/thread/796874
https://developer.apple.com/forums/thread/796686
現在新しいWebViewを使ってwebページを読み込むiPadプログラムを作成中ですが、読み込んだ後に部分のボタンをタップしても何も起こりません。safariで通常通りページを開いてボタンをタップするときちんと写真ライブラリ・カメラで撮るなどのポップアップが表示されます。下記がコードです。Webページは単純化のためにのみを配置しています。
struct SwiftUIWebView: View {
@State private var webPage = WebPage()
private let url = URL(string: "https://www.****.com/")!
var body: some View {
WebView(webPage)
.onAppear {
// URLを読み込む
webPage.load(URLRequest(url: url))
}
}
}
何か追加のコードが必要なのでしょうか？
Hello,
I am experiencing an issue when trying to open the browser on my Apple Watch SE 2 running the latest version, watchOS 11.6. When I attempt to visit any website, the browser opens and displays the URL at the top as if it is loading, but the screen remains black and no content is displayed.
The internet connection is available, and all other apps on the watch work normally. This issue occurs only with the browser.
I would appreciate any guidance or solution to resolve this problem.
Thank you for your assistance.
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
Steps to Reproduce:
Open the Bing search page in Safari (example URL: https://www.bing.com/search?q=webkit&form=APIPH1&PC=APPL).
Pinch-zoom in or out, then return the page to exactly 100% zoom.
Rotate the device from portrait to landscape orientation.
Observe that the page is incorrectly scaled to a value other than 100%.
Rotate the device back to portrait orientation.
The page remains at the incorrect zoom level.
Expected Result:
After returning the page to 100% zoom, changing orientation should keep the zoom level at exactly 100% in both portrait and landscape modes.
Actual Result:
After returning to 100% zoom, rotating to landscape changes the zoom to a non-100% value, and rotating back to portrait retains the incorrect zoom level.
Hi, we are trying to move an existing application to a Web based SPA architecture with majority of the screens written in JS opening in a webview and using native bridges for the Hardware components.
Before proceeding ahead, we just wanted to be sure that these kinds of applications are generally approved by Apple or not. If not, what are the guidelines to be followed if one wants to create an SPA application for iOS.
PS: The content that will be served in web view would be controlled and hosted within the organisation domain and whitelisted for the mobile app only.
Topic:
App Store Distribution & Marketing
SubTopic:
App Review
Tags:
WebKit JS
WebKit
Safari and Web