iPad on the ramp

A CFI is between flights. They've just shut down, walked across the ramp, and they have eleven minutes to grab a coffee and confirm their next student is still showing up. They open Trim on an iPad. They try to drag the next lesson on the calendar to a later slot.

Nothing happens.

They tap again. Still nothing. The lesson sits there. They give up and pull out their laptop. The laptop is in the flight bag in the airplane. The airplane is locked.

Software has to meet the customer on the actual ramp. The actual ramp has iPads, not MacBooks.

The bug

The week-calendar's drag-to-reschedule was built with Mouse Events — onMouseDown, mousemove, mouseup. That works on every desktop browser. iOS Safari and Chrome on iPadOS do not dispatch mousemove during a finger drag. They dispatch pointer events.

So the listener was wired to an event that never fired. The drag handle was visually present but functionally dead. A CFI on an iPad would touch the lesson, watch nothing happen, and conclude the feature was broken.

The fix is Pointer Events — onPointerDown, pointermove, pointerup, pointercancel. The modern unified standard. Mouse, touch, stylus, all through one API. Plus pointer capture so the drag survives leaving the original element, plus touch-action: none so the browser doesn't try to scroll the page while you're trying to drag a lesson.

The bigger lesson

Most "this doesn't work on iPad" bugs aren't intentional. They're assumptions baked in by a developer who built on a laptop, never tested on a tablet, and shipped to a market that uses tablets eight hours a day.

The cure isn't more discipline. It's the right defaults. Every draggable, every long-press, every hold-and-move interaction in Trim now uses Pointer Events from the first line of code. Future drags don't get to opt into the old way.

A CFI on a ramp doesn't care which event API fires. They care that the lesson moves when they drag it. That's the bar.