fix: ios crashing because of seeker lib

[NeOMakinG]

iOS was crashing because we were trying to initiate the seeker wallet manager but this is importing a library that is trying to get an android module, we need to guard that to avoid the crash!

How to test

run yarn expo ios and verify in the emulator that the app is not crashing

Summary by CodeRabbit

Version 3.7.2

• Bug Fixes
  • Resolved critical iOS stability issue preventing proper wallet functionality that could cause unexpected app crashes
  • Seeker wallet feature is now available exclusively on Android devices for optimal compatibility and performance
  • Improved platform-specific runtime handling to enhance app stability and reliability across all supported platforms

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR increments the app version to 3.7.2 and adds platform-specific guards to ensure Seeker wallet functionality and related module imports only occur on Android, preventing iOS runtime crashes from loading Android-specific dependencies.

Changes

Cohort / File(s)	Summary
Version Update app.json	Version and runtimeVersion incremented from 3.7.1 to 3.7.2.
Android-Only Seeker Wallet Hooks src/hooks/useSeekerWallet.tsx	Added Platform import and guard clauses to useEffect hooks to short-circuit and disable Seeker wallet functionality on non-Android platforms.
Dynamic Module Loading src/lib/SeekerWalletManager.ts	Converted static import of transact to dynamic import() in checkAvailability and reauthorize methods to defer module loading at runtime and prevent iOS crashes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• fix: remove android and handle error #146: Addresses platform-specific top-level imports causing runtime crashes by deferring module loading to runtime via dynamic imports.

Suggested reviewers

• 0xApotheosis

Poem

🐰 Hop hop, the Android way,
Guard those imports, keep crashes at bay,
iOS stays safe while Android plays,
Dynamic loading saves the day! ✨

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly addresses the main change: fixing iOS crashes caused by the Seeker wallet library by conditionally loading Android-specific code.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-ios

---

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.}

[coderabbitai]

🧹 Nitpick comments (1)

src/hooks/useSeekerWallet.tsx (1)

18-23: Move getSeekerWalletManager() call behind Platform guard to avoid loading iOS-incompatible dependencies.

getSeekerWalletManager() triggers instantiation of SeekerWalletManager, which statically imports expo-seed-vault and other iOS-incompatible modules. Although the hook early-returns on non-Android platforms, these imports execute unconditionally at the component root, causing unnecessary module loading on iOS.

Suggested approach

 export const useSeekerWallet = () => {
   const [isAvailable, setIsAvailable] = useState<boolean | null>(null)
   const [isAuthorized, setIsAuthorized] = useState(false)
   const messageManager = getMessageManager()
-  const seekerManager = getSeekerWalletManager()
 
   useEffect(() => {
     if (Platform.OS !== 'android') {
       return
     }
 
+    const seekerManager = getSeekerWalletManager()
     // Check availability on mount
     void seekerManager.checkAvailability().then(available => {

(Similarly for the second useEffect.)

[gomesalexandre]

Untested but discussed in DM, sounds sane to me