A crypto app is a normal mobile product with two unusual constraints: it holds things that are irreversibly valuable, and it ships through a reviewer who has opinions about financial products.
Both shape the build rather than the marketing, which is why they belong in the first architecture conversation.
Native where the device matters
The honest test is what you need from the hardware.
Native earns its place when you need secure enclave key storage, biometric signing, NFC, reliable background behaviour, or platform-specific security features. Wallets and anything holding keys qualify immediately, because key handling is exactly where a cross-platform abstraction leaks.
Cross-platform is fine when the product is screens and API calls. A portfolio tracker, a research tool, an account management app — React Native or Flutter will serve these well and halve the build.
Plenty of products are best served by a cross-platform shell with native modules for the sensitive parts. That is more work than either pure approach and usually the right answer for a wallet with a broad feature surface.
Keys never leave the enclave
The rule that governs everything else.
Generate on device with proper entropy. Store in the platform secure enclave — Keychain with Secure Enclave on iOS, Keystore with StrongBox on Android. Sign inside it. The key should never exist as a variable your application code can read.
That constraint rules out a number of convenient patterns: passing a key to a shared JavaScript layer, backing it up to cloud storage, logging anything derived from it. Each of those has caused real losses.
Biometric authentication gates the key rather than the app. Unlocking the app to view a balance and authorising a signature should be different events with different requirements.
Recovery is the product decision
Seed phrases are a security solution with a usability catastrophe attached. Users photograph them, store them in notes apps, and lose them.
The alternatives each trade something:
Social recovery — trusted contacts or devices collectively restore access. Strong, and requires users to nominate guardians before they need them, which many will not do.
MPC with a provider share — convenient, and it means the provider is party to recovery, which has to be disclosed plainly rather than buried.
Hardware backup — most secure, least convenient.
Whichever you choose, design recovery as a first-class flow. It is the moment users are most frightened and most likely to write publicly about the experience.
Review preparation shapes the build
App review rejections in this category are usually about framing rather than function.
Language that reads as a financial promotion. Purchase flows the platform considers a bypass of its billing. Features that imply returns. Anything suggesting the app itself is an investment product.
These are decisions made during the build, not corrections applied at submission. Working through the guidelines early costs a day. Discovering the problem at submission costs a review cycle, and then another if the fix is imperfect.
Privacy manifests, tracking prompts and data-use declarations all need doing properly too. They are tedious and they are a common cause of avoidable delay.
Transaction states are most of the perceived quality
A blockchain transaction is pending for an uncomfortable length of time, and how the app behaves during that window determines whether people trust it.
What good looks like: optimistic UI that clearly marks unconfirmed state, honest progress rather than an indeterminate spinner, a clear explanation when something fails, and never showing a balance that is about to change without saying so.
Users forgive slowness. They do not forgive a number that turns out to be wrong.
Simulate before signing
Before a user approves anything, show them what it will do — which tokens move, which approvals are granted, what the balance looks like afterwards.
This is the highest-value safety feature available in a modern crypto app, because it catches unlimited-approval attacks and drain contracts before the signature rather than explaining them after.
Common questions
Can you publish a crypto app on the App Store?
Yes, within rules that are narrower than most teams expect and that differ between wallets, exchanges and NFT products. The recurring friction is around purchases, token sales and anything the platform reads as a financial promotion. Work through the guidelines before the build rather than at submission, because the constraints shape the product rather than just the copy.
Should a crypto app be native or cross-platform?
Native where you need the device deeply - secure enclave key storage, biometric signing, NFC, background behaviour. Cross-platform where the product is mostly screens and API calls. Wallets and anything holding keys usually justify native, because key handling is exactly where platform-specific security features matter and where a cross-platform abstraction is most likely to leak.
How do you store crypto keys on a phone?
In the platform secure enclave, generated on device, never held in application memory longer than a signing operation requires and never written to ordinary storage or backed up to a cloud. Biometric authentication gates access to the key rather than to the app. What the app should never do is treat a key like a string it can pass around.
Why do crypto apps get rejected from app review?
Usually for how something is described rather than what it does. Language the platform reads as a financial promotion, purchase flows that bypass platform billing, and features that promise returns are the recurring causes. Framing choices made during the build prevent most rejections; framing fixed at submission costs you a review cycle each time.
Does Corum8 build crypto mobile apps?
Yes - native iOS and Android, cross-platform where it fits, with secure key storage, biometric and passkey authentication, wallet connection flows and the review preparation that goes with a financial product. We have built mobile products since 2016 with 95+ specialists.
