Difference between Swift and JS implementations of Sign.instance.update

[simonmcl]

Describe the bug
This issue from WC2 is still present in ReOwn 1.0.5: WalletConnect/WalletConnectSwiftV2#1344

It also seems to be a bit worse now as we've noticed a longer delay in much of the communication between dApp and wallet in general, when using on the same device (e.g. mobile safari + mobile wallet on the same device). I asked the developer of our internal wc2 test dApp to experiment and he says its taking ~10 seconds for the dApp to receive messages from the WC2 listeners. This is not exclusive to session updates, also pairing updates etc. The wallet registers the session, it shows up on device, but the web dApp receives no update for quite some time

These issues are not present when doing cross device (e.g. desktop browser + mobile app). Possible theory is that the dApp is going to sleep when the browser closes and its taking a long time to reconnect???

[llbartekll]

I asked the developer of our internal wc2 test dApp to experiment and he says its taking ~10 seconds for the dApp to receive messages from the WC2 listeners.

can you tell which dapp you tested it with?

[simonmcl]

@llbartekll our own internal WC2 dApp is this one: https://wc2.kukai.tech/ we don't really offer it to the public for anything, so be aware it might update/break without notice

We were seeing the same thing happen with public dApps:

• OBJKT: https://objkt.com/
• fxHash (using the TEZ wallet option): https://www.fxhash.xyz/

Those use a wrapper called Beacon, which enables WC2 and its own protocol. We were using our own dApp, which is pure WC2, to try and take Beacon out of the picture. Using our own we do see traffic randomly taking a long time to go up, but we don't see anything obvious as the cause. Usually users think something is broken, keep clicking other buttons, which then usually leads to errors being displayed. We get reports of these strange ones a fair bit, and we think they are all connected to this delay

[llbartekll]

thanks @simonmcl do you experience the increased latency on iOS and android?

[simonmcl]

@llbartekll We don't have a fully functioning Android app yet. We possibly experience it on our web wallet, but its far more noticeable on iOS

[simonmcl]

FYI, were doing a bit of debugging and it seems this issue is worse when using deeplinks versus universal links. Possible this is an iOS thing that when using deeplinks the browser is being suspended immediately, but with a universal link its remaining in the background for longer. Not sure if theres something that can be done via the modals to keep a connection open

[simonmcl]

FYI, our web dev managed to debug this and found that when using deeplinks, wss://relay.walletconnect.com/ is suspended once the browser closes. But not with universal links, its given some grace period to hang around and it stays active long enough for users to return in most cases. He seems to think that iOS 18 backgrounds the browser much quicker than iOS 17 when using deeplinks, so it might be an OS level change to deal with.

When using deeplinks and returning to the webpage, it seems that there are various factors that cause the web connection to sometimes take longer to reconnect. He's seen multiple attempts to reconnect go at the same, possibly blocking each other, other times it seems to wait for the sites own API's to return before opening the WC2 connection, etc. I think the modal guys need to take a look at this stuff, and try to find ways to keep that socket open, and perhaps display spinners while its waiting to reconnect. Currently the QRCode just sits on the screen as though nothing has happened and it takes a long time to disappear, giving the user a lot of time to screw with it. And again, in cases like the issue I linked too, when the socket is down, users can't switch wallets and get feedback.

Also worth noting that he says we are stuck on the WC2 modal because the AppKit modal only supports EVM and Solana. This is a bit of an issue for us as well if the WC2 modal has support dropped or gets a lot less attention while new iOS versions come out. Would really be helpful if the AppKit modal could have some sort of a fallback mode for other chains not officially supported. He's going to open tickets on their side for this stuff, maybe you can help add some weight to it internally