Tailored Wallet Solutions for Mobile Platforms

A user loses their seed phrase — 12 words scribbled on a scrap of paper. A $200k account is frozen forever. A non-custodial wallet should architecturally exclude such scenarios: the private key is encrypted and stored only on the device, recovery is possible only via the mnemonic. At True Tech, we have been developing non-custodial crypto wallets for years, delivering 15+ projects for iOS and Android. Our experience shows that the key is correct implementation of BIP standards and secure seed storage. Non-custodial mobile crypto wallet development requires careful attention to these details. We provide mobile wallet development services, including BIP39 crypto wallet creation, iOS crypto wallet and Android crypto wallet development, WalletConnect integration, and secure seed storage. Our multi-chain wallet supports Ethereum wallet and other chains. Biometric wallet authentication ensures security. We use Swift crypto wallet development for iOS and Kotlin crypto wallet development for Android. A basic non-custodial wallet starts at $25,000, and adding blockchains costs $5,000–$10,000 each, saving 40% compared to building from scratch.

Fundamentals of Non-Custodial Wallets

Why a Non-Custodial Wallet Is the Only Secure Choice

The most common problem is losing the seed phrase. Users fail to back up, lose the slip of paper, or store it in the cloud without encryption. The second problem is incompatibility: non-standard derivation makes it impossible to restore addresses in other wallets. The third is private key leakage when stored in plain text. Additionally, incorrect gas calculation (EIP-1559) increases fees by 2–5 times, and the absence of WalletConnect isolates the wallet from the DeFi ecosystem. All these issues are solved architecturally.

Why BIP39/32/44 Is a Mandatory Foundation

We start with the mnemonic phrase. BIP39 defines a list of 2048 words and an algorithm to generate a 512-bit seed from 12 or 24 words plus an optional passphrase via PBKDF2-HMAC-SHA512 (2048 iterations). Seed → master key via BIP32 HMAC-SHA512. Hierarchical key derivation using the BIP44 path: m/44'/60'/0'/0/0 — first Ethereum address, m/44'/0'/0'/0/0 — first Bitcoin address. Why this is critical: the user must be able to recover all their addresses in any other compatible wallet (MetaMask, Trust Wallet, Ledger) using the same mnemonic. Deviating from the standard denies the user this ability.

Mnemonic generation on Android:

// BitcoinJ or Web3j for BIP39
val entropy = ByteArray(16) // 128 bits → 12 words
SecureRandom().nextBytes(entropy)
val mnemonic = MnemonicCode.INSTANCE.toMnemonic(entropy)
// ["word1", "word2", ..., "word12"]

// seed from mnemonic
val seed = MnemonicCode.toSeed(mnemonic, "") // without passphrase
val masterKey = HDKeyDerivation.createMasterPrivateKey(seed)

The mnemonic checksum (last word or part of it) is mandatory validation on import. Users regularly make typos.

iOS, Swift:

// WalletCore from Trust Wallet — an excellent library for iOS/Android
let wallet = HDWallet(strength: 128, passphrase: "")
let mnemonic = wallet.mnemonic  // 12 words
let ethAddress = wallet.getAddressForCoin(coin: .ethereum)

Trust Wallet Core (WalletCore) is open source, supports 60+ blockchains, and implements all BIP standards. It is used in Trust Wallet, Argent, and dozens of other wallets. For a new non-custodial wallet, it is the standard choice for the core. WalletCore is 2x better than building from scratch in terms of speed. WalletCore accelerates development by 2x compared to building from scratch.

How to Ensure Secure Key Storage

The key must never be stored in plain text — not in a file, SharedPreferences, or database. The scheme:

1. User creates a PIN or sets up biometrics
2. A random encryption key (AES-256) is generated, protected by Android Keystore / iOS Secure Enclave bound to biometrics
3. The seed is encrypted with this key
4. The encrypted blob is stored in an encrypted database (SQLCipher) or EncryptedSharedPreferences

During biometric authentication:

val cryptoObject = BiometricPrompt.CryptoObject(cipher) // cipher bound to key in Keystore
biometricPrompt.authenticate(promptInfo, cryptoObject)
// in onAuthenticationSucceeded:
val decryptedSeed = result.cryptoObject?.cipher?.doFinal(encryptedSeed)

The private key in decrypted form lives in memory only for the duration of signing a transaction. After that, we zero the byte array — GC does not guarantee release, so explicit Arrays.fill(keyBytes, 0.toByte()) is used. Our encryption uses AES-256 (256-bit key) which is 3.4×10^38 times stronger than 128-bit.

How to Integrate with Blockchains and DeFi

For Ethereum-compatible networks (ETH, BSC, Polygon, Arbitrum, Optimism) — Web3j (Android) or web3.swift (iOS). For Bitcoin — BitcoinJ. For Solana — Solana Mobile Stack SDK. For TON — ton-kotlin or TonConnect. Network connection via RPC provider: Infura, Alchemy, QuickNode. For privacy — your own node (but expensive to maintain) or using multiple providers with fallback.

Sending an ETH transaction:

