One person. Three platforms.

How ByteGuard ships iOS, iPadOS, and macOS as a single-developer product — what's in the stack, why, and what trade-offs were made.

The challenge

Building a cross-platform password manager solo

• Three platforms (iOS · iPadOS · macOS) must share one vault encryption format and stay binary-identical on crypto.
• Zero-knowledge architecture means the server can't help — every feature must work offline.
• 35 languages of UI must stay in sync; every new screen ships with all 35 translations before release.
• One developer means every layer (UI · crypto · sync · build · App Store · support · marketing) is one person's responsibility.
• The goal is not to maximize features. It's to keep the surface small enough that one person can defend it.

The stack

Every dependency is a future maintenance bill paid by one person. The stack is intentionally minimal — only what's needed, only Apple-supported, no third-party UI / network / analytics SDKs.

• SwiftUI: 100% of UI. No UIKit shims. Same view code runs on iOS, iPadOS, macOS with platform-specific modifiers. Trade-off: lose some fine control, gain unified codebase.
• CryptoKit: Apple's official crypto framework for AES-256-GCM, HKDF-SHA256, ECDSA P-256. No third-party crypto libraries — fewer audit surfaces, no supply chain risk.
• CloudKit Private Database: Optional E2E-encrypted sync. ByteGuard ciphertext goes in; Apple infrastructure never sees plaintext. No custom sync server to operate, secure, scale.
• Argon2id (libsodium): Memory-hard KDF for master password → KEK derivation. Parameters: 64 MB memory · 3 iterations · 1 thread (matches OWASP 2026 mobile baseline). Will be open-sourced Q3 2026.
• SQLCipher: SQLite with built-in AES-256 page-level encryption. Database is encrypted at rest on disk; encryption is transparent to query layer. Battle-tested since 2008.
• Swift 6: Strict concurrency mode on. Compile-time data race elimination matters when crypto operations touch shared state. No Objective-C bridging unless absolutely required.

Design principles

Four hard rules that shape every architectural decision.

• Local-first, optional sync: Every operation works without network. iCloud sync is opt-in and only ever moves ciphertext. App is 100% functional in airplane mode.
• Zero-knowledge by construction: I cannot decrypt your vault even if compelled by law or compromised by attacker. KDF runs on device, server only sees ciphertext.
• Minimum subprocessors (currently 2): Only Apple (sync + StoreKit) and Have I Been Pwned (optional breach check, k-anonymized). No analytics, no error reporting, no marketing automation.
• Dependency conservatism: Every npm/SPM dependency added must clear a bar: is it Apple-native? Is it widely audited? Can I maintain a fork if upstream abandons? Most third-party libraries fail one or more checks.

Build log

Public milestones from launch to today. Future milestones have committed dates in the Continuity Plan.

• Q1 2026 — Launch: v1.0 to App Store. 1 language (English). Core password / passkey / TOTP / cards / notes. Argon2id + AES-256-GCM crypto pipeline.
• Q2 2026 — 35 languages: Full localization including RTL (Arabic, Hebrew). Marketing screenshots per language × light/dark mode. HIBP integration.
• Q2 2026 — Continuity Plan published: Five concrete promises that protect users even if I disappear. Public dead-man's switch design (active by Jun 30, 2026).
• Q3 2026 (committed) — Crypto module open source: MIT-licensed Swift package containing the KDF + cipher + key hierarchy code. Repository: byteguard-crypto-swift. Independent audit invited.
• Q4 2026 (committed) — Independent third-party audit: Engagement with a recognized application security firm. Full report published in Transparency Center, regardless of findings.

Single-developer trade-offs

What you give up when you bet on a single-developer product — stated explicitly, not hidden.

• No 24/7 support hotline. Email response is best-effort within 72 hours. For most password manager questions, the documentation is faster than I am.
• Slower feature pace than 1Password or Bitwarden (which have engineering teams of 50-200). I ship deliberately small, after testing across all 3 platforms.
• Narrow scope by design. No browser extension (yet), no Windows / Linux / Android port, no enterprise admin features. Apple ecosystem only.
• No guarantee of compatibility with future iOS versions a decade out. I'll do my best, but Apple changes things, and a single developer can't promise indefinite support — see Continuity Plan for the safety net.
• Bus factor of one. This is real. Read the Continuity Plan to see exactly how I've automated answers for what happens if I disappear.

Scaling without diluting

How ByteGuard grows past the single-developer phase without compromising the security posture.

• Phase 1 (current) — solo: One developer, narrow scope, conservative roadmap. Goal: prove the architecture and reach sustainable revenue without venture capital.
• Phase 2 — open source crypto + audit (Q3-Q4 2026): Publishing the crypto core invites public review. The audit catches what I missed. Both happen before I add any team member who could weaken the threat model.
• Phase 3 — selective contractor help: Once revenue is stable, engage specialists (penetration tester · localization reviewer · CI/CD) on per-project basis. Never full-time, never with vault-key access.
• Phase 4 — escrow + redundancy (MRR ≥ $5K/mo): Software escrow service (Iron Mountain / NCC Group) holds signing keys + build artifacts. Adds redundancy without changing the zero-knowledge guarantee.
• What's NOT in the plan: No venture capital. No exit-to-acquirer. No expansion into adjacent products. The scope stays narrow because that's what makes the security promise credible.

Questions about the architecture?

If you find a gap, a bug, or a better trade-off, please share it.

• Email: [email protected] — security disclosures get priority response within 24h.
• See also: Transparency Center (subprocessors, incidents, roadmap) · Security page (cryptographic details) · Continuity Plan (5 promises).