Mobile App Development for Crypto Lending
We frequently get requests to build mobile products for crypto lending. This is a complex technical task: the app must display collateral positions in real time, calculate the Health Factor, send liquidation risk notifications, and interact with DeFi protocols. An error in calculations or data delay can cost the user money. With over 5 years of experience in DeFi mobile development, we have completed 15+ projects for lending platforms, ensuring compliance and robust security.
Rigorous Development in Crypto Lending
How Is Health Factor Calculated and Liquidation Handled?
Health Factor = (Collateral × Liquidation Threshold) / Borrowed Amount. If HF falls below 1, the position is liquidated. This must be displayed to the user in real time with a visual indicator — not just a number, but a scale with zones: safe (green, HF > 1.5), risk (yellow, 1.1–1.5), critical (red, < 1.1).
The price of a collateral asset changes every few seconds. So HF must be recalculated on the client with every price update — via Chainlink Price Feeds or CEX WebSocket. It's important not to burden the server with polling every 2 seconds from thousands of clients; it's wise to subscribe to Binance WebSocket (wss://stream.binance.com:9443/ws/ethusdt@ticker) and calculate HF locally.
// Health Factor calculation on client struct LendingPosition { let collateralUSD: Decimal // collateral value in USD let liquidationThreshold: Decimal // e.g., 0.82 for ETH let borrowedUSD: Decimal // borrowed amount in USD var healthFactor: Decimal { guard borrowedUSD > 0 else { return Decimal.greatestFiniteMagnitude } return (collateralUSD * liquidationThreshold) / borrowedUSD } var riskLevel: RiskLevel { switch healthFactor { case ..<1.1: return .critical case 1.1..<1.5: return .warning default: return .safe } } } Push notification at HF < 1.2 is mandatory. Without it, the user won't learn about liquidation. We implement this via a server worker that monitors positions through smart contract events (LiquidationCall event in the protocol's ABI) or through a protocol API (if Aave, Compound), and sends push via FCM/APNs when thresholds are reached. These event structures are documented in Aave V3 developer docs.
Connecting to a DeFi Protocol
If building on top of an existing DeFi protocol — Aave V3, Compound V3, Morpho — we use their SDKs: Aave V3 (packages @aave/contract-helpers and @aave/math-utils via JavaScript bridge or backend), Compound (compound-js or direct calls via web3j / web3.swift).
For native iOS/Android apps without React Native, it's more convenient to keep all Web3 logic on the backend and expose it via REST API: the client doesn't know about ABI, it simply makes POST /positions/deposit or GET /positions/{id}.
| Protocol | SDK/Tools | Features |
|---|---|---|
| Aave V3 | @aave/contract-helpers + math-utils | L2 optimization, portals, eMode |
| Compound V3 | compound-js, web3j | Customizable pools, base rate |
| Morpho | own library | Peer-to-peer matching, low fees |
Morpho's peer-to-peer matching can achieve up to 30% better interest rates for lenders compared to Compound V3.
// Android: position display via Jetpack Compose @Composable fun PositionCard(position: LendingPosition, currentPrice: BigDecimal) { val updatedPosition = position.copy( collateralUSD = position.collateralAmount * currentPrice ) Card( colors = CardDefaults.cardColors( containerColor = when (updatedPosition.riskLevel) { RiskLevel.CRITICAL -> MaterialTheme.colorScheme.errorContainer RiskLevel.WARNING -> Color(0xFFFFF3E0) RiskLevel.SAFE -> MaterialTheme.colorScheme.surfaceVariant } ) ) { Column(modifier = Modifier.padding(16.dp)) { Text("Collateral: ${updatedPosition.collateralUSD.formatUSD()}") Text("Debt: ${updatedPosition.borrowedUSD.formatUSD()}") HealthFactorBar(hf = updatedPosition.healthFactor) } } } Interest Rates and APY Calculation
Rates in DeFi protocols are dynamic — they change based on the pool's utilization rate. They need to be updated in the UI every few minutes. For custodial platforms (Nexo, BlockFi-like), rates are set administratively and change less frequently.
APY vs APR — we show both. Users get confused: APR 8% ≠ APY 8%. APY with compounding is higher. Formula: APY = (1 + APR/n)^n - 1, where n is the number of compounding periods per year. Formula derived from standard compound interest calculations used in DeFi. We guarantee calculation accuracy with verification on testnet.
Transactions and Gas
When interacting with EVM smart contracts, every action is an on-chain transaction. Deposit, borrow, repay, withdraw — each costs gas. Before sending, we show the user a gas estimate via eth_estimateGas and the current price from eth_gasPrice or EIP-1559 eth_maxFeePerGas. Using L2 networks like Arbitrum reduces gas fees up to 5 times compared to Ethereum mainnet, which can save an active user hundreds of dollars per month — in some cases up to $300–$500 monthly. For example, a user with $50,000 in collateral can save up to $600 annually on Ethereum mainnet by using L2s.
Verification and Compliance
KYC via SumSub or Veriff for regulated platforms. Jurisdictional restrictions — users from the US cannot use most DeFi platforms without SEC registration. IP geofiltering on the server, additionally check at registration. We provide support for setting up the compliance module.
What's Included in the Work
- API and architecture documentation
- Source codes of iOS/Android applications
- CI/CD setup and deployment to app stores
- Access to backend admin panel and monitoring
- Client team training (2 sessions)
Timelines and Cost
View detailed timeline and cost
| Stage | Duration |
|---|---|
| Architecture: DeFi protocol or custodial scheme | 3–5 days |
| Smart contracts or protocol integration | 1–3 weeks |
| Server part (positions, prices, notifications) | 2 weeks |
| Mobile client iOS + Android | 3–4 weeks |
| Testing on testnet | 1 week |
Total: 8–12 weeks. The cost for a basic integration starts at $85,000 and can reach $150,000 for multi-chain support.
Step-by-Step Development Process
- Analysis and protocol selection (Aave, Compound, Morpho)
- API and application architecture design
- Development of smart contracts (if needed) or SDK integration
- Creating mobile client for iOS and Android
- Testing on testnet and security audit
- Deployment and monitoring
Typical integration problems — incorrect transaction signing due to WalletConnect incompatibility, outdated ABI after protocol update, delays in data from WebSocket, geofiltering issues on the client side. Our experience allows us to avoid these errors at the design stage. Our backend implementation reduces latency by up to 3 times compared to direct RPC calls.
Contact us to get a consultation on your project. We guarantee security and compliance with App Store Review Guidelines (Section 4.2/5.1) and Google Play Console. Get a consultation — we will help choose the right stack and avoid typical mistakes.







