Thank you for supporting me.
My environment
Device: iPhone 15 Pro
OS: iOS 26.0 Public Beta (23A5336a)
In iOS 26, three types of tabs were added to Safari.
Depending on the option, the behavior of the fixed header and footer can be unstable.
*Tab settings can be changed in the iOS Settings app under "Apps -> Safari" > "Tabs."
The following behavior differs depending on the tab.
Compact
When scrolling down, the header and footer shift up by a few pixels.
A margin is created between the footer and the URL input field.
Bottom
Behaves the same as "Compact."
Top
The header is completely hidden below the URL input field at the top of the screen, leaving a margin below the footer.
Below is the sample code to check the operation.
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>固定ヘッダー/フッター + モーダル</title>
<style>
:root {
--header-h: 56px;
--footer-h: 56px;
}
body {
margin: 0;
font-family: sans-serif;
line-height: 1.6;
background: #f9fafb;
padding-top: var(--header-h);
padding-bottom: var(--footer-h);
}
header .inner, footer .inner {
width: 100%;
max-width: var(--max-content-w);
padding: 0 16px;
display: flex;
align-items: center;
justify-content: space-between;
}
header, footer {
position: fixed;
left: 0; right: 0;
display: flex; align-items: center; justify-content: center;
z-index: 100;
background: #fff;
}
header {
top: 0;
height: var(--header-h);
border-bottom: 1px solid #ddd;
}
footer {
bottom: 0;
height: var(--footer-h);
border-top: 1px solid #ddd;
}
main {
padding: 16px;
}
.btn {
padding: 8px 16px;
border: 1px solid #2563eb;
background: #2563eb;
color: #fff;
border-radius: 6px;
cursor: pointer;
}
/* モーダル関連 */
.modal {
position: fixed;
inset: 0;
display: none;
z-index: 1000;
}
.modal.is-open { display: block; }
.modal__backdrop {
position: absolute;
inset: 0;
background: rgba(0,0,0,0.5);
}
.modal__panel {
position: relative;
max-width: 600px;
margin: 10% auto;
background: #fff;
border-radius: 8px;
padding: 20px;
z-index: 1;
}
.modal__head {
display: flex; justify-content: space-between; align-items: center;
margin-bottom: 12px;
}
.modal__title { margin: 0; font-size: 18px; font-weight: bold; }
.modal__close {
background: none;
border: none;
font-size: 20px;
cursor: pointer;
}
</style>
</head>
<body>
<header>
<div class="inner">
<h1>デモページ</h1>
<button id="openModal" class="btn">モーダルを開く</button>
</div>
</header>
<main class="container" id="main">
<h2>スクロール用の適当なコンテンツ1</h2>
<p>ヘッダーとフッターは常に表示されます。モーダルボタンを押すと、画面いっぱいのダイアログが開きます。</p>
<!-- ダミーカードを複数 -->
<section class="grid">
<div class="card"><strong>カード1</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード2</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード3</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード4</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード5</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード6</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード7</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード8</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード9</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
<div class="card"><strong>カード10</strong><p>適当なテキスト。適当なテキスト。適当なテキスト。</p></div>
</section>
</main>
<footer>
<small>© 2025 Demo</small>
</footer>
<!-- モーダル -->
<div class="modal" id="modal">
<div class="modal__backdrop"></div>
<div class="modal__panel">
<div class="modal__head">
<h2 class="modal__title">モーダル</h2>
<button class="modal__close" id="closeModal">×</button>
</div>
<p>これは白いビューのモーダルです。背景は黒く半透明で覆われています。</p>
</div>
</div>
<script>
const modal = document.getElementById('modal');
const openBtn = document.getElementById('openModal');
const closeBtn = document.getElementById('closeModal');
const backdrop = modal.querySelector('.modal__backdrop');
openBtn.addEventListener('click', () => {
modal.classList.add('is-open');
});
function closeModal() {
modal.classList.remove('is-open');
}
closeBtn.addEventListener('click', closeModal);
backdrop.addEventListener('click', closeModal);
window.addEventListener('keydown', (e) => {
if (e.key === 'Escape' && modal.classList.contains('is-open')) {
closeModal();
}
});
</script>
</body>
</html>
Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
window.location.href = "tel:02-xxxx-xxxx"
Can the development team modify the screen text? Or can the country code be erased?
What are the reasons for continuing to be "on the phone" if the country code is automatically attached to the phone like this?
Topic:
Safari & Web
SubTopic:
General
hi
Testing on OS26 Public Beta 6.
In Safari, if you enter x homepage and scroll, the tab bar sticks to the bottom and moves.
Make the keyboard appear in the search window
When scrolling down on the Safari homepage again, the issue of not being able to stick to the bottom appears.
Is it because the liquid glass UI was applied this time? and safari bug?
Please let me know if I'm missing anything
Topic:
Safari & Web
SubTopic:
General
window.location.href = 'tel:0216700310'; I ran the code in an IOS environment. The number was displayed when the call button on the device appeared. However, other IOS devices besides some devices came out as a number starting with +82, and I received feedback that the call was not connected properly. I wonder what could be caused by only some devices. And I would also like to ask what can be done to allow the numbers on the code to be displayed and called as they are.
Topic:
Safari & Web
SubTopic:
General
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.
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 all,
As you may know, the company ProofPoint is an Apple partner, and is engaged (I think) to reduce misuse of icloud emails.
We have two servers solely set up for our web-app, which is a specialised forum for apartment owners.
The new servers were established about the same time, with the same provider, with clean new IP addresses - and as mentioned above, are only used for this web-app.
During a testing phase a YEAR ago, we became aware that our in-house icloud emails weren't receiving notifications via the app, and further investigations revealed that the cause was that ProofPoint had placed a block on that server's IP.
We immediately, via their website form initiated a Support Ticket, which, the site indicated was lodged, BUT we have never received any response to that Ticket, nor have we received any response to four subsequent Tickets we initiated - nothing. In over a year!!
Yesterday, we contacted Apple support, but the devices area of support is the main section and they said it wasn't an issue they could assist with.
Some relevant matters:
SPF: DKIM: DMARC:
are, I believe all configured correctly (and Gmail gives a PASS to all of them).
The IP is not blacklisted by any list we are aware of.
Our other server's IP isn't blocked by ProofPoint.
So, literally at wits end, I'm reaching out to the developer subscribers here to see if they have any suggestions for us.
We currently are unable to accept any new subscriber that is using an icloud email address, and that's an absurd situation to be in.
Surely we don't have to go to the trouble and inconvenience of obtaining a new IP because of this!!! But when we can't get ANY response to the Support Tickets, it's really hard.
Thanks
Topic:
Safari & Web
SubTopic:
General
Hi everyone,
We’ve recently run into an issue with Apple Pay on the web and would appreciate some clarification.
Background:
Previously, we integrated Apple Pay without using the Apple Pay JS SDK.
We relied on ApplePaySession.canMakePayments() to check availability, and it worked fine.
After Apple announced support for browsers beyond Safari, we switched to the Apple Pay JS SDK.
According to Apple’s documentation, we should now use applePayCapabilities() for capability checks in third-party browsers.
Our current behavior:
We implemented applePayCapabilities().
Initially, it was returning either paymentCredentialStatusUnknown or paymentCredentialsUnavailable.
Based on those values, we displayed the Apple Pay button.
The problem:
About a week ago, on the same device/browser, applePayCapabilities() started returning applePayUnsupported.
Setup: MacBook Pro 13-inch (M1, 2020), Google Chrome Version 136.0.7103.93.
The Apple documentation says: “Don’t show an Apple Pay button or offer Apple Pay” when the result is applePayUnsupported.
However, at the same time, canMakePayments() is returning true.
This creates a direct conflict between the two recommendations:
canMakePayments() → true ⇒ show the button.
applePayCapabilities() → applePayUnsupported ⇒ don’t show the button.
Question:
What’s the correct approach here?
Should we prioritize applePayCapabilities() and hide the button, or is it acceptable to continue relying only on canMakePayments() as the source of truth for showing Apple Pay?
Any insights from others who’ve run into this contradiction would be very helpful.
Thanks in advance!
I'm experiencing a Safari Web Extension issue where the non-persistant background script seems to crash after 30 seconds even when the content script is messaging it.
Here is a minimal-reproducible example. When running in an emulator, the background script will stay responsive forever. However, when running on a physical device, the background script becomes non-responsive after 30 seconds of activity. It never becomes responsive again until I toggle the extensions enable/disable toggle, after which it stays active for 30 seconds and then crashes again.
We are encountering an issue where the Safari extension we are developing stops working while in use on relatively new iOS versions (confirmed on 17.5.1, 17.6.1, and 18). Upon checking the Safari console, the content script is displayed in the extension script, so the background script or Service Worker must be stopping. The time until it stops is about 1 minute on 17.5.1 and about one day on 17.6.1 or 18.
When it stops, we would like to find a way to restart the Service Worker from the extension side, but we have not found a method to do so yet. To restart the extension, the user needs to turn off the corresponding extension in the iPhone settings and then turn it back on.
As mentioned in the following thread, it is written that the above bug was fixed in 17.6, but we recognize that it has not been fixed. https://forums.developer.apple.com/forums/thread/758346
On 17.5.1, adding the following process to the background script prevents it from stopping for about the same time as on 17.6 and above.
// Will be passed into runtime.onConnect for processes that are listening for the connection event
const INTERNAL_STAYALIVE_PORT = "port.connect";
// Try wake up every 9S
const INTERVAL_WAKE_UP = 9000;
// Alive port
var alivePort = null;
// Call the function at SW(service worker) start
StayAlive();
async function StayAlive() {
var wakeup = setInterval(() => {
if (alivePort == null) {
alivePort = browser.runtime.connect({ name: INTERNAL_STAYALIVE_PORT });
alivePort.onDisconnect.addListener((p) => {
alivePort = null;
});
}
if (alivePort) {
alivePort.postMessage({ content: "ping" });
}
}, INTERVAL_WAKE_UP);
}
Additionally, we considered methods to revive the Service Worker when it stops, which are listed below. None of the methods listed below resolved the issue.
①
Implemented a process to create a connection again if the return value of sendMessage is null. The determination of whether the Service Worker has stopped is made by sending a message from the content script to the background script and checking whether the message return value is null as follows.
sendMessageToBackground.js
let infoFromBackground = await browser.runtime.sendMessage(sendParam);
if (!infoFromBackground) {
// If infoFromBackground is null, Service Worker should have stopped.
browser.runtime.connect({name: 'reconnect'}); // ← reconnection process
// Sending message again
infoFromBackground = await browser.runtime.sendMessage(sendParam);
}
return infoFromBackground.message;
Background script
browser.runtime.onConnect.addListener((port) => {
if (port.name !== 'reconnect') return;
port.onMessage.addListener(async (request, sender, sendResponse) => {
sendResponse({
response: "response form background",
message: "reconnect.",
});
});
②
Verified whether the service worker could be restarted by regenerating Background.js and content.js.
sendMessageToBackground.js
export async function sendMessageToBackground(sendParam) {
let infoFromBackground = await browser.runtime.sendMessage(sendParam);
if (!infoFromBackground) {
executeContentScript(); // ← executeScript
infoFromBackground = await browser.runtime.sendMessage(sendParam);
}
return infoFromBackground.message;
}
async function executeContentScript() {
browser.webNavigation.onDOMContentLoaded.addListener((details) => {
browser.scripting.executeScript({
target: { tabId: details.tabId },
files: ["./content.js"]
});
});
}
However, browser.webNavigation.onDOMContentLoaded.addListener was not executed due to the following error.
@webkit-masked-url://hidden/:2:58295
@webkit-masked-url://hidden/:2:58539
@webkit-masked-url://hidden/:2:58539
③
Verify that ServiceWorker restarts by updating ContentScripts
async function updateContentScripts() {
try {
const scripts = await browser.scripting.getRegisteredContentScripts();
const scriptIds = scripts.map(script => script.id);
await browser.scripting.updateContentScripts(scriptIds);//update content
} catch (e) {
await errorLogger(e.stack);
}
}
However, scripting.getRegisteredContentScripts was not executed due to the same error as in 2.
@webkit-masked-url://hidden/:2:58359
@webkit-masked-url://hidden/:2:58456
@webkit-masked-url://hidden/:2:58456
@webkit-masked-url://hidden/:2:58549
@webkit-masked-url://hidden/:2:58549
These are the methods we have considered. If anyone knows a solution, please let us know.
Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!).
In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS.
Once dead, nothing a normal user would do can wake the service worker back up:
No events like webNavigation or similar will trigger anymore
Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately
Closing and opening Safari does not start it again
The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly.
There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail.
It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing
"background": {
"service_worker": "service.js"
}
to
"background": {
"scripts": ["service.js"],
"persistent": false
}
With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field).
According to the release notes of 17.6 beta this bug was supposedly fixed:
“Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)”
However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6.
Has there been a change in policy about service workers and background scripts for Safari in iOS?
Are anyone else seeing this issue?
Also seemingly related:
https://forums.developer.apple.com/forums/thread/756309
https://forums.developer.apple.com/forums/thread/750330
https://developer.apple.com/forums/thread/757926
https://forums.developer.apple.com/forums/thread/735307
Hi everyone, i'm running into a problem with my personal domain being flagged as 'deceptive website' in safari, and i can't figure out how to fix it
Domain: neon0404.space
This is just my personal domain - i use it for adguard home, vaultwarden, some test stuff, sometimes small web tools for friends or family
Nothing illegal or malicious has ever been hosted there
On july 6, i launched a very simple web utility for a friend
when he opened it on ios safari, he got the red 'deceptive website warning'
I checked this on other different devices - all got the same warning
The next day (july 7) i submitted a review request via websitereview.apple.com, but got no reply
I did some digging and found that safari safe browsing daemon pulls data from google safe browsing, tencent safe browsing, and some apple's internal lists
So, going one-by-one
https://transparencyreport.google.com/safe-browsing/search showed up that domain is flagged for something shady
Signed up in google search console and saw my domain was flagged for 'malware links' (with no related urls listed), so looked like a false positive
I audited everything related to this domain on august 5 - nothing suspicious
Next day i requested a review in Google Search Console, just next day Google confirmed that everything is ok and removed the flag
So, i thought, maybe this was the key and requested another review via websitereview.apple.com (august 7)
No reply, domain still flagged
While i was waiting, i checked domain in Tencent (https://urlsec.qq.com/check.html) - no issues
Other services like VirusTotal, Norton and Sucuri showed up same result - no issues
I attempted to contact regular support (even though it's not their area of responsibility), but just in case
They, as expected, couldn't do anything
At this point it feels like a dead end, so i'm here
Has anyone been through this before?
Is there any other way to escalate the review process with apple?
Really appreciate any advice, as this domain is personal and linked to my username, which i want to use later
Hi,
We’re implementing Apple Pay on the Web for a multi-tenant platform via a PSP. The PSP operates multiple HSM/clusters and gave us multiple CSRs, asking us to register all.
Our understanding: a Merchant ID can hold several PPCs over time, but only one is active at once.
Questions
Is there any supported way to keep more than one PPC active simultaneously for the same Merchant ID?
If not, what does Apple recommend for web-only, multi-tenant setups: a single MID with PSP-side decryption & sub-merchant separation, or separate MIDs per brand/region?
Any official guidance on PPC rotation and handling many domains for Apple Pay on the Web?
links to official docs or prior Apple responses would be appreciated.
ios26beta8 mesh不切换
Topic:
Safari & Web
SubTopic:
General
Hello,
We are setting up Apple Sign In in one of our non production websites but we keep getting a "oauth code says expired or revoked" error. We have created a brand new service ID and key for this but are still getting this error.
Topic:
Safari & Web
SubTopic:
General
I’m experiencing an issue in WKWebView on iOS 26 Developer Beta 8. If a view's subview contains a WKWebView, using the CALayer's renderInContext method fails to capture the pixel at the current point, and the console outputs "unsupported surface format: &b38".
The following code snippet was functioning as expected on iOS 18 and iOS 26 beta 1. However, it no longer works in the latest beta.
Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?
- (BOOL)isTransparentAtTouchPoint:(CGPoint)point layer:(CALayer *)layer {
unsigned char pixel[4] = {0};
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef context = CGBitmapContextCreate(pixel, 1, 1, 8, 4, colorSpace, (CGBitmapInfo) kCGImageAlphaPremultipliedLast);
CGContextTranslateCTM(context, -point.x, -point.y);
[layer renderInContext:context];
CGContextRelease(context);
CGColorSpaceRelease(colorSpace);
CGFloat alpha = pixel[3] / 255.0f;
return alpha < 0.01;
}
Area: WebKit (Safari)
Description:
I am reporting an issue where our application's core functionality is being broken by Safari's Intelligent Tracking Prevention (ITP).
ITP's "Link Tracking Protection" feature automatically strips specific query parameters from URLs. We understand this is an intentional privacy feature. However, our application requires these query parameters to carry essential, non-tracking data, such as authentication tokens or specific app-state information to function correctly.
When a user navigates to our site, Safari strips these parameters, this means our client-side application never receives the necessary data, which breaks core features and leads to a failed user experience. This is a significant issue for our application as it prevents users from accessing their content.
We are seeking guidance on how to resolve this.
Questions for Apple:
Is there a recommended way to identify and flag essential, non-tracking query parameters so that Safari's ITP does not strip them?
Our parameters are critical for app functionality, not for third-party tracking. What is the recommended best practice for building web applications that rely on URL parameters while adhering to ITP's privacy-first model?
We want to ensure our application is compatible with modern browser privacy features without compromising functionality.
Could you provide a detailed explanation of what criteria ITP uses to decide which parameters to strip? Understanding the underlying logic would help us restructure our URLs to avoid this issue.
Device Information:
Operating System: iOS and macOS
Safari Version: Latest stable versions on both platforms
Device Models: All relevant models and device types
Topic:
Safari & Web
SubTopic:
General
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?
WebAuthn can be used in Safari, but when using it with WKWebView, you need to set the default browser definition (com.apple.developer.web-browser). Is this correct?
Also, is it possible that the terms of use will change or that it will no longer be available in WKWebView in the future?
Topic:
Safari & Web
SubTopic:
General
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