Why "wrong passcode" was lying to users of my encrypted vault app

Van Thuong Dao — Thu, 08 Oct 2026 06:22:46 +0000

A user wrote in: "I tried to restore my backup and it keeps saying my passcode is wrong. I'm 100% sure it's right." They weren't wrong to be sure. The passcode was fine. My error handling was lying to them.

Lockboxy (the encrypted vault app I build) lets you back up your vault to a file and restore it later — new phone, reinstall, whatever. Restoring needs your passcode (or a recovery key) to decrypt the backup. The restore screen's error handling looked like this, roughly:

try {
  await restoreFromBackup(file, credential);
} catch (e) {
  setError('Incorrect passcode. Please try again.');
}

Simple. Also wrong. That catch block fires for any failure during restore — wrong passcode, sure, but also a corrupted backup file, a backup from an incompatible app version, a truncated file from a failed download, a file that isn't a Lockboxy backup at all. Every single one of those got the same message: blame the passcode.

So someone with a perfectly correct passcode and a backup file that got mangled in transit would sit there, re-typing a passcode they already know is right, told every time that they're wrong. There's no worse debugging experience than an error message confidently pointing at the wrong cause.

The fix wasn't complicated — it just required actually having distinct error types instead of one catch-all:

try {
  await restoreFromBackup(file, credential);
} catch (e) {
  if (e instanceof IncorrectPasscodeError || e instanceof IncorrectRecoveryKeyError) {
    setError(
      usingRecoveryKey
        ? "That recovery key doesn't match this backup."
        : "Incorrect passcode. Please try again."
    );
    return;
  }
  // Anything else — corrupted file, bad format, whatever — is NOT a credential problem.
  setPickError("This backup file couldn't be read. It may be corrupted or from a different app.");
  setFile(null);
}

The actual fix is almost boring: instanceof checks on a proper error hierarchy (CryptoServiceError → IncorrectPasscodeError, IncorrectRecoveryKeyError, and others) that already existed in the crypto layer. The bug wasn't a missing feature, it was a UI layer that caught everything and collapsed it into one message because that was the easy path.

Here's the part that makes this more than a generic "handle your errors properly" lesson: Lockboxy is zero-knowledge. I don't hold your passcode, I can't reset it, and if you truly forget it, your data is gone — that's the whole point of the security model. Which means when a user sees a credential error, the ONLY two things that can possibly be true are "I mistyped it" or "I forgot it." There's no third option, no "contact support to reset it," nothing. The support cost of a misleading error message is much higher here than in an app where someone can just click "forgot password." If my error message blames the passcode and it's actually the file, the user has no way to find that out themselves — they'll assume their data is unrecoverable and give up, when the actual fix might be as simple as re-downloading the backup file.

Lesson, stated plainly: if your app can't offer a human a way around a problem, your error message is the only diagnostic tool they have. It has to be right, not just plausible.

Apple rejected my TestFlight upload — because of a version I'd already shipped

Van Thuong Dao — Thu, 08 Oct 2026 05:08:18 +0000

I spent half an hour yesterday convinced something was broken on my end. It wasn't. Apple just doesn't tell you this rule anywhere obvious.

Here's what happened:

I'd fixed two real bugs in my app (Lockboxy, an encrypted vault for Mac/iOS) — one was a confusing error message, the other added zip preview support. Normal patch release. Same version number as my last TestFlight build (1.2.15), since nothing user-facing about the version had changed — just a new build number.

xcodebuild -exportArchive failed with:

error: exportArchive
code 90186: Invalid Pre-Release Train. The train version
'1.2.15' is closed for new build submissions.

error: exportArchive
code 90062: ... must contain a higher version than
that of the previously approved version.

Both errors, same root cause: 1.2.15 had already been approved and released live on the App Store. Once a version number ships, Apple closes its "pre-release train" — permanently. Doesn't matter that I only wanted it for TestFlight. Doesn't matter that no one outside my test group would ever see it. The version number itself is burned the moment it goes live.

The fix is simple once you know it: bump to a new version number (1.2.16), even for an internal TestFlight-only build. But here's the part that actually cost me time — the version number is baked into the binary at archive time, not export time. I bumped MARKETING_VERSION in the Xcode project, re-ran -exportArchive against my existing archive, and it exported fine with no error — but silently still reported the old version inside the binary. I had to throw away the archive and run xcodebuild archive again from scratch before export would actually reflect the new version.

So the real sequence, if you hit this:

Bump your marketing version (and build number, while you're at it) in Xcode.
Re-archive from scratch. Don't reuse an old .xcarchive — MARKETING_VERSION is burned in at archive time.
Then export/upload as normal.

One side effect worth knowing if your app shows release notes in-app ("What's New"): if your code asserts the current app version matches the latest entry in your changelog data (mine does, as a test), bumping the version means you need a new changelog entry too — which, if you support multiple locales like I do (10 languages), means translating "What's New" into all of them before you can ship. Small cascade, easy to forget.

Nothing about this is documented clearly in one place — it's scattered across old Apple Developer Forums threads and Stack Overflow answers from 2019. If you're staring at code 90186 or 90062 right now: it's not your signing, not your provisioning profile, not your export options plist. It's just the version number. Bump it, re-archive, move on.

DEV Community: Van Thuong Dao

Why "wrong passcode" was lying to users of my encrypted vault app

Apple rejected my TestFlight upload — because of a version I'd already shipped