Hi Apple Team,
We’ve noticed a couple of issues with launching default App Clip in safari and would appreciate your guidance.
App Clip Popup Timing:
When launching the App Clip using default URL, we sometimes see the small App Clip popup appear before the App Clip banner is displayed. Ideally, the banner should appear first.
Cached URL Handling:
In certain cases, the App Clip appears to be using a cached URL instead of the most recent one. For example, when we invoke two different App Clip URLs with unique parameters, the App Clip sometimes launches using the previous URL’s data instead of the new one.
This behavior is inconsistent and makes it difficult to ensure users are directed to the correct experience each time. Could you please help us understand whether this is expected behavior or if there are any known issues or recommended solutions?
Thank you for your time and support.
Example
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
We are seeing network errors in Outlook mail on iOS and MacOS safari browsers.
As per current investigation, we notice these network error when the user tries to use outlook after leaving it open on Safari for a while.
Observations:
Issue present in both MacOS and iOS safari.
Issue is not present in other webkit browsers like brave and edge on iOS.
Issue is reproable on both mini and big owa on safari browser.
Issue is not related to post requests being sent in different packets on safari browser.
Requests are only blocked for outlook.office/outlook.live domains
What does not fix this issue?
Reloading the application
Clearing cookie, local storage or session storage
Unregistering service workers
Redirecting to a different page and coming back to outlook domain
Re authenticating the users
What fixes this issue?
Reconnecting to wifi or mobile network
Reconnecting vpn
Removing safari from background and reopening
Flushing the dns in setting
After updating to Safari 26.0 (on macOS Sequoia or Tahoe), the Declarative Net Request (DNR) API rule with "type": "redirect" no longer works as expected.
When the rule is applied, the browser initially shows a banner at the top of the page:
"This webpage was reloaded because a problem occurred."
After the reload, the page fails to load and displays an error page with the message:
"A problem repeatedly occurred with https://extensionworkshop.com/?test=true "
This behavior is new in Safari 26.0. The same rule was working correctly in earlier Safari versions (17.x / 18.x).
I would like to know if there is a way to disable Smart Punctuation from the webpage rather than requiring the user to do so from the settings. Adding a "inputmode=verbatim" attribute to the input HTML tags for my webpage did that for all the web browsers I tested on Windows, Ubuntu, Android, and MacOS. I tested Chrome and Firefox on all platforms, as well as Edge on Windows and Safari on Mac and iOS. So far the only time it did not disable Smart Punctuation was on Safari on iOS, but it did on MacOS.
I have a very specific issue that happens only on iOS Simulator version 18.4.
It does NOT happen when I run my app on a real iOS 18.4 device through Testflight.
My app displays a WebView (courtesy of Capacitor, url scheme capacitor://).
Inside that Webview I'm using Firebase JS API (11.2.0) and calling signInWithEmailAndPassword, which works well in all other contexts, i.e. browser, Android webview, iOS webview in all other Simulator versions, and on real devices.
Only when running in Simulator 18.4, I get a failed network request:
cannot parse response
Fetch API cannot load https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?... due to access control checks.
Failed to load resource: cannot parse reponse
error: FirebaseError: (auth/network-request-failed)
Everything is working correctly for both:
Capacitor app webview installed on a real 18.4 device with Testflight
Safari (non-webview) in the 18.4 Simulator
The issue is severe for us, because we are unable to develop our app and test it in the simulator on 18.4 Simulator before pushing it through Testflight internal release.
Request headers on the failed request (no response status or headers available).
Request
Accept: /
Content-Type: application/json
Origin: capacitor://localhost
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) - AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
X-Client-Version: Mobile/JsCore/11.2.0/FirebaseCore-web
X-Firebase-Client: (...)
Hi guys, I'm trying to use sign in with apple in javascript, I followed the guider in the website, and almost find everything I can find in Google, but nothing help, here is my situation:
I create a new App: com.yuhan.test.app
I create a new service ID: com.yuhan.test.service
configure a domain and return url
domain: tts.perterpon.com
returnURL: https://tts.perterpon.com/login
create a new key for Sign In with Apple.
my html code is here, it's easy, but it always told me invalid_client, I think I have done anything I need to do, can somebody help me? Thank you so much.
you can test my online web site: https://tts.perterpon.com/login.html
`
const buttonElementNew = document.getElementById('appleid-signin');
buttonElementNew.addEventListener('click', async () => {
try {
const data = await AppleID.auth.signIn()
console.log('Try/Catch Data', data.authorization.id_token);
const formData = new FormData();
formData.append("token", data.authorization.id_token);
await fetch("", {
method: "POST",
body: formData,
});
// Handle successful response.
} catch (error) {
// Handle error.
}
});
</script>
We have a JavaScript api that queries our Secure Browser to get the network information – signal strength, network name, plugged in/wifi. Everything worked fine through the Tahoe betas, still does. Now we are getting on the network name and this is breaking our UI. Was this an intentional change or a bug? The other two properties still appear to be working. And it works in all lower MacOS versions.
We are currently obtaining it through AppleScript
try
set ssid to do shell script "system_profiler SPAirPortDataType | awk '/Current Network Information:/ {getline; sub(/^ +/, ""); sub(/:$/, ""); print}'"
if ssid is equal to "" then
return "Not connected to any Wi-Fi network."
else
return ssid
end if
on error errMsg
return "Error: " & errMsg
end try
Topic:
Safari & Web
SubTopic:
General
When I open com. apple. developer. web browser, I am unable to inject JavaScript into the webview through methods such as addUserScript. The console will prompt 'ignoring user script injection for non app bound domain'
The app I work on uses WKWebView to render customer data. In iPadOS 26, we observe that there is a delay when resizing the window (and thus the web view) before the content is re-rendered. The same behavior is visible in Safari.
For demonstration purposes, consider this test page: https://phet-dev.colorado.edu/html/build-an-atom/0.0.0-3/simple-text-only-test-page.html
Initially, the window is small:
Then when the window is expanded, the content scales up temporarily:
It eventually re-renders to the correct size, but then if you make the window small again, you get (temporarily):
Is there anyway around this behavior? We would love to have the content reflow interactively.
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
I'm not loving the huge Favorites icons in Safari on MacOS 26, is there a way to reduce the size of them so that we can see more favorites on the list without scrolling down?
We’ve noticed that the ApplePaySession.applePayCapabilities() check has stopped working correctly in Safari over the past couple of days.
Behavior observed:
1.) In Safari Private Window, paymentCredentialStatus behaves as expected and case 1 is triggered.
2.) In a normal Safari window, it always triggers case 3 (paymentCredentialsUnavailable), even when the user has active cards provisioned in Wallet.
We tested across multiple devices, and the behavior is consistent.
if (window.ApplePaySession) {
var merchantIdentifier = 'YOUR MERCHANT IDENTIFIER';
var promise = ApplePaySession.applePayCapabilities(merchantIdentifier);
promise.then(function(capabilities) {
switch (capabilities.paymentCredentialStatus) {
case "paymentCredentialsAvailable":
// Show Apple Pay button as primary option
case "paymentCredentialStatusUnknown":
// Offer Apple Pay
case "paymentCredentialsUnavailable":
// Consider showing Apple Pay button
case "applePayUnsupported":
// Don’t show Apple Pay button
}
})
}
This used to work fine until a few days ago, but now the capability check in non-private Safari windows always indicates unavailable, even with valid active cards.
Has anyone else faced this issue recently? Could this be a Safari regression or a change on Apple’s side?
Thanks in advance!
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;
}
When I open the browser in Safari on iOS 26, I want to specify the background color for the header notch (where the time, battery, etc. are displayed) and the footer indicator area.
Specifying the theme color in HTML as shown below did not change anything.
<meta name="theme-color" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000">
The HTML below specifies the background color as green, but is it necessary to specify the background color directly in the body like this?
Or is there some kind of metadata, like theme color?
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<meta name="theme-color" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: light)" content="#ff0000">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#ff0000">
<title>サンプル</title>
</head>
<body style="background:#00ff00">
<main>
<p>テキスト</p>
</main>
<div
id="overlay"
role="dialog"
aria-modal="true"
data-test-id="health-warning-modal"
style="
color:#000000;
position:fixed;
inset:0;
z-index:30000;
background:#2563eb;
display:grid; /* 初期表示:表示中 */
align-items:center;
justify-content:center;
overflow-y:auto;
"
>
<div
style="
padding:60px 16px;
display:flex;
flex-direction:column;
gap:20px;
width:100%;
box-sizing:border-box;
"
>
<p
style="
font-weight:700;
text-align:center;
margin-top:20px;
font-size:28px;
line-height:1.4;
"
>
オーバーレイ
</p>
</div>
</div>
</body>
</html>
Dear Apple Developer Support,
We are currently developing a system that requires the ability to edit Japanese vertical text within the Safari browser on iPhone. During our investigation, we encountered an issue that matches the following WebKit bug:
283620 – Caret Positioning Issues in Vertical Writing Mode
We understand that this issue is being addressed in the following pull request:
https://github.com/WebKit/WebKit/pull/39939
However, it appears that a complete fix has not yet been implemented.
Given this situation, we would like to confirm the following:
Is there any known workaround for this issue in iOS 17.5 or iOS 18.5 (the latest versions as of now)?
If a workaround exists, could you please provide details?
If not, could you share the expected timeline for a full resolution of this issue?
Although this appears to be an open-source WebKit issue, we are reaching out to Apple because WebKit is tightly integrated with iOS and Safari, and ultimately delivered as part of the iPhone experience.
Thank you very much for your support.
Best regards,
Takao Kurabayashi
Topic:
Safari & Web
SubTopic:
General
Despite using the iPad in landscape mode, self-camera video is forced to portrait (Rotate 90 degrees).
Only the video is portrait, even though the browser is in landscape orientation.
Our app use getUserMedia() to get the video.
The problem also happend in iPad Safari GoogleMeet.
Details:
The problem occurs even when the screen orientation is locked.
After the video has been forced to portrait, rotating the iPad temporarily changes the video to landscape, but forces it to portrait again.
It takes around 0 - 30 seconds before the video is forced to portrait.
Both selfie camera and back camera
I have confirmed this problem on the following devices
iPad 8th iPadOS: 18.3.1
iPad10th iPadOS:18.3.1
iPadPro(M4) iPadOS:18.3.1
Some devices do not have this problem, even if they are the same model and OS version.
I have tried the following
restart
factory reset
Configuration changes (Settings > Apps > Safari)
SETTINGS FOR WEBSITES
Camera > Allow, Ask
Microphone > Allow, Ask
Advanced > Feature Flags
Reset All to Defaults
Screen Orientation API (Locking / Unlocking)
Screen Orientation API
WebRTC AV1 codec
Please help me to resolve this problom. Thanks.
I'm working on a Safari web extension that uses the nativeMessaging facility to communication with native code.
When I want to notify the javascript extension from the embedding application, I use SFSafariApplication::dispatchMessage. As per the documentation, this call
... ensures that Safari is launched and that your extension is running before delivering the message.
Everything works fine when the background script is running.
However, after the background script gets unloaded at some point in time (non persistent background page, default behavior for a manifest V3 extension), the background script is not reloaded by the message from the native app (background script still appears unloaded in the developer menu of Safari, double-checked using a counter stored in browser.storage.local incremented on message reception). In this case, the completion handler of the application gets no error (error == nil) as if the message was correctly delivered.
I was able to reproduce this behavior with the sample app delivered for WWDC20 (after upgrading the manifest from v2 to v3 to make it non-persistent).
Is it supposed to work ? What I'm doing wrong ?
"The Safari web extension packager enables you to package and distribute your Safari extensions using App Store Connect from any web browser, without requiring a Mac or access to Xcode."
I upload the unzipped folder I'd test in Chrome://extensions to the Safari web extension packager in App store connect.
I get error:
Embedded binary's bundle identifier is not prefixed with the parent app's bundle identifier.
The only solution i've seen to this error involves xcode/a mac, being without which doesn't help
I recently upgraded my device from IOS 18.4 to IOS 26. My web extension has disapeared from safari. I can see it in Settings > Apps > Safari > Extensions and when I turn it on and re-open safari. I just get a mesasge that says "{extension name} is no longer avaiable". I have tried Manifest V2 and Manifest V3 both yield the same results. The current production extension bundled with the IOS app has the same problem. I can no longer use or test my own extension !? Help please !
Hi, We are facing a major issue with our application. We are using FolioReaderkit to read epub files. Currently, it's working on the iOS 18.1 device and simulator, but it's not working on the iOS 18.2 and later version devices.
we are facing this error in Folioreaderkit