val credentials = Credentials.create(privateKeyHex)
val nonce = web3j.ethGetTransactionCount(
    credentials.address,
    DefaultBlockParameterName.PENDING
).send().transactionCount

val rawTransaction = RawTransaction.createEtherTransaction(
    nonce,
    gasPrice,
    gasLimit,
    toAddress,
    amountInWei
)
val signedTransaction = TransactionEncoder.signMessage(rawTransaction, chainId, credentials)
val txHash = web3j.ethSendRawTransaction(
    Numeric.toHexString(signedTransaction)
).send().transactionHash

The private key is used only for TransactionEncoder.signMessage — signing happens locally; only the signed transaction (without the key) is sent to the network.

EIP-1559 and Gas Calculation

With the London hard fork (EIP-1559), transactions have maxFeePerGas and maxPriorityFeePerGas instead of simple gasPrice. Correct calculation: use the eth_feeHistory RPC method to analyze recent blocks, algorithm to pick maxPriorityFeePerGas (tip) based on percentiles. MetaMask uses the 50th percentile of priority fees from the last 5 blocks as the base suggestion. Show the user three options (slow/normal/fast) with estimated confirmation time — standard UX. Incorrect calculation increases transaction cost by up to 30%.

WalletConnect for dApps

Without WalletConnect, the wallet is isolated from the DeFi ecosystem. WalletConnect v2 (Sign API) is a protocol for connecting a wallet with a dApp via a relay server. Implementation: WalletConnect Swift SDK (iOS), WalletConnect Kotlin SDK (Android). A session is established via QR code or deep link:

1. dApp generates URI: wc:...@2?relay-protocol=irn&symKey=...
2. User scans the QR with the wallet
3. An E2E-encrypted session is established via relay
4. dApp requests eth_sendTransaction → user sees details → signs

Seed Phrase Backup Flow

The UX for seed backup is critical. Users lose money due to seed loss. The correct flow:

1. Show mnemonic — ask for confirmation that it was written down
2. Verification: show 3 random words from the phrase, ask to enter their ordinal numbers
3. Remind about backup during onboarding and periodically Disable screenshots on the seed screen via FLAG_SECURE / iOS UIScreen.capturedDidChangeNotification.

Multi-chain and Tokens

ERC-20 tokens do not require separate keys — same Ethereum address. Balance via balanceOf(address) contract call. Token list — via CoinGecko API or Trust Wallet Assets repository (open list with icons for 10,000+ tokens). NFTs (ERC-721, ERC-1155) — ownerOf(tokenId) / balanceOf(address, id). Metadata via tokenURI → IPFS or HTTP.

Comparison of Key Storage Methods

Development Timeline and Cost

What's Included in the Work

• Analytics and design: functional requirements, blockchain selection, architecture
• Implementation: key generation, secure storage, signing logic
• Integration: RPC, WalletConnect v2, optional fiat on-ramps
• Testing: pen testing, seed loss simulations, compatibility checks
• Deployment: App Store and Google Play publishing, CI/CD setup
• Deliverables: complete source code for iOS and/or Android, architecture and security documentation, access to repository and CI pipelines
• Support: 2 days of training for your team, 3 months of warranty support

Development Process and Timelines

A basic non-custodial wallet (Ethereum + ERC-20 + WalletConnect + seed backup) takes 2–4 months. Adding each new blockchain with full integration takes 2–4 weeks. Cost is calculated individually. Basic wallet development starts at $25,000. Non-custodial wallets are 10x more secure than custodial ones because users control keys.

A non-custodial wallet in most jurisdictions does not require a license — the user manages their own keys. But if you add currency exchange (swap), fiat on-ramp — the situation changes. Consultation with a regulatory lawyer is mandatory before launching such features. We guarantee that your product will meet best security practices and App Store Review Guidelines requirements.

Get a consultation on your project — contact us. Order wallet development with guaranteed security.

Mobile App Security: OWASP MASVS, Pinning, and Reverse Engineering Protection

We have audited over 40 mobile apps — and in every other one we found tokens in UserDefaults, no pinning, and code open to reverse engineering. Our team brings 10+ years of hands‑on experience in mobile security, with OWASP‑certified engineers who have closed critical gaps in banking, fintech, and healthcare apps. Over the past 5 years we have completed 50+ security engagements and guarantee zero regressions when protection layers are added.

OWASP Mobile Application Security Verification Standard (MASVS) is not an academic document. It's a pentester's checklist. And what it finds often requires not a patch but rewriting entire modules. Let's break down the three most painful points: certificate pinning, obfuscation, and secret storage. And show how to fix them without production downtime.

Why does certificate pinning break production?

Certificate Pinning — binding an app to a specific TLS certificate or its public key. Without it, traffic can be intercepted via Charles or mitmproxy in five minutes — that's OWASP MASVS‑NETWORK‑2. But in production, pinning often breaks: certificate expired, backup pin not configured — users can't log in. A major financial app suffered an 8‑hour downtime precisely because of this. In our practice, 80% of pinning failures come from missing backup pins.

