@DTS Engineer Thank for your answer. In summary, our issue is not straightforward. On the application site, everything functions correctly. The problem lies on the client (browser) side. I am uncertain whether a race condition or a similar condition may be the cause of this issue. All of our JavaScript code executed for this purpose is synchronous, resulting in no concurrency. The problem occurs precisely at the moment when this code executes: “window.location.assign” Therefore, there is nothing complex about it. We are simply redirecting the current page to the Universal Link. This operation works fine in most conditions but doesn't when the same Safari tab is being used. We do not see any errors in the Browser javascript console. Our flow will not function without JavaScript, as it is the only option to automatically redirect to the Universal Link without user interaction. Perhaps the issue is not with the Universal Link itself, but rather with the browser, which is unable to properly handle the link in this case or something stored in the browser memory that prevents the link from opening again without user interaction. What information would be helpful in this regard? Thank you for your help.

Any update on this @DTS Engineer ? We are currently stuck in making progress on this issue. We'd appreciate guidance on what to do to avoid such behavior. As explained, we believe our Universal link are configured correctly since App switch works correctly initially.

We did follow the debugging guide. The issue here is to understand why it works correctly the first time, meaning that the Apple-app-site-association files and associated domains are configured correctly, and not the second time while remaining on the same tab. We need help understanding what the security difference is between the first invocation and second knowing that it is the exact same website executed and javascript code executed on both attempts.