[jvsena42]

Twin: synonymdev/bitkit-android#1582

This PR lets a sideways swipe over the USDT receive QR change tabs, as it does on the other receive tabs. Before, swiping out of USDT did nothing.

Description

• UsdtReceiveView: with USDT selected, ReceiveQr replaces the paged TabView with this view, so a horizontal swipe had nothing to move. The address content now uses swipeSegmentedTabs, the helper Settings, Shop and All Activity already use. A swipe right selects the tab before USDT (Spending); a swipe left does nothing, since USDT is the last tab.
• swipeSegmentedTabs: takes an optional tabs list in display order. Receive shows only some ReceiveTab cases (no Auto or Hardware tab here), so stepping through allCases would land on a hidden tab. Existing callers pass nothing and keep allCases.
• swipeSegmentedTabs: takes simultaneous, used only here, so on the USDT page a swipe down still closes the Receive sheet (review round 1; before, the high-priority drag took it). Settings, Shop and All Activity keep the high-priority gesture.
• The QR still copies on tap. On iOS a swipe never copied, because the QR uses onTapGesture; the Android twin also fixes a copy on swipe.

Out of Scope

• SegmentedControl: tab identifiers follow the app language (segmented control tab identifiers change with the app language #1019).

Design

Receive USDT › HW QR on the Refactor v63 page. No visual change.

Preview

iPhone 17e simulator (iOS 26.5), USDT enabled, swipes driven with AXe across the middle of the QR (300 ms). With the before build, a swipe from Savings moved to Spending, so the gesture itself was delivered.

Before: swipe right, still on USDT	After: swipe right selects Spending	After: swipe left returns to USDT	After: swipe left on USDT stays	Figma

Recordings

Before:

before.mp4

After:

after.mp4

QA Notes

Journeys

• new usdt-receive-swipe-tabs.xml: swiping right over the USDT QR selects Spending without copying; swiping left stays on USDT; a tap still copies. Ported from the Android twin

Manual Tests

N/A

Automated Checks

• ran a simulator build of this branch merged with the other 3.1.0 batch branches: succeeded; SwiftFormat passed on the changed files. No unit test covers the gesture.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Adds sideways swipes to the USDT receive address view.

• Swiping over the USDT QR now moves to the previous receive tab.

Review was based on source inspection. The native iOS UI could not be run or captured in this Linux environment.

_{Reviews (1) · Last reviewed commit: "fix: swipe between receive tabs from the..." · Reviewed by Greptile}

[talosmachina]

No findings. Adds the segmented-tab swipe to the USDT receive address view, stepping through the visible receive tabs instead of allCases. Reviewed ea5252d, light tier.

What I checked, and 4 candidates I ruled out

Read in full: View+SwipeGestures.swift, UsdtReceiveView.swift, ReceiveQr.swift
Call sites traced: swipeSegmentedTabs (Settings, Shop, All Activity keep allCases via the nil default), UsdtReceiveView(tabs:onSelectTab:) from ReceiveQr
CI: validate green; build-local, Run Tests and Run Integration Tests still running when posted. Reviewed from the code and CI; iOS does not build on this box.

Ruled out

• Swipe lands on a hidden tab: tabs.map(\.tab) is availableTabItems, the same list the SegmentedControl shows, so Auto and Hardware appear only when they are shown and USDT is always last.
• Selection skips ReceiveQr's bookkeeping: the setter is onSelectTab, which writes selectedTabBinding, so hasUserSelectedTab and onUsdtSelectionChange fire as they do for a tap.
• Swipe active on the network, amount or fee pages: the modifier sits only on the .address case.
• Tap to copy broken: the drag needs 20 pt before it starts and acts only past 50 pt horizontal, so the QR's onTapGesture still fires on a tap; existing callers wrap scrolling content the same way.

Merge confidence: 4/5, the iOS build and tests had not finished, and no test covers the gesture (the journey is the check).

[ovitrif]

@jvsena42 a follow-up on this PR and its Android twin: I'd like the Receive tabs to swipe on every tab and wrap around (swipe back on the first tab goes to the last, swipe forward on the last goes to the first), and a sideways swipe must never dismiss the Receive sheet. Tracked in synonymdev/bitkit-android#1590 and #1024.

The dismissal repro: on USDT, swipe sideways and release above the sheet; Receive closes. On Spending the same swipe doesn't, since the pager consumes the drag. Consuming the drag after touch slop here may already fix it.

Would you fold this into your PRs, or should I open a follow-up stacked on your branches?

[ovitrif]

@jvsena42 I've opened the wraparound as a follow-up stacked on this branch: #1027, so this PR stays as it is. When this one merges, it retargets to master.

One thing I found on this branch: on the USDT address page a swipe down no longer closes the Receive sheet, because the high-priority drag from swipeSegmentedTabs takes it. On the other tabs it still closes. A sideways swipe released above the sheet does not close Receive on iOS.

[jvsena42]

@ovitrif thanks. Swipe down on the USDT page: reproduced and fixed in 047370c.

swipeSegmentedTabs attached its drag as a highPriorityGesture, so on the USDT address page it took the sheet's vertical drag too. It now takes simultaneous: true, used only by UsdtReceiveView; Settings, Shop and All Activity keep the high-priority gesture. iPhone 17e simulator, AXe swipes:

Before: swipe down on USDT, Receive stays open	After: the same swipe closes Receive

Sideways after the fix, left to right: a right swipe selects Spending; a left swipe returns to USDT; a diagonal swipe released high above the sheet (240 pt across, 300 pt up) leaves Receive open on USDT.

Recordings

after-swipe-down.mp4

after-sideways.mp4

This adds a simultaneous parameter after animation in swipeSegmentedTabs, so #1027 will need a small rebase around that signature. Android (#1582) is not affected the same way: detectHorizontalDragGestures only takes horizontal drags, so a vertical drag still reaches the sheet. That is from the code; I did not drive it on the emulator in this pass.

Wraparound in #1593 / #1027 sounds good, thanks for stacking them.

[greptile-apps]

Greptile encountered an error while reviewing this PR. Please reach out to support@greptile.com for assistance and include this reference: 9c4ff2ce-1881-4bc3-907b-b892ea74b4aa.

[ovi-reviewer]

Verdict: ✅ Approve

Findings: None.

QA for 047370c:

Tested on iPhone 17 Pro simulator, iOS 26.5.

Test 1: USDT receive swipe tabs and tap to copy ✅ Swipes select the expected tabs without copying; a tap still copies.

I ran all seven actions in journeys/receive/usdt-receive-swipe-tabs.xml: swiping right over the USDT QR selects Spending, a 600 ms left swipe returns to USDT, and swiping left on USDT keeps it selected. Neither swipe shows the copied tooltip. Clipboard readback also stayed unchanged after both swipes; tapping the QR copied the displayed USDT address and showed the tooltip.

usdt-receive-swipe-tabs-2x.2x.mp4

For swipe-down dismissal and the diagonal swipe released above the sheet, I relied on @jvsena42's recordings at 047370c: swipe down closes Receive, while the diagonal swipe leaves it open. I checked those recordings; these cases were not repeated here.

Twin: synonymdev/bitkit-android#1582 matches the tab selection, end-of-list behavior and tap-to-copy contract; its journey was also verified.

Reviewed the full four-file PR diff, including receive selection, QR copying and sheet handling. Existing Settings, Shop and All Activity callers were checked in code; no device case drove those unchanged callers.

---

Reviewed by gpt-6.1-sol-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

utAck

[ovitrif]

@jvsena42 I merged master into this branch (b0ca762) so it passes the new SwiftFormat 0.64.0 lint and warnings-as-errors build from #1028; no changes to your code. It needs a fresh approval on the new head.

[jvsena42]

@ovitrif thanks for the merge. The SwiftFormat check on b0ca762 fails on Bitkit/Views/Wallets/Activity/ActivityRow.swift:104-105 (wrapIfStatementBodies), which this PR does not touch. Master fails the same way at cf2b97e: those one-line if bodies came in with #1002, merged alongside #1028. SwiftFormat 0.64.0 on this branch reports no other file.

[ovi-reviewer]

Verdict: ✅ Approve

Findings: None.

QA for b0ca762: Passing evidence carried from 047370c; the merge preserves the tested gesture behavior, so no device cases were repeated.

Test 1: USDT receive swipe tabs and tap to copy ✅ The earlier run passed all seven journey actions.

The previous review verified right swipe to Spending, the 600 ms return swipe, left swipe staying on USDT, and tap-to-copy. Its clipboard readback confirmed swipes did not copy and a tap copied the displayed address. The helper, QR copy code and journey are unchanged.

usdt-receive-swipe-tabs-2x.2x.mp4

Test 2: Swipe down on USDT ✅ The earlier recording shows Receive closing.

Carried from @jvsena42's verified recording at 047370c. The simultaneous gesture and sheet dismissal handling are unchanged.

after-swipe-down.mp4

Test 3: Diagonal swipe released above Receive ✅ The earlier recording shows the sheet staying open.

Carried from the same verified report at 047370c. The swipe thresholds and sheet gesture handling are unchanged.

after-sideways.mp4

The exact-head Debug simulator build passed on Xcode 27.0 with warnings treated as errors.

@jvsena42 I reproduced the SwiftFormat failure at ActivityRow.swift:104-105 and confirmed that file is identical to the pinned master base. It is covered by synonymdev/bitkit-ios#1035 chore: make master pass the swiftformat check.

Twin: synonymdev/bitkit-android#1582 fix: swipe between receive tabs from the usdt qr matches tab selection, endpoint behavior and tap-to-copy.

Reviewed the delta from 047370c to b0ca762, including master-merge interactions with Receive. Existing Settings, Shop and All Activity callers and other inherited changes were inspected in code, without new device coverage.

---

Reviewed by gpt-6.1-sol-high via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

utAck

[ovitrif]

Merged, as it was approved and green.