In the current implementation, when you call addClass/removeClass, to get the timing, the library adds the class, gets the timing and removes the class again, hoping that the browser wouldn't notice if it's fast enough. And then it adds the class again to make the actual animation.

The problem with this, is that with slower devices, the browser starts the animation before the code has time to remove the class. This causes the animation to start, cancel, and then start again.

You can check the bug on mobile devices using the following fiddle (full screen version). I added some layers to make the device choke a little. I tested that fiddle causing the issue, on a current gen iPod Touch, running iOS 7. Also tested on an iPod Touch 4g running iOS 6.1. And it also happened using the vanilla Android Browser on Android 4.1 in the Android emulator. You might have to tap a few time before you see the issue.

On mobile or desktop Chrome the issue is not visible, at least on Android 4.4.2.