NordLocker — Encrypted Cloud Storage

Problem

NordLocker's promise to users was zero-knowledge storage — the company itself should never be able to read a user's files. That promise had to hold up not just in marketing copy but in the actual client implementation, while still delivering the sync reliability and subscription experience users expect from a mainstream cloud product.

Approach

I built the iOS encryption layer using CryptoKit to encrypt files with AES-256 before they ever left the device, with keys derived and managed client-side. On top of that, I built sync and conflict-resolution logic that could operate correctly on encrypted blobs without the server ever needing plaintext, and a StoreKit 2 subscription system covering trials, entitlements, and family sharing.

Architecture

The client is layered into an encryption module (key derivation, AES-256 file encryption via CryptoKit), a sync engine that tracks file state and resolves conflicts using encrypted metadata, and a StoreKit 2 entitlement layer that gates features locally with a design biased toward availability — a lapsed receipt check fails toward access, not lockout, until it can be safely reconciled.

Technical Decisions

Challenges

• Implementing correct, auditable client-side AES-256 encryption for a security-critical consumer product.
• Resolving sync conflicts on encrypted data without server-side visibility into file contents.
• Handling StoreKit 2 edge cases — trials, family sharing, refunds — without support tickets becoming the safety net.

Results

• Shipped the iOS encryption layer underpinning NordLocker's zero-knowledge storage guarantee.
• Reduced subscription-related support tickets by hardening entitlement handling around trials and family sharing.

Lessons learned

• Security-critical code deserves a different review bar — more eyes, more tests, more paranoia about edge cases than typical feature work.
• Trust-based products live or die on how gracefully they handle failure states, not just the happy path.