A team builds a reorderable list using the browser's native HTML5 Drag and Drop API, tests it on a laptop, and ships it. Within a week, mobile users report that dragging doesn't work at all, or that it works erratically, items jumping unpredictably or the drag canceling itself mid-gesture. This isn't a bug in the implementation. It's a fundamental limitation in what the API was designed to do.
This pattern repeats often enough to be predictable: the feature is built and reviewed entirely on a laptop trackpad, ships to a user base that's majority mobile, and the first real signal that anything is wrong arrives as a wave of confused support tickets rather than a caught bug in code review.
The API Was Built for Desktop, Full Stop
The HTML5 Drag and Drop specification was written with desktop mouse interaction as the only real target. Its core events (dragstart, dragover, drop) map naturally onto a mouse button press, a cursor movement, and a mouse button release. There is no equivalent concept baked into the spec for a finger touching glass.
Mobile browser vendors have added partial touch support over the years, but it's inconsistent across platforms and versions in ways that make it unreliable for production use. Safari on iOS has historically had different, more limited behavior than Chrome on Android for the same native drag events, and neither behaves identically to how the same code runs on desktop.
The Touch-vs-Scroll Ambiguity Problem
The deeper issue isn't just inconsistent vendor support, it's a fundamental ambiguity the native API doesn't resolve well. A finger touching a draggable element and immediately moving could mean "I want to drag this" or "I want to scroll the page." A mouse has no equivalent ambiguity, since scrolling and dragging use entirely separate input mechanisms (a scroll wheel or trackpad gesture versus a button-and-move sequence).
Native drag and drop on mobile often resolves this ambiguity poorly, either hijacking legitimate scroll gestures as accidental drags, or failing to recognize an intentional drag because the browser interpreted the initial movement as a scroll. Users experience this as the feature simply not working reliably, without any clear pattern to when it fails.
Checking actual support tables on Can I Use for the specific drag and drop events involved makes the scope of the inconsistency concrete rather than anecdotal. It's rarely a case of the API being entirely unsupported on a given mobile browser, it's a case of specific events firing at different times, with different data available, or not firing at all under specific gesture conditions, which is a harder class of bug to catch in testing than an outright missing feature.
Why This Keeps Surfacing in Code Review Too Late
Code review rarely catches this problem, because the code itself looks correct. The event listeners are wired up properly, the drag handlers do what they're supposed to do, and a desktop browser test confirms the feature works. Nothing about the code review process flags "this API has known mobile reliability problems" unless a reviewer happens to have hit this exact issue before.
That's part of why this specific failure mode is so common across unrelated teams and codebases. It isn't a mistake any single engineer makes carelessly, it's a gap in the platform itself that isn't visible until real touch devices are in the loop, and most local development and code review happens entirely on desktop hardware.
Photo by Walls.io on Pexels
What Pointer Events Solve That Native Drag Doesn't
The alternative most production teams land on is building drag-and-drop directly on top of the Pointer Events API (pointerdown, pointermove, pointerup), which unifies mouse, touch, and pen input behind a single event model with consistent behavior across browsers and devices.
Pointer events give you full control over the touch-vs-scroll decision instead of leaving it to inconsistent browser heuristics. A common pattern is requiring a brief hold (roughly 150 to 250 milliseconds) before a touch commits to being a drag rather than a scroll, giving the browser's native scroll behavior priority unless the user clearly intends to drag.
Libraries Already Handle This Correctly
Building the pointer event handling, auto-scroll near container edges, and cross-device consistency from scratch is a meaningful amount of work to get right. interact.js and dnd kit both build on pointer events rather than native drag and drop specifically because of the mobile reliability problems described above, and both have already solved the touch-vs-scroll ambiguity in a way that's been tested across a wide range of real devices.
Starting from one of these, rather than either fighting the native API's mobile limitations or reimplementing pointer event handling from scratch, is the faster and more reliable path for anything that needs to work well on a phone or tablet.
When Native Drag and Drop Is Still the Right Choice
None of this means the native API is broken or useless. It remains the correct tool for desktop-only interactions involving files: dragging a file from the operating system's file browser into a web upload zone, or dragging content between separate browser windows or tabs. These use cases specifically need OS-level integration that no JavaScript-only library replicates, and the native API is the only way to get it.
The mistake isn't using native drag and drop, it's using it for an interaction that also needs to work on a touchscreen. If the feature only ever needs to work on desktop with a mouse, native HTML5 drag and drop is still a reasonable, low-dependency choice.
A reasonable middle path some teams take is feature detection: use native drag and drop for the desktop file-drop use case specifically, while building the general reordering interaction on pointer events regardless of device. This avoids maintaining two entirely separate drag implementations while still getting the OS-level file integration that only the native API provides.
Migrating an Existing Feature Without a Full Rewrite
Teams discovering this problem after a feature has already shipped don't need to rebuild everything at once. The pointer event handling can be introduced incrementally: wrap the existing drag logic in a compatibility layer that listens for pointer events and translates them into the same internal state changes the native drag handlers already produce, then gradually retire the native event listeners once the pointer-based path is confirmed stable across real devices.
This staged approach costs more calendar time than a clean rewrite but meaningfully reduces the risk of introducing new regressions in a feature that's already live and depended on. Running both implementations side by side behind a feature flag for a short rollout window, comparing error rates and support ticket volume before fully cutting over, is a reasonably low-risk way to validate the migration before removing the old code path entirely.
The Practical Takeaway
Before building a drag-and-drop feature, decide explicitly whether mobile support is required. If it is, skip native HTML5 drag and drop entirely and build on pointer events, either directly or through a library that already handles the cross-device edge cases. If the feature is genuinely desktop-only and involves dragging files from the OS, native drag and drop remains the simpler, dependency-free option.
The broader set of decisions around building drag-and-drop well, including keyboard access and drop-target feedback, are covered in the fuller guide on how to design drag-and-drop interactions that work on touch and desktop.
More production engineering write-ups like this one are at https://137foundry.com.
Top comments (0)