You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On an iPhone, in Safari or Chrome (both WebKit), open a dApp using AppKit with email/social login enabled (features.email / features.socials via the AUTH connector).
Start the connect flow, choose "Continue with email", enter an email address.
Enter the 6-digit OTP code sent to that email and submit.
Once connected, trigger a signature request (wagmi's signMessage(), via the AUTH connector) to authenticate the session.
Observe the sign confirmation popup rendered by the secure iframe (secure.walletconnect.org/sdk): it appears but is completely unresponsive (cannot tap Sign/Cancel, cannot scroll) for approximately 20-30 seconds before becoming interactive. After that it works normally.
Summary
Expected: the sign confirmation popup should be interactive as soon as it's rendered.
Actual: on iOS only (both Safari and Chrome, i.e. WebKit - not reproducible on Android, and not reproducible with external wallets like MetaMask/Phantom, which render their confirmation UI in a separate native app rather than an in-page iframe), the popup is frozen/unresponsive for ~20-30 seconds after opening. This is consistently reproducible, see attached recording.
During an earlier debugging session (Safari Web Inspector attached to a physical iPhone), we captured a likely cause:
The secure iframe itself re-navigates to a fresh URL when the sign request starts, and that document load completes quickly (~20ms) — so it isn't a slow iframe/page load.
During the freeze window, two requests to https://pulse.walletconnect.org/batch (sent via navigator.sendBeacon from EventsController, i.e. AppKit's own SDK usage-analytics reporting, not our application code) were observed failing to connect, taking ~10.4s and ~15.1s respectivel - a combined duration matching the observed freeze almost exactly. Console showed the native Safari error: "Beacon API cannot load https://pulse.walletconnect.org/batch?... Could not connect to the server."
On a repeat attempt where these requests didn't fail, the freeze was correspondingly shorter (~5-10s)
Direct navigation to https://pulse.walletconnect.org returns a normal 404 (expected, it's an API-only endpoint), confirming the domain itself is reachable — the failures are specific to the sendBeacon request pattern, not general connectivity or a blocked/unreachable host. Reproduced on both WiFi and cellular.
Note this specific network-level correlation is intermittent and hasn't reproduced on every attempt since (the popup freeze itself has, consistently) - we're reporting it as the most likely cause based on the strength of that timing correlation, not as a guaranteed root cause on every occurrence.
Our hypothesis: these background analytics requests are made from the page's top-level JS context (not the iframe), and are unrelated to the sign iframe itself, but a hung/slow connection attempt from the same tab appears to compete for iOS Safari's limited per-tab connection pool, stalling the sign iframe's own network activity until the analytics requests give up. This would explain why only iOS/WebKit is affected (possibly due to Intelligent Tracking Prevention treating pulse.walletconnect.org as a tracking/analytics domain and throttling background requests to it) and why external wallets (native app handoff, no iframe/shared tab) are unaffected.
We tried setting features.analytics: false, but this does not fully prevent the behavior, since SOCIAL_LOGIN_SUCCESS is hardcoded into EventsController's MANDATORY_EVENTS list and is still sent regardless of that flag.
Would appreciate a look into whether this analytics beacon can be made to not compete with/block the sign flow's own network activity (e.g. a shorter internal timeout, or fully isolating it from the critical path), and whether there's a supported way to disable it entirely including mandatory events.
Link to minimal reproducible example
ScreenRecording_07-17-2026.10-44-32_1.MP4
Steps to Reproduce
Summary
Expected: the sign confirmation popup should be interactive as soon as it's rendered.
Actual: on iOS only (both Safari and Chrome, i.e. WebKit - not reproducible on Android, and not reproducible with external wallets like MetaMask/Phantom, which render their confirmation UI in a separate native app rather than an in-page iframe), the popup is frozen/unresponsive for ~20-30 seconds after opening. This is consistently reproducible, see attached recording.
During an earlier debugging session (Safari Web Inspector attached to a physical iPhone), we captured a likely cause:
Note this specific network-level correlation is intermittent and hasn't reproduced on every attempt since (the popup freeze itself has, consistently) - we're reporting it as the most likely cause based on the strength of that timing correlation, not as a guaranteed root cause on every occurrence.
Our hypothesis: these background analytics requests are made from the page's top-level JS context (not the iframe), and are unrelated to the sign iframe itself, but a hung/slow connection attempt from the same tab appears to compete for iOS Safari's limited per-tab connection pool, stalling the sign iframe's own network activity until the analytics requests give up. This would explain why only iOS/WebKit is affected (possibly due to Intelligent Tracking Prevention treating pulse.walletconnect.org as a tracking/analytics domain and throttling background requests to it) and why external wallets (native app handoff, no iframe/shared tab) are unaffected.
We tried setting features.analytics: false, but this does not fully prevent the behavior, since SOCIAL_LOGIN_SUCCESS is hardcoded into EventsController's MANDATORY_EVENTS list and is still sent regardless of that flag.
Would appreciate a look into whether this analytics beacon can be made to not compete with/block the sign flow's own network activity (e.g. a shorter internal timeout, or fully isolating it from the critical path), and whether there's a supported way to disable it entirely including mandatory events.
List of related npm package versions
@reown/appkit: ^1.8.22
@reown/appkit-adapter-wagmi: ^1.8.22
@reown/appkit-wallet: 1.8.20
@reown/appkit-controllers: 1.8.20
wagmi: ^3.6.16
viem: 2.52.2
Node.js Version
v20.11.1
Package Manager
yarn@1.22.21