fix(swift-example-app): harden Withdraw Credits amount + address validation

[QuantumExplorer]

Issue being fixed or feature implemented

Follow-up to #3906 (Withdraw Credits production UI, ID-10), which merged before review feedback from thepastaclaw was addressed. Two issues in WithdrawCreditsView:

• 🔴 Blocking — parsedCredits could crash on large input. Double(UInt64.max) isn't exactly representable and rounds up to 2^64, so the credits <= Double(UInt64.max) guard admitted 2^64 and UInt64(credits) trapped. parsedCredits recomputes on every keystroke (before submit-time re-validation), so an amount scaling to ~2^64 credits would crash the sheet on input rather than show a friendly error. (Same shape exists in the merged TransferCreditsView.parsedCredits — flagged separately as a follow-up.)
• 🟡 UX — submit enabled for any non-empty destination. The button lit up for malformed / wrong-network addresses; the user only learned otherwise after the Rust round-trip.

What was done?

• parsedCredits: switched the upper bound to strict < so 2^64 is rejected and the UInt64 cast stays in range.
• Destination validation: added isValidDestinationAddress, which uses the existing DashAddress.parse(_, network:) bridge (Base58Check + network validation in Rust) and accepts a .core (L1) result. canSubmit and the submit() guard now require a valid address, and an inline "Not a valid Dash address" hint explains the disabled state. No consensus logic added to Swift — authoritative validation still runs in Rust on submit, matching the file header.

How Has This Been Tested?

./build_ios.sh-equivalent app build succeeds (0 errors, 0 code warnings). Driven on the simulator (devnet):

• Invalid destination → submit stays disabled + inline hint shown.
• Amount of 2×10⁸ DASH (huge) → sheet no longer crashes; button stays disabled.

Breaking Changes

None. UI-only validation hardening in the example app.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any (n/a)
• I have made corresponding changes to the documentation if needed (n/a)

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@QuantumExplorer, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 8 minutes and 31 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d75ca5dd-7176-4648-960a-850bbae21eb5

📥 Commits

Reviewing files that changed from the base of the PR and between bf0df5d and 6ae7f99.

📒 Files selected for processing (1)

• packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/WithdrawCreditsView.swift

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/withdraw-credits-validation-fix

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[thepastaclaw]

✅ Review complete (commit 6ae7f99)

[thepastaclaw]

Code Review

Tight, well-scoped UI hardening on SwiftExampleApp's Withdraw Credits sheet. Strict < against Double(UInt64.max) correctly avoids the rounding-to-2^64 trap on UInt64(credits), and the new isValidDestinationAddress delegates to the existing Rust-backed DashAddress.parse bridge while keeping authoritative validation in Rust on submit. Diff is confined to WithdrawCreditsView.swift; no FFI, consensus, or business-logic surface area is affected.

[github-actions]

✅ DashSDKFFI.xcframework built for this PR.

• Workflow run: https://github.com/dashpay/platform/actions/runs/27573956536
• Artifacts: DashSDKFFI.xcframework (folder), DashSDKFFI.xcframework.zip, xc_checksum.txt

SwiftPM (host the zip at a stable URL, then use):

.binaryTarget(
  name: "DashSDKFFI",
  url: "https://your.cdn.example/DashSDKFFI.xcframework.zip",
  checksum: "5fdc8698e53d69ec7b7089a9feb17eacdb1bbe2c4ec9aa38740bab1008a94eb6"
)

Xcode manual integration:

• Download 'DashSDKFFI.xcframework' artifact from the run link above.
• Drag it into your app target (Frameworks, Libraries & Embedded Content) and set Embed & Sign.
• If using the Swift wrapper package, point its binaryTarget to the xcframework location or add the package and place the xcframework at the expected path.