I'm building a progressive web app (PWA) and came to the conclusion that almost nobody knows that this feature exists - Add to Home Screen. Not many people even understand what a PWA is or that you can add it to the home screen. This feels unnatural compared to installing an app from a store. Why do we make it so hard for users? Could we not make this easier by having the ability to call this installation or show an install notification?
Right now, when users visit a PWA on iOS, there's no way for developers to let them know they can install it. The "Add to Home Screen" option is tucked away in the Share menu, and most users never find it. I'd really like to be able to show them a friendly prompt.
Comparing to other browsers, this is possible via the beforeinstallprompt event. This would make a huge difference for user experience. Right now the only way is to show iOS users a separate set of instructions with screenshots, which feels clunky compared to what's possible on other platforms.
I'm curious - is there any reason why this hasn't been added to Safari yet? Other browsers have supported this for years now. Is there any progress being made on this, or is it being considered for the roadmap? It would be really helpful to know if this is something that will be worked on in the future.
I know there's a lot on the roadmap, but this would really help developers create better installation experiences for our users.
Thanks for considering this!
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,
I've got Smart App Banner set up on my website. However, I want to be able to measure the traffic coming from this banner to the app store / app (i.e. measure impressions/downloads).
Apple documentation (https://developer.apple.com/help/app-store-connect/view-app-analytics/manage-campaigns/) says you can set up a campaign link and use it in the Smart Banner to track those who download / open the app store page using your smart banner (so that we can get attribution).
However, there is no documentation at all in terms of how this should be added to the tag when implementing a Smart App Banner.
I've tried so many different variations and none have tracked downloads. This includes a structure based on an example taken from WWDC from a few years back which also did not work.
I would appreciate any help!
Hello,
After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project).
Observed behavior
On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return.
This happens not only for:
evaluateJavaScript("navigator.userAgent")
but also for simple or even empty scripts, for example:
evaluateJavaScript("")
On previous macOS versions, the same calls typically returned in ~200 ms.
Additional testing
I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls.
In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2.
Question
Is this a known issue or regression related to:
iOS Apps on Mac,
Swift + WKWebView, or
behavioral changes in evaluateJavaScript on macOS 26.2?
Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated.
Thank you.
Test Code Swift
class ViewController: UIViewController {
private var tmpWebView: WKWebView?
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
setupUserAgent()
}
func setupUserAgent() {
let t1 = CACurrentMediaTime()
tmpWebView = WKWebView(frame: .zero)
tmpWebView?.isInspectable = true
tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in
let t2 = CACurrentMediaTime()
print("[getUserAgent] \(t2 - t1)s")
self?.tmpWebView = nil
}
}
}
Test Code Objective-C
- (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions {
NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970];
WKWebView *webView = [[WKWebView alloc] init];
dispatch_async(dispatch_get_main_queue(), ^{
[webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) {
NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970];
NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime));
}];
});
}
The issue of fixed elements with
{ bottom: 0 }
moving up when scrolling still persists.
It seems to be a general issue with the IOS 26 release.
It affects other browser too. I tested on browsers such as Safari, Chrome, Firefox, Edge and Bravo.
With the exception of Edge, all the others display the behavior.
Device: iPhone 15 Pro
IOS Version: 26.0.1
Hi Apple engineers!
We are making an iOS browser and are planing to deliver a feature that allows enterprise customers to use a MAM key to set a PAC file for proxy. It's designed to support unmanaged device so the MDM based solutions like 'Global HTTP Proxy MDM payload' or 'Per-App VPN' simply don't work.
After doing some research we found that with WKWebView, the only framework allowed on iOS for web browsing, there's no API for programmatically setting proxy. The closes API is the WKURLSchemeHandler, but it's for data management not network request interception, in other word it can not be used to handle HTTP/HTTPS request well.
When we go from the web-view level to the app level, it seems there's no API to let an app set proxy for itself at an app-level, the closest API is Per-App VPN but as mentioned above, Per-App VPN is only available for managed device so we can't use that as well.
Eventually we go to the system level, and try to use Network Extension, but there's still obstacles. It seems Network Extension doesn't directly provide a way to write system proxy. In order to archive that, we may have to use Packet Tunnel Provider in destination IP mode and create a local VPN server to loop back the network traffic and do the proxy stuff in that server. In other word, the custom VPN protocol is 'forward directly without encryption'. This approach looks viable as we see some of the network analysis tools use this approach, but still I'd like to ask is this against App Store Review Guidelines?
If the above approach with Network Extension is not against App Store Review Guidelines, I have a further question that, what is the NEProxySettings of NETunnelNetworkSettings for? Is it the proxy which proxies the VPN traffic (in order to hide source IP from VPN provider) or it is the proxy to use after network traffic goes into the virtual private network?
If none of the above is considered recommended, what is the recommended way to programmatically set proxy on WKWebView on an unmanaged device (regardless of where the proxy runs, web-view/app/system)?
Is ServiceWorker supported on WKWebView? As per Mozilla Developer Network(MDN Web) docs[1] its not supported, but our research shows that ServiceWorker becomes available for a domain in WKWebView 1) if the domain is allowlisted in app-bound domains[2] or 2) if app is registered as default browser(this can not be considered for our app as its not a browser).
How to enable ServiceWorker on WKWebView? Is adding domain as app-bound domain the right/only way to enable ServiceWorker on WKWebView? We didn't find any official documentation about this.
Can WebView get ServiceWorker support by default without enabling app bound domains since that is not an option for our app? Our app needs to support more than 10 domains. Powerful APIs such as JavaScript injection, cookie manipulation, event handlers are by default available to all domains/WebView instances even if App doesn't enable app-bound domains. Is it possible to do same for ServiceWorker?
If ServiceWorker can not be supported by default then can Apple provide a feature by which ServiceWorker will be enabled in App for all the domains?
Apple enforces maximum of 10 app-bound domains. Is it possible to remove this limit and provide a way to dynamically add to this list at the time of a request?
[1] https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker#browser_compatibility
[2] https://webkit.org/blog/10882/app-bound-domains/
When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?
This is my first post, so please forgive me if it is to the wrong area.
I've been using Tahoe for a few days and, overall, it's very stable. But the one thing that has bothered me to no end is Safari's new behavior with respect to its header (Address bar, Favorite bookmarks bar, tab bar) background color. The web content of the active tab seems to affect everything - and oftentimes makes things completely unreadable - at least in "Dark" mode. For instance, if a web page uses a white background, the Favorites bookmark labels are the same color as the bookmark background, so reading the labels is simply impossible. At other times, they're just very difficult to read.
Similarly, it is almost always impossible to tell which tab is the active one - my only workaround is to try 100% brightness....or to just guess.
When Apple previously experimented with letting content bleed through to the top, there was a setting for stopping it - but I don't see such a setting anymore. Do you you know of any way to stop this effect?
I am creating a Safari Web Extension.
There are two calls let say, call1 and call2 which gets executed in sequence by browser, call1 gives a 302 type response and redirects to call2.
When creating DNR rule for adding "Cookie" in the request header of call1, the same cookie gets added to the request header of call2 as well(Same is the case for other headers/custom headers as-well). Because of this the set-cookie present in response header of call1 is not sent in the request header of call2, and returns 400 response.
The same setting is working fine for other browsers chrome & firefox.
Is this a bug or DNR works differently for safari ?
currently "webRequestBlocking" works in safari for manifest v3, is there any development of it getting removed just like it's removed in chrome in mv3.
Since Xcode 26 our tests are crashing due to the Main Thread not being able to deallocate WKNavigationResponse.
Following an example:
import Foundation
import WebKit
final class WKNavigationResponeMock: WKNavigationResponse {
private let urlResponse: URLResponse
override var response: URLResponse { urlResponse }
init(urlResponse: URLResponse) {
self.urlResponse = urlResponse
super.init()
}
convenience init(httpUrlResponse: HTTPURLResponse) {
self.init(urlResponse: httpUrlResponse)
}
convenience init?(url: URL, statusCode: Int) {
guard let httpURLResponse = HTTPURLResponse(url: url, statusCode: statusCode, httpVersion: nil, headerFields: nil) else {
return nil
}
self.init(httpUrlResponse: httpURLResponse)
}
}
import WebKit
import XCTest
final class ExampleTests: XCTestCase {
@MainActor func testAllocAndDeallocWKNavigationResponse() {
let expectedURL = URL(string: "https://galaxus.ch/")!
let expectedStatusCode = 404
let instance = WKNavigationResponeMock()
// here it should dealloc/deinit `instance` automatically
}
Here the call stack:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 CoreFoundation 0x101f3dd54 CFRetain.cold.1 + 16
1 CoreFoundation 0x101e14860 CFRetain + 104
2 WebKit 0x10864dd24 -[WKNavigationResponse dealloc] + 52
Hi everyone,
I’m building a React Native iOS app where I’m integrating Wazo (native WebRTC) and Jitsi (WebView / WebRTC).
Use case:
Wazo is used to maintain a background call session (mainly signaling + audio keep-alive).
Jitsi is used in the foreground for video calls.
Problem:
When Jitsi starts, it takes control of the microphone and camera.
The Wazo call disconnects after ~5 minutes (likely due to media / audio session conflict).
Even if Wazo audio/video is muted or tracks are disabled, the session still drops.
My questions:
Is it officially supported or recommended to run two WebRTC stacks (Wazo + Jitsi) simultaneously on iOS?
Can Wazo stay connected without active audio/video tracks while Jitsi uses mic/camera?
Is there a way to release Wazo media streams temporarily (but keep signaling alive) while Jitsi is loading or active?
Are there any AVAudioSession / background mode limitations on iOS that make this impossible by design?
If this is not supported, what is the recommended architecture (single WebRTC pipeline, switching media ownership, etc.)?
Environment:
iOS (React Native)
Wazo SDK (native WebRTC)
Jitsi Meet (WebView)
CallKit + PushKit enabled
Any guidance, documentation, or real-world experience would be greatly appreciated.
Thanks in advance 🙏
Hello,
We’ve been using the CesiumJS WebGL library for several years, both on our website and within embedded WebViews in our iOS application. Since upgrading to iOS versions 18.2 and 18.3, we’ve started receiving numerous user complaints regarding application crashes on various iPad and iPhone models when loading CesiumJS.
The crashes occur as soon as the 3D view initializes, and the error consistently reported is:
"WebGL context lost"
This issue appears to be a WebGL-related crash potentially triggered by GPU memory handling or allocation limits. However, we are not detecting any abnormal memory consumption prior to the crash, and the same setup works perfect on older iOS versions and on all Android devices and versions.
Steps to Reproduce:
Open: https://www.flightradar24.com/30.47,-94.84/8
Click on any aircraft icon on the map.
In the aircraft details panel at the bottom, click on the “3D view” tab.
On iOS 18.2 or 18.3, the page will crash shortly after initializing CesiumJS WebGL.
Affected Devices:
This issue is occurring across a wide range of devices, including:
iPad 9th Generation
iPad Pro (11-inch, 2nd Gen)
iPhone SE (2020 and 2022)
iPhone 11, 11 Pro
iPhone XR
iPhone Mini
All of the above are running iOS 18.2 or 18.3. The problem does not occur on Android or previous iOS versions.
Request:
Has anyone else encountered similar issues with WebGL context loss after upgrading to iOS 18.2 or 18.3? Are there any known changes in memory limits or WebGL behavior in these recent iOS updates? We’d appreciate any insight or suggestions on workarounds or potential fixes.
Thank you!
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
Typically, you can use the @@extension_id special string to reference the absolute path into the bundled resources of an extension, such as an image or a custom font, in a CSS file.
However, this broke with Safari 18.
Consider this section in a popup.css file:
.card-icon {
height: 16px;
width: 20px;
background-image: url(safari-web-extension://__MSG_@@extension_id__/images/card.svg);
background-size: 20px 16px;
}
In Safari 17.4, once loaded in the browser, @@extension_id is replaced with E8BEA491-9B80-45DB-8B20-3E586473BD47, and the background-image reads as so:
background-image: url(safari-web-extension://E8BEA491-9B80-45DB-8B20-3E586473BD47/images/card.svg);
But as of Safari 18, the @@extension_id just collapses to an empty string, and the background-image reads as so:
background-image: url(safari-web-extension:///images/card.svg);
and the svg fails to load with the following error: "Failed to load resource: You do not have permission to access the requested resource."
This is a regression, does to match the behavior of the other major browsers, and should be fixed.
Filed with Feedback ID: FB15104807
The crash is specific to iOS 26.2 WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage)
Name attribute is accessible but WKScriptMessage body attribute causes crash
The object seems to be not accessible
Please kindly improve the Safari browser side bar implementation further along with what The Browser Company has done with their Arc browser. Arc is about to retire soon too and they're willing to sell their SwiftUI code perhaps too for a decent pile of dollars, not the Jony Ive piles at least it should not.
The toggle for side bar is nice and works perfect though!
WKWebView has a new property "isBlockedByScreenTime" since iOS 26. But I do not yet understand when exactly this property could be used.
When I setup content-based restrictions in the ScreenTime settings then WKWebView reports an error 105 via "webView:didFailProvisionalNavigation:" delegate. The isBlockedByScreenTime property still returns false in this case.
If ScreenTime has a time-based limit, the App would not run at all.
Under which circumstances would the property "isBlockedByScreenTime" return the value true? When exactly and for what can this property be actually used?
The "problem" is that I want to find if a web page is blocked and can not be loaded, why this is the case. By simply trial and error I found out that WKWebView returns error codes 104 and 105 for blocked web sites because of content filters and Screen Time restrictions, however these error codes are not documented at all (at least I've not found any documentation or documentation for these error codes and also some other codes like 100, 102, 204 etc), so I'm not really sure if I handle all cases correctly.
I hoped that isBlockedByScreenTime would at least tell me one reason for blocked pages.
If there are documents which explain these error codes (100 and above), where I can find these?
Summary
Recently a number of bugs affecting our Safari extension have been introduced with various Safari 18.X updates. We've submitted feedback for all of these, but most have received no response. We need to raise this to your attention as it has been affecting our developer experience and causing a lot of frustration for our users. It's something that adds a lot of uncertainty for us. These issues affect core web functionalities but seem to be isolated to the Start Page or Extension environments.
For example:
using window.open, no longer works
using window.location.href = ... no longer works
Including a tag in our start page causes infinite reloading to occur.
registering a content script more than once will crash Safari
Details
Unable to open new window as as start page extension in Safari 18
FB15879470
What happens: Calling window.open does nothing. This broke our links to our feedback submission, marketing site & help site.
When: Nov 18, 2024 - Initial launch of Safari 18 on macOS
Status: Open, No response
Unable to open app url scheme with window.location.href in start page extension in iOS 18
FB15879596
What happens: Changing the URL in this way does nothing (well actually it does work about 10% of the time). This broke our navigation to in app payment.
When: Nov 18, 2024 - Initial launch of Safari 18 on iOS
Status: Open, No response
New tab extensions broken
FB16126043
What happens: Having a tag in your causes an infinite loop of reloading the start page. This broke our entire start page extension.
When: Dec 19, 2024 - Safari 18.3 on iOS beta
Status: 10 similar tickets found, marked for future OS update. We did get a response and a fix is identified for a future release
window.open opens “about:blank” when called from Start Page extension.
FB16427985
What happens: calling window.open from the start page opens about blank on iOS 18.3. Similar to the first issue, but slightly different behaviour. This broke our links to our feedback submission, marketing site & help site.
When: Jan 30, 2025 - Safari 18.3
Status: Open, No response
Registering a content script more than once causes Safari to crash in macOS 15.4 beta
FB16831768
What happens: We have an optional content script that we were registering every time it was used. Although somewhat redundant, it was much simpler than checking if one was already registered and tracking if an updated one needed to replace it. This works fine on all other browsers and all prior Safari versions we've released it on. However if a user enables site blocker on the latest version, as soon as they visit any website, our content script registration causes Safari to crash. Essentially preventing users from using Safari until they uninstall our extension.
When: Mar 11, 2025 - Safari 18.4
Status: Open, No response
In Conclusion
Luckily we have been able to isolate and find workarounds for most of these issues so far, but we are not guaranteed to in the future. We are raising this not only to have these issues looked into, but to raise awareness of the rising trend of basic functionality of Safari extensions breaking with Safari updates. We hope that this can influence a shift in your QA & feedback intake practices to ensure these issues are less frequent in the future.
We are happy to raise future issues through your provided channels as they are discovered. But to have our feedback ignored and then have to rely solely on workarounds to prevent disruptions to our users' experience is concerning.
We submitted this feedback to our developer relations contact, and he suggested we submit a TSI to look into these issues. In response to this, we were advised to post this here.
Hello, my application experiences crashes related to JavaScriptCore in iOS 17 and 18. I would like to consult about potential causes, to determine whether it is a bug in JavaScriptCore or an issue with my code implementation.
First, the crash stack always includes the call to
JSC::MarkedBlock::aboutToMarkSlow(unsigned int).
In the iOS 17 version, the crash occurs on this line, typically
JSC::MarkedBlock::aboutToMarkSlow(unsigned int) + 88.
In iOS 18 and later, the stack crashes atJSC::MarkedBlock::dumpInfoAndCrashForInvalidHandle(WTF::AbstractLocker&, JSC::HeapCell*).
I checked the source code of JavaScriptCore for both iOS 17.6 and iOS 18.2 and observed modifications in the implementation of aboutToMarkSlow.
My question is under what circumstances could this crash occur?
crash.log
I have attached a crash log encountered in iOS 18, hoping you can provide more effective information for problem diagnosis, especially since there are specific details worth noting near the crash registers.
INVALID HANDLE: MarkedBlock = 0x141158000; heapCell = 0x14115bfa0; type = 0
INVALID HANDLE: found 24 0s at beginning of block
INVALID HANDLE: block in another VM: 1, block in another VM: 1; other VM is 0x1324b6000
Moreover, in iOS 18.4, due to the implementation of dumpInfoAndCrashForInvalidHandleV2, the message has changed to:
INVALID HANDLE 587: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=0; totalzeros=0; blockVM=0x0; actualVM=0x0;
isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0;
INVALID HANDLE 606: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0;
isBlockVMValid=0; isBlockInSet=0; isBlockInDir=0; foundInBlockVM=0;
INVALID HANDLE 615: markedBlock=0x303518000; heapCell=0x303518fe0; cellFirst8Bytes=0; subspaceHash=0; contiguousZeros=16384; totalZeros=16384; blockVM=0x0; actualVM=0x0;
isBlockVMValid=0; isBlockInSet=1; isBlockInDir=1; foundInBlockVM=0;
(Further INVALID HANDLE messages follow the same format)
I hope this provides you with more information.
I'm using a CSS filter to achieve dark mode for my HTML page. I know it's imperfect, but I have no choice for many reasons.
However, I found that the CSS filter produces incorrect colors in iOS 26.2 WebView, while it works fine in iOS 18.6.2 WebView.
Here is my HTML and CSS filter:
<html>
<head>
<style>
.filter_container {
/* invert colors for the entire page */
filter: invert(1) hue-rotate(180deg);
}
.filter {
/* restore colors for specific elements, such as img */
filter: hue-rotate(180deg) invert(1);
}
</style>
</head>
<body>
<div>original & bgcolor+filter & img+filter</div>
<table>
<tr>
<td>
<div style="display:flex; gap:1px; align-items:center; justify-content:center;">
<div class="origin_container"><div class="origin" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px;"></div></div>
<div class="filter_container"><div class="filter" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></div></div>
<div class="filter_container"><img class="filter" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAA8CAYAAAA6/NlyAAAAdklEQVR4nOXOQQEAIACEMKR/57OFPliCnW0jRGIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkxt+B1y6HmAR0uIzOQQAAAABJRU5ErkJggg==" style="height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></img></div>
</div>
<div style="text-align:center;">#FFFFFF</div>
</td>
...many other colors
</table>
</body>
</html>
It works fine in iOS 18.6.2 WebView:
But renders incorrectly in iOS 26.2 WebView: