It seems that in iOS 18.5+ built with Xcode 16.4+, there has been a breaking change since 18.4 with 16.3 within WebKit and how the navigationAction.sourceFrame property is initialized when implementing the decidePolicy delegate method.
The flow goes:
Implement a WKNavigationActionDelegate with decidePolicy
Call WKWebView.loadHTMLString("some-string", baseURL: nil)
Upon loading the HTML content, read the value of navigationAction.sourceFrame within the decidePolicy method of the WKNavigationActionDelegate
On iOS 18.4 (and below) with Xcode 16.3 (and below);
navigationAction.sourceFrame is <uninitialized>
On iOS 18.5+ with Xcode 16.4+:
navigationAction.sourceFrame is already initialized and is equal to navigationAction.targetFrame
It appears that this change was made between minor versions of Xcode and is unexpected behavior of a minor version. Not only was this not called out in the release notes for Xcode 16.4 and iOS 18.5, but it's technically also a breaking change to the WebKit API.
Can we get insight on why this change was made and what Apple's policy is on breaking changes between minor versions of Xcode/iOS?
General
RSS for tagExplore 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
Seeing an issue in some versions of Safari (16.6, 18.3, 18.5) where an APNG converted to AVIF does not support transparency. Instead of a transparent background, the background is filled with black.
Topic:
Safari & Web
SubTopic:
General
Our app connects to the headend to get a IDP login URL for each connection session, for example: “https://myvpn.ocwa.com/+CSCOE+/saml/sp/login?ctx=3627097090&acsamlcap=v2” and then open embedded webview to load the page. (Note: the value of ctx is session token which changes every time). Quite often the webview shows blank white screen. After user cancel the connection and re-connect, the 2nd time webview loads the content successfully.
The working case logs shows:
didReceiveAuthenticationChallenge is called
decidePolicyForNavigationAction is called twice
didReceiveAuthenticationChallenge is called
decidePolicyForNavigationResponse is called
didReceiveAuthenticationChallenge is called
But the failure case shows:
Filed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x11461c240 {Error Domain=RBSRequestErrorDomain Code=3 "No such process found" UserInfo={NSLocalizedFailureReason=No such process found}}}
didReceiveAuthenticationChallenge is called
decidePolicyForNavigationAction is called
decidePolicyForNavigationResponse is called
If we stop calling evaluateJavaScript code to get userAgent, the blank page happens less frequently. Below is the code we put in makeUIView():
func makeUIView(context: Context) -> WKWebView
{
if let url = URL(string: self.myUrl)
{
let request = URLRequest(url: url)
webview.evaluateJavaScript("navigator.userAgent")
{
result, error in
if let error = error
{
NSLog("evaluateJavaScript Error: \(error)")
}
else
{
let agent = result as! String + " " + self.myUserAgent
webview.customUserAgent = agent
webview.load(request)
}
}
}
return self.webview
}
Found some posts saying call evaluateJavaScript only after WKWebView has finished loading its content. However, it will block us to send the userAgent info via HTTP request. And I don’t think it is the root cause since the problem still occurs with less frequency.
There is no problem to load same web page on Windows desktop and Android devices. The problem only occurs on iOS and macOS which both use WKWebview APIs.
Is there a bug in WKWebview?
Thanks,
Ying
Since iPadOS 18.x WKWebView seems to have a bug within its Fullscreen API (which can be enabled via WKPreferences.isElementFullscreenEnabled). This bug has the effect that websites trying to make an element (for example a video player) fullscreen fail to do so. This does not always happen, most of the time the fullscreen mode does work fine, but sometimes (far too often to be ignored) it does not. If an instance of WKWebView shows this issue, it can not be "fixed" by reloading the page or loading other pages, this issue exists in this instance forever.
My App is a web browser App so I can create and remove WKWebView instance easily (by opening or closing Tabs). And there are times where I never see this bug, and times where ever other tab shows this bug. It's totally unreliable.
The App does not show any issues at all when running under iPadOS 17 or older. The issue is only present under iPadOS 18.x.
After some testing I've found out that when the bug has affected an instance of WKWebView, the JavaScript call element.requestFullscreen() will work if the element is a video element, but does no longer work if it is another element (like a DIV). If an instance of WKWebView is not affected by this bug, element.requestFullscreen() will work for all HTML elements.
Does anyone has experienced this bug as well? And maybe found a workaround? Or maybe found a pattern which helps to find out what exactly is triggering this bug?
Hi!
I configure proxy for webview like
DispatchQueue.main.async {
self.webView.configuration.websiteDataStore.proxyConfigurations = [proxyConfiguration]
}
It is fine in iosiOS 17 however, it crashes in iOS 18.3. And the problem seems to be related to the left side of the equation. I tried to call
print(self.webView.configuration.websiteDataStore.proxyConfigurations.count)
in async block and got the same bad access error. But if stop at that line of code and call
po self.webView.configuration.websiteDataStore.proxyConfigurations
in debugger it returns 0 elements.
Did anyone have the same problem? What may cause the exception?
Hi, now we could try WebGPU by manually enabling it in feature flags in no matter Safari or Safari technology preview on macOS.
But, do we know when this WebGPU feature would be enabled by default or any plan to enable it by default in Safari?
Thanks!
Topic:
Safari & Web
SubTopic:
General
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 !
Ever since the iOS and iPadOS 26.2 beta I can’t open Safari at all. Safari tries to open but crashes and goes back to my home screen. I’ve restored my devices and restarted everything and the same issue occurs. I didn’t have this problem on the beta 26.1 but this whole thing started on 26.2.
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 ?
We are building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Communication between the Angular UI and native Swift code is done using WKScriptMessageHandler.
The app mostly works without issues, but in rare edge cases, we’re seeing crashes on the main thread, and the crash is reported in Firebase Crashlytics. The root cause appears related to CFRelease and WKScriptMessageHandler.
Here’s the relevant crash stack:
Crashed: com.apple.main-thread
0 CoreFoundation 0xbfac CFRelease + 44
1 CoreFoundation 0xa734 __CFURLDeallocate + 128
2 CoreFoundation 0x730c _CFRelease + 292
3 libobjc.A.dylib 0x4e28 AutoreleasePoolPage::releaseUntil(objc_object**) + 204
4 libobjc.A.dylib 0x4cbc objc_autoreleasePoolPop + 260
5 WebKit 0x99f194 WebKit::WebUserContentControllerProxy::didPostMessage(WTF::ObjectIdentifierGeneric<WebKit::WebPageProxyIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, WebKit::FrameInfoData&&, WTF::ObjectIdentifierGeneric<WebKit::ScriptMessageHandlerIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::CompletionHandler<void (std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::String const&)>&&) + 680
6 WebKit 0x1b358 WebKit::WebUserContentControllerProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 392
7 WebKit 0xe86b0 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272
8 WebKit 0x23c0c WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44
9 WebKit 0xe3f054 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 252
10 WebKit 0x332d4 IPC::Connection::dispatchIncomingMessages() + 744
11 JavaScriptCore 0x58a7c WTF::RunLoop::performWork() + 204
12 JavaScriptCore 0x599a4 WTF::RunLoop::performWork(void*) + 36
13 CoreFoundation 0x56328 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
14 CoreFoundation 0x562bc __CFRunLoopDoSource0 + 176
15 CoreFoundation 0x53dc0 __CFRunLoopDoSources0 + 244
16 CoreFoundation 0x52fbc __CFRunLoopRun + 840
17 CoreFoundation 0x52830 CFRunLoopRunSpecific + 588
18 GraphicsServices 0x11c4 GSEventRunModal + 164
19 UIKitCore 0x3d2eb0 -[UIApplication _run] + 816
20 UIKitCore 0x4815b4 UIApplicationMain + 340
21 APP1 0xa2f80 main + 21 (AppDelegate.swift:21)
22 ??? 0x1c234eec8 (シンボルが不足しています)
Steps:
WebView: WKWebView
Message passing: WKScriptMessageHandler → passing data from Angular → Swift
WKWebView is long-lived and reused
Native is using WKUserContentController.add(_:name:) to register handlers
Crashes are intermittent (hard to reproduce), but often follow:
Screen sleep/wake
Push notification open
Angular calling native immediately after resume
Questions:
Has anyone seen this specific crash pattern involving CFRelease and WKScriptMessageHandler?
Are there known WebKit or CoreFoundation bugs related to WKScriptMessageHandler and retained URLs or message content?
Thank you for your help!
After upgrading to Safari version 18, we encountered an issue with my extension’s background script not being able to access cookies. Previously, in Safari versions 17 and below, the extension worked as expected. Now, when the extension tries to retrieve cookies using browser.cookies.getAll(), it returns an empty list. However, if we open the extension’s developer tools, the cookies are visible and accessible.
It seems that Safari only provides cookie data after the developer tools have been opened. However, after relaunching Safari and launching the extension without opening the developer tools, browser.cookies.getAll() still returns an empty list.
Has anyone else experienced this?
STEPS TO REPRODUCE
Download this minimal app : https://www.icloud.com/iclouddrive/0bajlhnuQaG6T5NsFKXEB0U9Q#test%5Fcookies
Compile test_mv2 extension (in test_cookies.getAll.zip).
Launch test_mv2.app and activate extension.
Click on the extension's button (browserAction).
Open the developer tools.
Observe an empty list of cookies.
Click on the extension's button (browserAction).
Cookies are retrieved as expected.
Based on the "Build immersive web experiences with WebXR"-Video for visionOS there is no way to disable the consent prompts for entering an immersive experience or consent hand-tracking. For the microphone it's possible to "greenlight" specific websites for mic input, which works great.
I'd welcome it, if it were possible to add specific websites in the settings, in which those consent dialogs aren't shown each time.
In my opinion, the user interaction through a button that launches the experience would be sufficient to not disorient.
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>
When attempting to authorize an Apple Payment on an iOS 18 device using the scannable code in a non-Safari browser (i.e. Chrome), the payment sheet displays briefly, then dismisses.
This same exact implementation of Apple Pay on the Web works flawlessly in Safari, so this feels like a bug given that the merchant session works fine in Safari.
The following errors were found in my iOS device logs:
(PassbookUIService) Codable: Failed to decode Merchant Session Created: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=<private>, NSCodingPath=<private>}
(PassbookUIService) Session 29592: Fatal Error: Failed to decode merchant session created`
Hi,
I have an app that uses WKWebView and it's crashing on iOS 26 Simulator in places I've never had problems before. In this case it's crashing when calling WKWebView.callAsyncJavaScript, but in my other project WKWebView is crashing with some sort of EXC_BAD_ACCESS other than callAsyncJavaScript.
Am I missing something?
Thanks,
Topic:
Safari & Web
SubTopic:
General
Hi,
I'm developing an extension and I need to debug console logs that are logged in the Service Worker. The worker is configured in the manifest and is generally working as expected:
However, when I open the browser, go to any site, and open Develop -> Service Workers or Develop -> Web Extension Background Content it is not visible there, so I can't really access the logs:
But then I noticed that if I go out of focus from the browser for some time (and probably let the SW die), it becomes visible and I can open it without an issue:
So, a couple of questions:
Why isn't it instantly accessible? The extension Service Worker dev tools should be accessible regardless of what is happening to the tab or the browser, even if the SW terminates.
Why does it eventually appear under Web Extension Background Content instead of the Service Workers when it is in fact an SW?
Hi, this is my first post in the community, so please correct me if i am posting this somewhat in a wrong manner.
Im using my Apple M1 Pro(14inch, 2021) and installed the os 26 yesterday.
Today, I was using Safari, and all of sudden it gets frozen, then the following window popped up.
Is this something expected? i.e. my usage is somewhat unusual or is there any report around potential memory leak in Safari? appreciate any suggestions, as Safari is my main browser and currently on hold due to this issue. Thanks
Starting in iOS 26 (tested on 26.1), when I use any of the “policy” methods of WKNavigationDelegate to return an action policy of cancel I get a trace like this printed to console:
1 0x18de71bbc WebKit::WebFramePolicyListenerProxy::ignore(WebKit::WasNavigationIntercepted)
2 0x18db3dd50 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)::$_0::operator()(WKNavigationActionPolicy, WKWebpagePreferences*)
3 0x100189e5c $sSo24WKNavigationActionPolicyVIeyBhy_ABIeghy_TR
4 0x100189d38 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctF
5 0x100189df4 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctFTo
6 0x18db255c0 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)
7 0x18dea9848 WebKit::WebPageProxy::decidePolicyForNavigationAction(WTF::Ref<WebKit::WebProcessProxy, WTF::RawPtrTraits<WebKit::WebProcessProxy>, WTF::DefaultRefDerefTraits<WebKit::WebProcessProxy>>&&, WebKit::WebFrameProxy&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)
8 0x18dea7a34 WebKit::WebPageProxy::decidePolicyForNavigationActionAsync(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)
9 0x18d9cbbf4 void IPC::handleMessageAsync<Messages::WebPageProxy::DecidePolicyForNavigationActionAsync, IPC::Connection, WebKit::WebPageProxy, WebKit::WebPageProxy, void (IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&))
10 0x18d9c7728 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
11 0x18e49a0d8 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&)
12 0x18df1908c WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&)
13 0x18d9dfc28 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
14 0x18e47f72c IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>)
15 0x18e47fac4 IPC::Connection::dispatchIncomingMessages()
16 0x199ad3758 WTF::RunLoop::performWork()
17 0x199ad4eb0 WTF::RunLoop::performWork(void*)
18 0x1804563a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
19 0x1804562ec __CFRunLoopDoSource0
20 0x180455a78 __CFRunLoopDoSources0
21 0x180454c4c __CFRunLoopRun
22 0x18044fcec _CFRunLoopRunSpecificWithOptions
23 0x1926be9bc GSEventRunModal
24 0x18630f0d8 -[UIApplication _run]
25 0x186313300 UIApplicationMain
26 0x18554ac38 block_destroy_helper.15
27 0x10018a70c $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ
28 0x10018a67c $s16WebkitPolicyTrap11AppDelegateC5$mainyyFZ
29 0x10018a818 __debug_main_executable_dylib_entry_point
30 0x1000cd3d0 29 dyld 0x00000001000cd3d0 start_sim + 20
31 0x1002bab98 30 ??? 0x00000001002bab98 0x0 + 4297829272
This doesn’t happen in 18.6. Also, it doesn’t seem to have any negative consequences other than the console spam? But then, the navigation is being cancelled anyway, so maybe it’s trapping and just happens to have the effect of not loading the request?
Anyway, I guess I can’t upload zips. But it’s pretty easy to reproduce. Just assign a WKWebView a navigationDelegate with an implementation like:
func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping @MainActor (WKNavigationActionPolicy) -> Void) {
decisionHandler(.cancel)
}
and then have it .load() anything. Have I been doing this wrong and 26 exposes it? Or is this a bug in 26? If the latter, any downstream consequences I should be looking out for?
macOS 15.7.1 (24G231)
Xcode 26.1.1 (17B100)
iOS 26.1 (23B86)
Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content.
The EPUB content format is XHTML and uses namespaces (for the epub:type declaration).
On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace:
0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968
1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940
2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984
3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708
4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636
5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304
6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268
7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488
8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52
9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228
10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268
I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html>
I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not.
It happens on iOS, macOS, and iPadOS.
This has never been a problem in any earlier release of macOS / iOS.
Topic:
Safari & Web
SubTopic:
General
We encountered an issue with universal links where the link failed to open the iOS application from Safari when triggered by an javascript outside a click event.
However, when we modified the code to open the link directly via a user click, the application launched as expected. Based on our testing, this issue seems to occur only when there is information for the application cached in Safari (i.e. IDP page cached, redirects to our app, javascript based universal link navigation fails).
Here is a code example of what caused the universal link failure:
const openUniversalLink = () => {
buttonClicked = True
}
useEffect(()=> {
if (buttonClicked) {
window.location.href = universal_link
}
}
<Button
onClick={openUniversalLink}
/>
Here is a code example of what caused our universal links to open successfully:
const openUniversalLink = () => {
window.location.href = universal_link
}
<Button
onClick={openUniversalLink}
/>
Are there defined practices of when we are able to open universal links triggered by javascript vs when they must be opened directly through user action?