Today day-swipe runs in opposite directions on Apple and Android, and the Apple side reads inverted

[andremiliano]

What

The Today day-navigation swipe runs in opposite directions on Apple and Android. The same finger movement moves the day backwards on one platform and forwards on the other.

Apple — swipe LEFT goes to the OLDER day:

// Strand/Liquid/LiquidTodayView.swift:267-273
/// Horizontal swipe between days (left = older, right = newer), clamped to [today, earliest].
…
let delta = dx < 0 ? 1 : -1

The classic shell agrees with the liquid one, so Apple is at least self-consistent:

// Strand/Screens/TodayView.swift:1248-1249
// Swipe LEFT (dx < 0) -> OLDER day (+1 offset); swipe RIGHT -> NEWER day (-1 offset).
let delta = dx < 0 ? 1 : -1

Android — swipe RIGHT goes to the OLDER day:

// android/app/src/main/java/com/noop/ui/TodayDayNav.kt:58-62
internal fun dayNavSwipeTarget(selectedOffset: Int, dragX: Float, thresholdPx: Float): Int = when {
    abs(dragX) < thresholdPx -> selectedOffset
    dragX > 0f -> dayNavOlder(selectedOffset)
    else -> dayNavNewer(selectedOffset)
}

TodayScreen.kt:1294-1305 describes that lane as mirroring the iOS one, which is where the two appear to have drifted: the Kotlin comment claims parity the mapping does not have.

Both selectors are pure and unit-testable, and neither has a test pinning the direction, which is presumably how this survived.

Why it is a bug rather than a preference

Under the parity contract the behaviour is supposed to match across platforms, and here one gesture produces opposite outcomes. A wearer running both, or moving between them, gets the day moved the wrong way every time.

Separately, on Apple the direction also runs against the usual expectation for a horizontally paged date view, where dragging the content leftwards brings the next (later) page in from the right — the pattern Calendar, Health and Fitness follow. That was how this surfaced: on iOS 11.8.0 a wearer swiping right-to-left expected to move forwards and went backwards instead, and read it as inverted. Android's mapping is the one that matches that expectation.

What needs deciding

Which platform changes. That is a product call, not a mechanical one, since either fix changes the muscle memory of the wearers already used to it:

• Change Apple to match Android — aligns Apple with the platform convention above, and leaves Android users untouched.
• Change Android to match Apple — smaller blast radius if Apple's direction is intentional, but keeps the Apple side reading backwards against its own OS conventions.

Whichever is chosen, a test on each pure selector (clampedDayOffset / dayNavSwipeTarget) pinning "this drag sign yields this direction" would stop it drifting again, since both are already pure and neither is covered today.

Happy to open the PR for whichever direction is preferred, including the twin test on both sides.

Verification

Read against v11.8.0 (ef0c0d72) and origin/main; the cited lines are unchanged between them. The Apple behaviour was observed on an iPhone running a build of main with the #2377 header change on top; nothing in that branch touches the gesture. The Android behaviour is from the source only — not checked on a device.