Wrapper Latency

title: Wrapper Latency
dated: Top of 2026
author: Ivan Reese
related: Pens & Hands

Here are some latency tests, visualizing touches both in the wrapper and in the js app, so we can grapple with the impact of bridging between Swift and WKWebView (as opposed to going pure Swift).

3 tests — one with a finger moving at medium speed, one with the pen moving at high speed, and one with the pen wiggling. You’ll see each test a few times: twice at 1x, then 1/8x, and then with a freeze frame of additional info.

Here are the freeze frames from the video, so you don’t have to pause. I also tried to estimate the latency times.

Ivan Yeah, the ms numbers are unreadably small — just use pinch-zoom or whatever!

Ivan That 25ms line looks unnaturally long, but remember: the pen is accelerating sharply, and the size of the following 8ms line is a wildly inaccurate estimate.

When I say “real” touch, I mean “a measured position, not a predicted position”.
Latency numbers in the photos are shown in ms because the swift wrapper runs at 120hz and the JS runs at 60hz, so it’s harder to talk about frames of latency (which would otherwise be my preference)
the “8-16ms” latency is where you see the effect of 120 vs 60
The “best predicted touch (Swift, estimate)” is something I’ve just added in post. The wrapper doesn’t draw predicted touches, and I didn’t bother adding them because I don’t want to spend that much time on these latency tests, but I have a reasonably good sense of where they’d be (since the best prediction seems to always be about 8ms ahead of the best real touch).

This last freeze-frame captures a bug where an errant hover (I think) appears whenever a pen stroke ends, at the position where the pen stroke began. So, note to self, track this down.