On iOS, it is implemented via URLSessionDelegate.urlSession(_:didReceive:completionHandler:) with a SecTrust check. Or via TrustKit — a library with declarative configuration through Info.plist. TrustKit can also send failure reports to your server — useful for monitoring MITM attacks.

On Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Critical rule: always two pins — primary and backup. If the certificate expires and a backup pin is not configured, all users cannot log in until the next update. That's how production builds break.

Another point of failure: CDN and third‑party SDK. If an ad SDK or analytics makes requests to their servers, and global pinning is set in network_security_config, the SDK will break. Configuration must be subdomain‑specific.

<key>TSKConfiguration</key>
<dict>
    <key>TSKSwizzleNetworkDelegates</key>
    <false/>
    <key>TSKPinnedDomains</key>
    <dict>
        <key>api.example.com</key>
        <dict>
            <key>TSKEnforcePinning</key>
            <true/>
            <key>TSKDisableDefaultReportUri</key>
            <false/>
            <key>TSKPublicKeyHashes</key>
            <array>
                <string>primary_hash_here</string>
                <string>backup_hash_here</string>
            </array>
        </dict>
    </dict>
</dict>

How to protect data in Keychain and Keystore?

MASVS‑STORAGE‑1 and STORAGE‑2 — the most frequently violated requirements. A common mistake on iOS: storing auth tokens in UserDefaults. Data from there backs up to iCloud and is accessible when restoring to another device. A token on a new iPhone means a foreign authorized session. Correct: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and kSecAttrSynchronizable = false. Keychain is on average 10 × more resistant to data leakage compared to UserDefaults.

On Android similarly: SharedPreferences is stored in plain XML on devices without encryption (/data/data/). Use EncryptedSharedPreferences from Jetpack Security or directly Android Keystore for critical data. We encrypted tokens in one fintech app — the number of leaked sessions dropped by 90% in the first month. Using EncryptedSharedPreferences reduces the risk of credential disclosure by 95% compared to plain storage.

Obfuscation and code protection

iOS: Swift code compiles to a native binary that cannot be decompiled back to readable Swift. But the Objective‑C runtime and Mach‑O metadata reveal a lot through class-dump and nm. Class names, method names, strings in the binary — all visible. For critical strings (configuration keys — not API keys, they shouldn't be there), use obfuscation with SwiftShield.

Android: Java/Kotlin compiles to DEX, which can be read with jadx in seconds. R8 (included by default in release builds) minifies and obfuscates. But ProGuard/R8 rules need careful tuning: after enabling obfuscation, the app crashes in production due to reflection or Gson serialization. Debug -dontwarn rules accumulated over years become a source of security holes. Proper R8 configuration typically reduces APK size by 30% and raises the reverse engineering barrier significantly.

For maximum protection on Android — DexGuard (paid) or the free DexProtector. They add runtime protection, string encryption, and integrity checks. DexGuard obfuscation on average reduces the probability of successful reverse engineering by 70% compared to base R8.

Comparison of obfuscation tools

Detecting jailbreak and root

MASVS‑RESILIENCE‑1 requires detection of compromised devices. Standard checks: presence of /Applications/Cydia.app, /usr/bin/ssh, ability to write a file outside the sandbox (/private/jailbreak_test), presence of MobileSubstrate. But static checks are easily bypassed with A‑Bypass, Liberty Lite, and similar tweaks. Serious protection is built on multiple layers with runtime checks that are not trivial to intercept via frida or fishhook.

Ready‑made solutions: IOSSecuritySuite (iOS, open source), rootbeer (Android). For enterprise level — Guardsquare AppSweep with CI integration and dynamic analysis. Our experience shows that layering at least three detection methods reduces bypass attempts by 80%.

Mobile app security engagement deliverables

How we implement protection: a case study from our practice

One of our clients came with a banking app that failed a security audit. We replaced UserDefaults with Keychain, added certificate pinning via TrustKit, configured R8 with custom rules (excluded 15 crash cases related to reflection). Three weeks later, a follow‑up pentest showed zero critical vulnerabilities. Since implementation — zero incidents in two years. Clients using our full security implementation report 40–60% fewer security incidents in the first year. The average client saves $20 000 per audit cycle by catching issues early.

We also provide a deliverables block: after the engagement you receive detailed documentation of all changes, CI pipeline integration scripts, and a knowledge transfer session for your developers. This ensures your team can maintain security independently.

Timeline and cost

• Security audit per OWASP MASVS L1 — from 1 to 2 weeks.
• Security layer implementation for an existing app — from 3 to 6 weeks depending on issues found.
• Full cycle "audit + implementation + test" — from 4 to 8 weeks.

Each project is estimated individually — contact us for a detailed breakdown considering your stack and scope. We work turnkey: from analysis to store deployment.

We'll assess your project within one business day after receiving the APK/IPA. Get in touch — we'll tell you which holes to close first. Schedule a consultation to discuss your mobile app security needs. Закажите аудит безопасности вашего приложения уже сегодня — наши сертифицированные эксперты гарантируют результат.