Pull to Refresh

The whole gesture lives on the block axis: the finger goes down, the list follows, and page direction touches neither. Do not multiply the delta by a direction sign and do not reach for var(--dir) the way you would on an inline-axis control, because clientY on its own is enough and transform: translateY(...) is correct in both directions. Teams that apply a blanket "every gesture flips" rule to this element land on an indicator that travels upward in the Arabic build, or on a negative threshold that never resolves.

The indicator turns clockwise in Arabic exactly as it does in English, because rotation direction is a clock convention and carries no linguistic meaning to flip. A blanket [dir="rtl"] svg { transform: scaleX(-1) } turns it counter-clockwise and mirrors the pull arrow along with it, so scope the flip to a class you put on horizontal arrows by hand; transform has no logical form, so the browser will never make that call for you. In UIKit, UIRefreshControl draws its own spinner and takes no image, and if you substitute a custom one, do not call imageFlippedForRightToLeftLayoutDirection() on it: that call is an explicit request to mirror, and a vertical arrow has nothing to reverse.

Any text that rides with the indicator ("Pull to refresh", "Last updated 9:41") follows page direction, so align it with text-align: start and not left. If you lay the circle and the text out in one row, use gap and padding-inline instead of margin-left, because the visual order of the row flips while DOM order stays put. The timestamp is its own hazard: dropping 12:04 PM or a Latin time-zone name into an Arabic sentence lets the bidi algorithm reorder the pieces on screen, so isolate the run with <bdi> or unicode-bidi: isolate and PM will stop jumping to the head of the line.

Layer horizontal swipe actions onto the same rows and you are on the inline axis, which mirrors completely: what a leftward drag uncovered in English is uncovered by a rightward drag in Arabic. In SwiftUI write .swipeActions(edge: .trailing), and on Android pass ItemTouchHelper.START and ItemTouchHelper.END to SimpleCallback rather than LEFT and RIGHT, because the first pair resolves against the layout direction and the second is physical. The dX value inside onChildDraw stays physical regardless (negative for leftward motion whatever the layout direction), so read the sign from layoutDirection before you decide which button to paint behind the row.

The gesture is vertical, but the chrome around it is not, and the SwipeRefreshLayout circle sits centred so nothing in it mirrors on its own. The moment you offset it toward one side or park a label beside it, use padding-inline-start and margin-inline-end on the web and NSDirectionalEdgeInsets in UIKit. UIScrollView.contentInset is a UIEdgeInsets with physical left and right fields and no logical counterpart on that type, so what you set there stays where it was when the app flips and you have to swap it by hand.