fix: polish trezor send loading states

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻

[ben-kaufman]

Fixes#696

Description

This PR polishes the transient loading states in the Trezor send flow:

• shows inline loading feedback while the selected hardware-wallet source refreshes or a transaction preview is prepared
• prevents repeated source, Continue, fee, and swipe actions while their required hardware-wallet state is unavailable
• keeps the previous fee visible while a replacement preview loads, with the spinner on the speed icon
• separates a temporarily disabled swipe from the post-swipe submission spinner, matching the intended Figma behavior

This is stacked on #688. Review this PR against feat/trezor-send; it contains only the loading-state polish for that flow.

Linked Issues/Tasks

• FixesTrezor send UI polish #696
• Depends on feat: add trezor send #688
• Related Android implementation: fix: send source & fee progress ui/ux bitkit-android#1195

Screenshot / Video

Funding-source refresh	Continue preparation
Confirm preview refresh	Sign With Device

pr-708-trezor-send-polish.mov

QA Notes

Manual Tests

• 1. Send → Amount → switch the funding source to Trezor: the source chip shows a blue spinner, and the source control and Continue cannot be triggered again until the available amount finishes refreshing.
• 2. Send → Confirm → switch to Trezor or change the fee speed: the previous fee stays visible, the speed icon is replaced by its tinted spinner, and the confirmation swipe remains disabled until a valid preview is ready.
• 3. Send → Confirm → swipe after the fee is ready: the knob reaches the right side and shows the submission spinner while the flow proceeds to Sign With Device.
• 4.regression: switch back to Spending or Savings: the normal source, fee, Continue, and swipe behavior remains available.

Automated Checks

• HwFundingSignerTests: 26 tests passed, including source-refresh, unavailable-fee, and preview-loading coverage.
• SwiftFormat lint passed for the changed files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR separates disabled and submitting states in the swipe control and adds explicit hardware-wallet funding-source and preview loading state across the send flow.

• Adds tintable activity indicators and loading support to shared controls.
• Tracks hardware funding-source and transaction-preview preparation in HwSendCoordinator.
• Disables repeated source, fee, Continue, and swipe actions while required hardware state is unavailable.
• Adds coordinator tests for source refresh and preview preparation.

Confidence Score: 4/5

The hardware-source loading failure path should be fixed before merging because a fee-estimation failure can trap the send screen with no usable source-selection or Continue action.

Hardware selection now starts an externally visible loading state that is cleared only after a refresh or preview, but the amount view can return before starting either operation when its fee rate is unavailable.

Files Needing Attention: Bitkit/Views/Wallets/Send/SendAmountView.swift; Bitkit/ViewModels/HwFundingSigner.swift

Important Files Changed

Filename	Overview
Bitkit/ViewModels/HwFundingSigner.swift	Adds request-scoped funding-source and preview loading flags, including stale-request invalidation and cancellation cleanup.
Bitkit/Views/Wallets/Send/SendAmountView.swift	Connects hardware loading to source and Continue controls, but can leave both unavailable when fee resolution fails before balance refresh.
Bitkit/Views/Wallets/Send/SendConfirmationView.swift	Presents hardware preview loading on the fee icon and disables source, fee, and swipe actions until preview readiness.
Bitkit/Components/SwipeButton.swift	Separates temporarily disabled presentation from the post-swipe spinner while retaining unified interaction blocking.
BitkitTests/HwFundingSignerTests.swift	Covers successful funding-source refresh and preview-loading transitions but not unavailable fee-rate or refresh-failure recovery.

Sequence Diagram

sequenceDiagram
participant U as User
participant V as SendAmountView
participant C as HwSendCoordinator
participant F as Fee estimation
U->>V: Select Trezor
V->>C: selectWallet(showsLoading: true)
C-->>V: "isFundingSourceLoading = true"
V->>F: Resolve selected fee rate
alt Fee rate available
V->>C: refreshAvailable(...)
C-->>V: "Balance and loading=false"
else Fee estimation fails
V-->>V: Refresh guard returns
Note over V,C: Loading remains true and source control stays disabled
end

Loading

_{Reviews (1): Last reviewed commit: "fix: polish trezor send loading states" | Re-trigger Greptile}

[ovitrif]

Confirm still traps source, fee, and swipe after a missing fee rate, and the Amount → Confirm reload blanks the fee Amount just prepared.

• Switching to Trezor on Confirm sets isFundingSourceLoading through selectWallet(..., showsLoading: true), then calculateTransactionFee() returns when selectedFeeRateSatsPerVByte is nil, so nothing settles the flag. Source, fee, and swipe stay disabled until the sheet is dismissed.
• displayedTransactionFee only preserves a fee already stored in local transactionFee. Confirm's first preparePreview zeros previewFeeSats while transactionFee is still 0, so the fee from Amount disappears until the duplicate preview returns.
• testCoordinatorTracksPreviewPreparation only covers a successful estimate. Nothing would fail if preparePreview's catch stopped clearing isPreviewLoading.

[ben-kaufman]

All three Confirm loading and fee findings are fixed in signed commit bb94073 and the threads are resolved. HwFundingSignerTests passes 26 of 26. @ovitrif please re-review the updated head.

[ovitrif]

@ben-kaufman Can we please include media in PR description (screens / recs) 🙏🏻 ?
Thanks

[ben-kaufman]

@ovitrif Added four screenshots and a recording to the PR description covering the funding-source refresh, Continue preparation, Confirm preview refresh, and transition to Sign With Device. Thanks!

[ovitrif]

QA Notes

iPhone 17 simulator, iOS 26.5, regtest.

• Amount: switching the source to Trezor refreshed available funds; source and Continue were usable after settle.
• Confirm: the previous fee stayed visible across Trezor and Savings switches; swipe proceeded once the preview was ready.
• Swipe after the fee was ready reached Sign With Device.
• Switching back to Savings restored source, fee, Continue, and swipe.

Approve.

[ovitrif]

LGTM, tested all cases from QA notes.

Before merge we still need e2e green, maybe merge with master so it retriggers properly? cc. @ben-kaufman 🙏🏻

Meanwhile @piotr-iohk can have a look to confirm if the e2e failure would likely succeed next run:
https://github.com/synonymdev/bitkit-ios/actions/runs/33512189709/job/99876203530?pr=708

thanks 🙏🏻