Actually this is a duplicate for https://developer.apple.com/forums/thread/106537 but in web-specific forums section.
Is there any video/audio codec best practices, guides, recommendations for app/web developers for best performance (take advantage from HW acceleration), power consumption saving? What are officially supported media containers? What are video encoding profiles, video dimensions, frame rates?
The only official source I have found is https://developer.apple.com/documentation/webkit/delivering-video-content-for-safari?language=objc. But h264 is pretty old. I experimentally found that the VP9 video format is also supported on iOS newer versions. But is this a requirement? Сan i be sure that the video will play on all devices?
My goal is to provide web media content (which will be rendered in my application using WKWebView API) that will be supported by most devices (both iOS and MacOS), takes advantage of such features as hardware decode acceleration and be efficient.
Any hints/info is highly appreciated. Best regards.
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
Hello, why is Safari blocking my domains? https://fitgel.ru https://fittoma.ru https://ohota.pro There are no errors in them, other browsers respond normally.
Topic:
Safari & Web
SubTopic:
General
現在新しい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))
}
}
}
何か追加のコードが必要なのでしょうか？
I created a form field using:
On Safari and Chrome desktop, it behaves as expected. Safari shows the current date in grey by default, and Chrome displays a format hint like dd.mm.yyyy, which is perfectly fine.
On iOS, however, the field appears completely blank. I understand that the placeholder attribute is not part of the iOS date input behavior, which is technically fine. Still, it would be helpful if developers had the option to define a default display value. In the past, browsers prefilled date inputs, but many developers objected because they needed the field to be empty by default.
I have searched extensively and tried several AI tools, and everywhere it says that this cannot be changed. Am I missing something, or is there any way to display a placeholder, the current date, or some kind of visual hint in iOS Safari?
Right now, the empty field creates poor UX because users may overlook it. Since the field is required, this can easily lead to validation errors and additional friction.
As a workaround, I used a CSS hack with input[type="date"]::before and a content attribute. I also added JavaScript to toggle a pseudo-placeholder value specifically for iOS.
Is there a cleaner solution that avoids this workaround?
Thanks in advance for your guidance.
We are experiencing a problem that seems to be caused by a specification changes for Safari.
We would like to discuss how to solve this problem.
Sample JavaScript:
<html>
<head>
<script>
function jumpPage(code) {
document.main.code.value = code;
win1=window.open("","win1","toolbar=no,resizable=yes,menubar=no,scrollbars=yes,status=yes,left=0,top=0");
win1.resizeTo(width=screen.availWidth,height=screen.availHeight);
document.main.action="details";
document.main.target="win1";
document.main.submit();
}
</script>
</head>
<body>
<form name="main" method="post" action="" target="">
<a href="javascript:jumpPage('001')">details</a>
<input type="hidden" name="code" value="">
</body>
</html>
This JavaScript performs the following actions when a link is clicked.
Open a window using window.open in JavaScript
Submit the above opened window by post method to the target in JavaScript.
When this operation is performed, the process in (2) could submit to the
target page with “POST” method before iOS18.1, but
will transition to the page with“GET”method from iOS18.2 onward.
All protocols are http.
This problem does not occur if the URL is specified as an IP address, but it does occur if the host name is specified as.
Please let me know how to use with“POST”method as in iOS 18.2 or earlier.
Best regards,
Topic:
Safari & Web
SubTopic:
General
Our app uses ASWebAuthenticationSession for login.
This launches an incognito (ephemeral) browser window of the system’s default browser with the authentication URL.
Recently, on the latest macOS Tahoe, we observe that:
The browser application is launched(we could see in the dock)
But the authentication window with the URL does not appear
No error is returned to the app (silent failure)
我使用Apple Pay on the Web Interactive Demo构建了一个web应用使用的是Payment Request API方式，但是遇到了几个问题：
拉起的web Apple Pay 底部一直转圈圈无法付款，这个是什么问题？
如何设置sandbox测试付款呢？
如何异步、同步获取支付结果（后端代码获取支付结果）？demo只有await response.complete("success");前端代码获取支付结果的操作
demo网址: https://shop.wowseer.com/rsolomakhin/pr/applepay/
In WKWebView, there is the WKUIDelegate method:
func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {}
This delegate method provides a callback when a new window (for example, target="_blank") is requested in the web view.
However, in native SwiftUI (iOS 26), WebView / WebPage APIs do not provide an equivalent delegate method to handle new window requests.
As a workaround, I am using the following method:
public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {}
In this method, when action.target == nil, I treat it as a new window request.
My question:
Is relying on action.target == nil in decidePolicy a reliable and future-safe way to detect new window requests in SwiftUI’s WebView, or is there a better or more recommended approach for handling target="_blank" / new window navigation in the SwiftUI WebView APIs?
Code:
public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {
guard let webPage = webPage else { return .cancel }
// Handle case where target frame is nil (e.g., target="_blank" or window.open)
// This indicates a new window request
if action.target == nil {
print("Target frame is nil - new window requested")
// WORKAROUND: Until iOS 26 WebPage UI protocol is available, we handle new windows here
// Try to create a new WebPage through UI plugins
if handleCreateWebPage(for: webPage, navigationAction: action) != nil {
// Note: The new WebPage has been created and published to the view
return .allow
}
}
return .allow
}
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 everyone, recently I used codex and GPT-5.2 to build a simple SSL certificate monitoring website, and I'd like to share some of my development experiences. The project link is at the end, but first, let's talk about the technical implementation.
The Motivation
I've encountered several service outages caused by expired SSL certificates in the past. Each time, I had to react after users reported the issue, which was very passive. While there are some monitoring tools on the market, they are either too heavy or lack the necessary features, so I decided to build my own.
Technology Stack
Next.js 16 + shadcn/ui + TypeScript
I chose Next.js because:
The development experience with App Router is excellent, with a clear mapping between routes and file structure.
Server Components reduce the need for client-side JavaScript.
Built-in features like image optimization and font loading are ready to use out of the box.
shadcn/ui is a component library based on Radix UI, and its advantages are:
Components are copied directly into your project, giving you full control.
It uses Tailwind CSS, making style customization easy.
It has excellent accessibility features.
Drizzle ORM + PostgreSQL
I've used Prisma before, but I tried Drizzle this time and found it to be more lightweight:
Faster type generation.
More intuitive SQL operations.
Better query performance.
better-auth Authentication System
This is a recent discovery I made, and it's more modern than NextAuth:
Better TypeScript support.
A cleaner API design.
Supports email/password and multiple OAuth providers (GitHub, Google).
Some Challenges I Faced
1. The Complexity of Certificate Chain Validation
At first, I thought checking an SSL certificate was simple—just get the certificate information. I later discovered that certificate chain validation is quite complex:
You need to verify the signature of each certificate in the chain.
You must check the integrity of the entire certificate chain.
You have to determine if the root certificate is trusted (which browsers have built-in lists for).
You need to handle cases where intermediate certificates are missing.
The solution was to create a complete certificate chain extraction and validation module that includes:
Extracting the full certificate chain from a TLS connection.
Verifying the signature and validity period of each certificate.
Detecting broken or incomplete chains.
Visualizing the chain structure in a tree format.
2. Designing the Security Scoring System
To help users quickly understand the security status of their certificates, I created a scoring system from A+ to F. The core logic is:
Weighted score across four dimensions
- Certificate Validity: 30%
- Chain Integrity: 25%
- Cryptographic Strength: 25%
- Protocol Version: 20%
If there are critical issues (e.g., expired certificate), the maximum grade is C
The challenges were:
How to allocate weights reasonably.
How to design the penalty rules.
How to provide valuable improvement suggestions.
Ultimately, I adopted a layered scoring approach where each dimension is calculated independently and then combined with weights.
3. Hydration Issues with Multi-language Routing
When supporting 6 languages, I encountered React Hydration errors:
// ❌ Incorrect approach
// app/[locale]/layout.tsx contained the <html> tag
// This conflicted with the root layout
// ✅ Correct approach
// The root layout has only one <html> tag
// Use a client component to dynamically update the lang attribute
4. Graceful Degradation for Redis Caching
To improve authentication performance, I added Redis caching. But I had to consider:
What happens when Redis is unavailable?
How do you handle cache and database data inconsistency?
The solution was:
Automatically fall back to the database if the Redis connection fails.
Actively invalidate the cache when the database is updated.
Provide cache statistics API to monitor the hit rate.
5. PageSpeed Optimization
Initially, the Lighthouse score was only in the 60s. The main problems were:
Large JavaScript Bundle
Used Next.js's dynamic imports to load components on demand.
Removed unused dependencies.
Enabled Tree Shaking.
Image Optimization
Used the Next.js Image component for automatic optimization.
Added appropriate placeholders.
Enabled lazy loading for images.
Font Loading
Used next/font for automatic font optimization.
Reduced the number of font variants.
Used font-display: swap to avoid layout shifts.
Critical Rendering Path
Identified critical CSS and inlined it into the HTML.
Deferred loading of non-critical JavaScript.
Optimized the loading order of third-party scripts.
Third-party Script Optimization
Deferred loading for Google Analytics, Crisp Chat, etc.
Used the defer/async attributes.
Considered using Web Workers for time-consuming tasks.
After optimization:
Performance: 60 → 95
Accessibility: 85 → 98
Best Practices: 90 → 100
SEO: 100
Some Technical Highlights
Certificate Chain Visualization
A tree structure is used to display the certificate chain, with expand/collapse functionality and color-coding for different statuses:
Green: Valid
Yellow: Expiring soon
Red: Expired
Security Issue Detection
Automatically detects insecure cryptographic algorithms:
MD5, SHA-1 signature algorithms.
Weak ciphers like RC4, DES.
Old protocols like TLS 1.0/1.1.
Multi-channel Notifications
Currently supports five notification channels: Email, Slack, Discord, Telegram, and Feishu. Users can freely combine them.
Project Link
https://guardssl.info
Features:
Free SSL certificate checking.
Domain monitoring and expiration reminders.
Security scoring and improvement suggestions.
Multi-language support (Chinese, English, Japanese, French, Spanish).
Feel free to try it out and provide feedback. We can discuss any questions you might have.
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
Could somebody provide hello world example of Safari Extension which is able to call on-device Foundation Model (Apple Intelligence)?
I cannot find any examples yet
I am following up on Thread (https://developer.apple.com/forums/thread/733233). Currently, SFSafariExtensionManager.getStateOfSafariExtension only returns if an extension is enabled, but not if "Allow in Private Browsing" is toggled on.
Is there an API in macOS 26 and Safari 19 that allows a native Safari App Extension to detect this specific permission?
Touch not working to close in-app close-ups since latest iOS 26 update
Topic:
Safari & Web
SubTopic:
General
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.
Hello,
I am implementing video calling on iOS and need to support Picture in Picture (PiP) behavior similar to FaceTime or WhatsApp.
What works
Audio continues correctly in background
CallKit UI works as expected
Video works correctly while the app is in the foreground
What I’m trying to achieve
When the user presses the Home button or switches apps, I want to show a system Picture in Picture window (floating video outside the app).
Current setup
Video is rendered via WebRTC
The video is displayed inside a WKWebView (HTML / JavaScript)
PiP works only while the app is foregrounded
When the app backgrounds, the video disappears (only audio remains)
Questions
Does iOS support system Picture in Picture for:
WebRTC video
WKWebView / HTML video
2 Is AVPictureInPictureController limited only to:
AVPlayerLayer
AVSampleBufferDisplayLayer
3 If PiP requires native rendering:
Is it mandatory to render WebRTC frames natively using AVSampleBufferDisplayLayer?
Is PiP explicitly unsupported for WebView / HTML video?
📌 Clarification
Apps like FaceTime and WhatsApp are able to show PiP outside the app.
I want to understand whether this behavior is achievable only with native video pipelines, or if WebView-based video is fundamentally restricted by iOS.
Any official clarification or documentation reference would be appreciated.
Thank you.
Bit of an odd one here, just keen to understand if it’s just me or a more generic issue.
For all other apps, I can drag the icon from the dock to place into stage manager left, centre or right.
However when I try to do the same with Safari (and only Safari), it just doesn’t work at all.
I can repeat this 100%, has been an issue with 26.0, 26.1 and now 26.2. Can confirm this isn’t a problem on my 11” M4 iPad pro running same O/S.
Here is a video showing the issue (YouTube)
https://youtu.be/0WBGBZVHsfs
Topic:
Safari & Web
SubTopic:
General
I’m encountering an issue on iOS when rendering a list using React.
Each list item uses the array index as the React key and consists of two parts:
a header section that uses position: sticky for dynamic sticking behavior, and
a body section whose height is automatically adjusted based on its content.
When the list data is updated, I sometimes observe that the sticky header content does not update visually in time, even though the underlying data and DOM have changed.
// demo.jsx
import React, { useState } from 'react';
import { Button } from '@iftide/mobile';
import './style2.less';
// import data1 from './data1.json';
// import data2 from './data2.json';
const prefixCls = 'im-detaillist';
const data1 = [
{
sectionTitle: '2025年05月'
},
{
sectionTitle: '2025年04月'
},
{
sectionTitle: '2025年03月'
}
];
const data2 = [
{
sectionTitle: '2023年08月'
},
{
sectionTitle: '2023年07月'
},
{
sectionTitle: '2023年06月'
},
{
sectionTitle: '2023年05月'
}
];
export default function App() {
const [list, setList] = useState(data1);
const [toggle, setToggle] = useState(true);
return (
<div>
<Button
title="更新2"
onClick={() => {
setToggle(!toggle);
setList(data2);
}}
/>
<div className={`${prefixCls}-container2`} style={{ height: `700px` }}>
{list.map((section: any, sectionIdx: number) => {
return (
<div
className={`${prefixCls}`}
key={String(sectionIdx)}
// id={section.sectionTitle}
>
<div className={`${prefixCls}-section-title`} role="text">
{section.sectionTitle}
</div>
<div
style={{
background: 'green',
height: `${Math.ceil(400 * Math.random()) + 50}px`
}}
>
省略
</div>
</div>
);
})}
</div>
</div>
);
}
.@{prefixCls}-section-title {
position: sticky;
position: -webkit-sticky;
will-change: transform;
top: 0;
z-index: 1;
padding-left: 11px;
width: 100%;
height: 30px;
font-size: var(--font-size-s);
font-weight: 400;
line-height: 30px;
color: #000000;
background-color: #F4F5F7;
letter-spacing: 0;
}
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
Scenario Overview:
In our app, we open an in-app browser to complete a third-party consent flow. The sequence is:
App → Website A (set cookie and redirect) → Google → Website A (check cookie) → App
After upgrading the app, the first consent attempt fails because the cookie cannot be written, causing the check cookie step to fail. However, if we use the native Safari browser, this issue does not occur.
Observed Behavior:
Scenario
Result
Upgrade app → Consent
❌ Fail
Upgrade app → Consent fail → Consent again immediately
✅ Pass
Upgrade app → Consent fail → Upgrade again after 1–2h → Consent
✅ Pass
Upgrade app → Consent fail → Upgrade again after 1d → Consent
❌ Fail
Install a new app → Consent
✅ Pass
Upgrade app → Consent, cancel flow → Consent again
✅ Pass
Install new app → Wait for upgrade → Upgrade app → Consent
✅ Pass
Install new app → Wait 1–2h → Upgrade app → Consent
✅ Pass
Investigation:
From Safari documentation, this seems related to Intelligent Tracking Prevention (ITP), which restricts cross-site cookie behavior during first-party interactions. However, I haven’t found a clear mitigation strategy yet.
Question:
Has anyone encountered similar issues with Safari ITP after app upgrades? Are there recommended approaches to ensure cookies persist across this redirect flow?
Topic:
Safari & Web
SubTopic:
General