Developing a Mobile App for Document Storage (Digital Wallet)
A passport in your phone sounds simple until you encounter a user on iOS 15 with a device lacking Face ID, needing to present the document offline with cryptographic authenticity confirmation. This is where a standard "pretty UI file manager" becomes a failed product, while a properly architected Digital Wallet becomes a separate engineering project.
The Core Engineering Challenge: Storage and Key Management
Most first versions of such applications make the same mistake: store PDF in Documents/ and encrypt with AES-256. This is catastrophically insufficient. The problem isn't the encryption algorithm—it's key management.
If the key is stored alongside the data (even wrapped in SecKeyCreateRandomKey), it can be recovered during jailbreak or with physical device access. The correct scheme: generate the master key in Secure Enclave on iOS (kSecAttrTokenIDSecureEnclave), where it never leaves the chip. On Android, the equivalent is Android Keystore with StrongBox on devices with dedicated HSM (Pixel 3+, Samsung with Knox). Documents are encrypted with a derived key through HKDF; the derived key is encrypted with the master key. Without biometrics or PIN, the key is inaccessible.
The second pain point is backups. By default, Documents/ on iOS is included in iCloud Backup. User documents leak to the cloud without developer awareness. The fix: set isExcludedFromBackup = true for the storage directory and explicitly apply the NSURLIsExcludedFromBackupKey attribute.
Document Authenticity Verification on Import
Storage is half the battle. Users expect the app to at least perform basic verification when loading: is the PDF corrupted, does the MRZ in the passport match the visual content, is the document expired.
For MRZ parsing, use the Vision framework on iOS (VNRecognizeTextRequest) or ML Kit Document Scanner on Android. OCR of the MRZ zone achieves >98% accuracy on quality photos. For PDF — PDFKit on iOS, PdfRenderer on Android: verify the document's digital signature (PDFDocument.accessPermissions, X.509 chain in embedded CMS).
A full eIDAS/PAdES verification chain is a separate topic, but basic checks can be implemented in 3-4 days.
Storage Structure
WalletVault/
├── index.encrypted # CBOR manifest of all documents (ID, type, date, thumbnail hash)
├── docs/
│ ├── {uuid}.enc # Encrypted document (AES-GCM, 256-bit)
│ └── {uuid}.meta.enc # Metadata (name, tags, expiration)
└── keys/
└── vault.key.ref # Reference to key in Keychain/Keystore (not the key itself)
The manifest index allows displaying the document list without decrypting the files themselves—thumbnails are stored separately, scaled down to 64×64 px.
Offline Presentation and Third-Party Verification
The scenario of "show the document to an inspector" requires more than displaying an image. For critical use cases (driver's license, corporate badge), implement ISO 18013-5 (mDL — mobile Driving Licence) over BLE/NFC: a verifier requests specific fields (only name and date of birth, no address), the device responds with a signed CBOR object. The user sees which fields are disclosed—selective disclosure in action.
For less critical scenarios, a QR with signed JWT + short TTL (60 seconds) is sufficient.
Project Stages
Requirements audit for document types and presentation scenarios → storage and key management design → Vault module development → OCR/MRZ verification integration → document management UI → security review → publication.
One platform with basic storage: from 5 weeks. Two platforms with MRZ, offline ISO 18013-5 verification, and MDM integration: 3–5 months. Cost is calculated individually after requirements analysis.