Autheris

Recent Commits

• Hunter Eddington(02 Oct 26)

  Revise security issue reporting instructions Updated contact information for reporting security issues to use GitHub's vulnerability report form and clarified the process.

• Hunter Eddington(02 Oct 26)

  Add contact section for vulnerability reporting Added contact information for reporting security vulnerabilities, including details on what to include in the report.

• Hunter Eddington(02 Oct 26)

  2.7 - New Screenshots

• Hunter Eddington(30 Sept 26)

  Split the README: an app-facing front page, and the engineering in docs/ The README had grown to 717 lines, roughly 560 of them internals — the CloudKit schema, the localisation tooling, the release runbooks — sitting immediately behind a thirty-line landing page. Someone arriving from the App Store listing met CloudKit field types before they met what the app does. The front page is now 129 lines and answers two questions: what Autheris is, and how it keeps your codes safe. Security is rewritten in those terms rather than in its implementation — where the tokens live, what iCloud Sync sends, what the privacy screen covers, and the one request the app can make — with the mechanics one link away. The features list, screenshots, installation and download are unchanged. Nothing was rewritten or dropped in the move. The engineering sections were relocated verbatim into `docs/`, re-levelled one heading deeper so the hierarchy still reads, and every internal cross-reference was rewritten to its new home: a check across all 57 headings in the six files reports no broken references.

• Hunter Eddington(30 Sept 26)

  Untrack the local tooling, and drop the assistant framing from the README Assistant configuration had been committed: 79 files of skills, agent definitions, IDE glue, and — the worst of it — session transcripts under `.reasonix/tasks/`, whose directory names carry the model that produced them. None of it is part of Autheris, and a clone was receiving one developer's setup with it. Untracked and ignored rather than deleted: the files stay in the working copy, so the tooling that reads them carries on working, and `git rm --cached` leaves that reversible. Also ignored are `Vaultic/CLAUDE.md` and `Vaultic/.mcp.json`, which stay on disk and stay excluded from the app target's membership — a synchronized folder copies every non-Swift file into the bundle, so that exclusion is what keeps them out of the shipped app, and it is why their names survive in `project.pbxproj` and in the bundle test that guards it. The README keeps the lesson from that corner — the scaffold whose `.dev.vars` shipped for several releases, and the three ways the exclusion list can be undone — without narrating whose guide said what.

• Hunter Eddington(30 Sept 26)

  Ship 2.6: counter-based codes, done properly The listing has claimed HOTP support since 2.4. It was not true. `OTPAuthURLParser` never read the URL's *host*, so an `otpauth://hotp/` QR code was saved as a time-based token whose codes the service always rejected — silently, with nothing on screen to explain it — and both importers skipped HOTP entries outright. Reading the host is the whole fix; the rest of this release is what falls out of making the claim true. - `OTPKind` and `OTPCode.counter`, threaded through generation, sync (two new plain CloudKit fields, fingerprint `v3`), backups, QR export, imports, and the watch payload (`version 2`: a v1 watch must refuse a payload it cannot honour rather than render a counter-based token as a time-based one). - The card shows the counter where the countdown would be, with a **Next** button beside it. Advancing is explicit and never a side effect of copying, because a copy is not proof the service accepted the code and a spent counter takes away a code the user may still need to retype. - Three copies of the URL parsing became one. The duplicates had already drifted, and that drift is precisely what made the claim false. Also in this release: - A setup *link* can be pasted into the manual form, which used to reject one as "please enter a valid Base32 secret key" — a URL is not Base32, and on a Mac a link is often the only thing there is to copy. - The import-failure messages are translated. They were bare literals, a shape neither the extractor nor the localization coverage test can see. - `Vaultic/PrivacyInfo.xcprivacy`, the manifest the app never shipped, and the issuer-logo lookup is now a switch in Settings → Privacy. The README states plainly what that one network request discloses — the *codes* never leave the device, the list of services does unless it is turned off. - 43 new tests. The URL parser, both importers and the generator's HOTP/RFC 4226 vectors now pin the cases that used to fail quietly. And the repository's front page: the screenshots it has carried since 2.2 but never shown, iPhone and iPad ones produced from the real app, a collapsible table of contents for a 700-line README, and the `LICENSE` file the README has linked to since it was written.

• Hunter Eddington(29 Sept 26)

  Document the iOS release path, and the four steps in it that fail quietly Releasing 2.5 meant rebuilding the iOS release path from scratch, because only the Mac one was written down. The archive, the export and the upload are all ordinary, but four of the steps mislead when they go wrong, and each cost real time to work out: - `asc release stage --metadata-dir` wants the metadata *root*; it resolves `version/<version>/` itself. Given a version directory it fails in `apply_metadata` — after `ensure_version` has already created the version — and leaves a checkpoint whose `metadataDir` matches nothing, so every later run stops on "checkpoint does not match current run arguments" instead. - A freshly uploaded build is refused a review submission until its export answer is set (`usesNonExemptEncryption`). It is a compliance position, not a build detail, so it belongs read from the previous build rather than answered fresh. - `asc xcode version view` cannot read this project at all: it reports an empty version with `modern: false`, because `MARKETING_VERSION` is per build configuration. The six settings get edited directly, and the built app is what confirms them. - `asc metadata push` has to be previewed. A release that only adds What's New should plan adds and nothing else; a `changes` or `deletes` entry means the local listing has drifted from the live one, and it is the only place that shows up before it is applied. `ExportOptions-iOS.plist` is new because the `ExportOptions.plist` already in the repository is the Mac one — same method, but it exports a `.pkg`, since which artifact comes out is decided by the archive's platform. Both files now say so.

• Hunter Eddington(29 Sept 26)

  Ship 2.5: the app now speaks the six languages the listing already did 2.4 translated the app's strings but shipped no release of its own; 2.5 is that release. Nothing about the product changed — same codes, same sync, same settings — except that the app, the watch and the privacy prompts now answer in Spanish, French, German, Japanese, Simplified Chinese and Brazilian Portuguese, which is what the App Store listing has offered since 2.4. `MARKETING_VERSION` moves to 2.5 and `CURRENT_PROJECT_VERSION` to 20 in all six build settings, the changelog gains its entry in both places that hold one (the in-app `ChangelogRelease.catalog` and `CHANGELOG.md`), and `metadata/version/2.5/` carries the seven locales. `ChangelogReleaseTests` is what ties the first two together, and it is the reason this could not be half-done: bumping the version without its notes fails the build. The locale files are 2.4's with `whatsNew` and `promotionalText` replaced. Description, keywords and the URLs are carried over byte-for-byte, because the app's feature set did not change and rewriting a listing around a localization would be inventing copy. `asc metadata validate` reports 25 files and no issues, and the push planned exactly 14 adds — seven `whatsNew`, seven `promotionalText` — against zero changes and zero deletes, which is what a release that only says new things should look like. Three things about the mechanics, since they are the kind that cost an afternoon the next time round: - `asc xcode version view` cannot read this project: it reports an empty version and `modern: false`, because `MARKETING_VERSION` lives per configuration rather than at the project level. The six settings were edited directly, and the built app confirmed at 2.5 (20) before anything was uploaded. - `asc release stage --metadata-dir` wants the metadata *root*, not a version directory — it resolves `version/<version>/` itself. Passing `./metadata/version/2.5` fails in `apply_metadata` with `flag: help requested` *after* it has already created the version, and leaves behind a checkpoint whose `metadataDir` matches no working command, so the next run stops on "checkpoint does not match current run arguments" until it is deleted. - A freshly uploaded build is refused a review submission until its export answer is set: `asc builds update --build <id> --uses-non-exempt-encryption false`, matching every build this app has uploaded. 2.5 is WAITING_FOR_REVIEW. A featuring nomination for it is filed with Apple.

• Hunter Eddington(29 Sept 26)

  Finish the localization: the Info.plist prompts, the watch, and what `translated` means The 2.4 commit localized the app's own strings into the six languages the store listing already speaks, and left two of them behind. Both are finished here. **The privacy prompts were not merely untranslated — they reached nothing.** `Vaultic/InfoPlist.xcstrings` was there, English only, every entry at `new`. But the camera and Face ID copy does not live in `Localizable`: the system reads it out of `InfoPlist.strings`, a table of its own, and a catalog with nothing compiled produces no table at all. A build with that file in the target has no `InfoPlist.strings` in it, so the two prompts a first-time user actually meets were English in all six languages while the other 267 entries were translated. They are translated now, and the suite reads them back out of the built app under `table: "InfoPlist"` — because "the catalog has it" and "the bundle has it" are different claims, and only the second one ships. **The watch speaks them too.** Its strings were English, and the README called that a deliberate stopping point. It is not one any more: `VaulticWatch/Localizable.xcstrings` carries its five strings in the same six languages, and `VaulticWatch/InfoPlist.xcstrings` carries the name with `shouldTranslate` off. The watch is still read-only and still shows the codes the phone sent it; this changes the words around them and nothing else. **Every entry in all four catalogs now says `translated`, not `needs_review`, and that is a narrower claim than it reads.** The wording is machine translation that no native speaker has reviewed. `needs_review` was the one-click answer to "what does a human still have to read", so the honest end state is the one replaced by the other, and what the README says about it has been rewritten to match: the flag now means the strings are settled for a release, not that they were read. What the tests are worth is unchanged — the shape, not the wording. **Three ways the sync pipeline misleads, all silent, all now written down.** - An iOS build of the `Vaultic` scheme builds the watch app and embeds it, so the watch's `.stringsdata` lands under `Vaultic.build` as well. The single `find '*Vaultic.build*'` the README recommended therefore swept the watch's five strings into the *phone's* catalog, where no phone view asks for them. Excluding `*VaulticWatch.build*` leaves each target to its own file. - `xcstringstool sync` deletes entries no source yields, and this catalog holds one on purpose: `Autheris`, the product name, with `shouldTranslate` off. A sync without `--skip-marking-strings-stale` drops it, and `testTheProductNameIsNotTranslated` fails. With the flag, syncing is additive and idempotent — which is what the README already claimed it was. - Sync is never pointed at the `InfoPlist` catalogs. No Swift file says `NSCameraUsageDescription`, so there is nothing to merge, and the keys are simply stripped. `LocalizationCoverageTests` grows from one catalog to four, and adds the two guards the old suite could not make: that an entry marked `shouldTranslate: false` carries no translations to contradict it, and that the watch's strings reach the watch's own bundle when the host build embedded one — the iOS run does, and the Mac run has no `Watch/` directory to find. The source scan now reads both targets against their own catalogs. None of it needed a source change: a literal ternary written directly inside `Text` takes the parameter's `LocalizedStringKey` type on this toolchain, which is how all five of the watch's strings are written. I checked that with a throwaway AST dump rather than assuming it, because the README lists literal ternaries among the shapes that quietly opt out — which is true of a ternary bound to a `String` first, and not of one written in the argument. No version bump. 2.5's changelog and store metadata belong with a release, and the translations still want a native speaker's eyes first.

• Hunter Eddington(29 Sept 26)

  Localize the app into the six languages the listing already speaks The App Store listing has been translated into Spanish, French, German, Japanese, Simplified Chinese and Brazilian Portuguese since 2.4. The app itself was English everywhere, so six of those languages opened to an English app. It now speaks them: one String Catalog, `Vaultic/Localizable.xcstrings`, 267 entries, seven languages. Every entry is marked `needs_review` rather than `translated`, which is the honest state of it — the wording exists and the app uses it, but no native speaker has read it. The String Catalog editor filters on exactly that, so what is left to do is one click away. There is deliberately no version bump: 2.5's changelog and store metadata belong with a release, and that should wait until the translations have been read. **The extraction pipeline, and the step that fails silently.** Xcode's extractor reads the sources during a build (`SWIFT_EMIT_LOC_STRINGS` was already on) and emits a `.stringsdata` per file; `xcstringstool sync` merges those into the catalog, and re-running it is idempotent, so it never disturbs existing translations. The catch is that **one platform's build only extracts the branches that platform compiles**. Building for iOS alone quietly omitted the whole Mac preferences window, the camera-permission copy, and five Settings rows — they ship in English while the catalog looks complete. Syncing the union of an iOS and a macOS build is what found them, and the README now says so. **A `String` property is a localization bug**, and this was the shape of almost everything that had to be fixed, because it leaves no trace: `Text("Cancel")` takes a `LocalizedStringKey` and is looked up, `Text(someString)` renders what it is handed, and the extractor agrees with both. So a literal that passes through a `String` — a property, a parameter, a tuple, a ternary of two literals — never reaches the catalog, and nothing looks wrong. Fixed: - `String` properties shown by `Text`: `OnboardingFeature.title`/`.description`, `QRCodeView.title`, `SecretKeySection.title`, `AccentTheme.displayName` - `String` parameters shown by `Text`/`Label`: `actionRowLabel(_:systemImage:)`, `WelcomeView.highlight(_:)`, `ImportConfirmationView.statRow(label:value:)` - `String` tuples behind the alerts in `AutherisApp`, `AddTokenView`, `SettingsView` and `RecentlyDeletedView`, now built with `String(localized:)` - every `alertMessage`, `restoreErrorMessage`, `generationError`, `supportErrorMessage` and `failureView(message:)` literal, likewise - three ternaries of two literals (`"Next" : "Get Started"`, the ring-colour caption, the reveal-setup-key label), each now a typed `LocalizedStringKey` - the scanner's UIKit overlay and its permission prompts, where `label.text` and `UIButton.title` take a `String` and so needed `String(localized:)` too **Plurals.** Nine strings pluralised themselves with `count == 1 ? "" : "s"`, which is correct in exactly one language. They are catalog entries with plural variations now, so the rule comes from the language: `%lld Code`/`%lld Codes`, `Supprimer %lld code`/`Supprimer %lld codes`, and a single form for Japanese and Simplified Chinese, which have no `one` category at all. English keeps the behaviour it had, grammatical awkwardness at a count of one included, rather than changing shipped copy as a side effect of translating it. Two strings that were never translatable stop pretending to be: the changelog's list numbering and the Recently Deleted count badge are `Text(verbatim:)` now, so the catalog does not carry a bare `"%lld"` key, and the accent swatch's "A" is a glyph rather than a word. Deliberately left in English, and listed in the README so the next person does not think it was missed: the in-app changelog history (long-form prose mirroring copy for versions that have shipped), the support-mail draft (support answers in English, and a half-translated bug report is worse than a clear one), `debugInfo` in `ImportConfirmationView` (assigned only under `#if DEBUG`), the watch app, and the product name, which carries `"shouldTranslate": false`. `VaulticTests/LocalizationCoverageTests.swift` guards the shape rather than the wording, which is all a test can do here: every entry has all six languages, none is left at `new`, every plural entry declares the categories its language actually has, and every translation keeps exactly the placeholders its key has. That last one earned its place immediately — it caught a singular form that had dropped its `%lld`, which would have hidden the count. Two of the tests reach outside the app on purpose: one scans the Swift sources, so a literal the extractor never saw fails here instead of shipping as English, and the other compares the built `Autheris.app`'s compiled strings against the catalog, because a catalog full of translations proves nothing if the build does not put them in the bundle. Verified: 184 tests on an iOS Simulator destination, 0 failures; the app and the watch app build for iOS and macOS; and the app launched under `-AppleLanguages "(ja)"` shows `コードを検索`, `編集`, and a countdown reading `59秒` — the `%llds` key, resolving.

• Hunter Eddington(29 Sept 26)

  Ship 2.4: an Apple Watch app, App Store metadata as JSON, the backend scaffold removed **An Apple Watch app.** A second target, `VaulticWatch`, embedded in the iPhone app at `Autheris.app/Watch/Autheris.app`. It is a viewer and nothing else — no add, edit, delete, search, settings or copy. Installing it is the opt-in: the phone only sends to a watch it reports as paired *with the app installed* (`WCSession.isPaired && isWatchAppInstalled`), so a user who has not chosen to put Autheris on their wrist never has a secret leave the phone. Codes travel over `WatchConnectivity` rather than iCloud, so the watch works for everyone rather than only for the users who turned iCloud Sync on. The relay uses `updateApplicationContext` — the one transport that describes *state* rather than events — with a file fallback for a list past the context's size cap, and the same `sentAt` stamp on both transports so a late-arriving older list cannot roll the watch back. That is the rule `SyncMergeEngine` already applies to iCloud. The last list received is written to the watch's own Keychain under the same `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` protection the phone uses, rather than relying on the framework to redeliver the application context: the failure mode if that behaviour ever changes is a user reaching for their watch and seeing no codes, with nothing logged anywhere. The consequence is stated plainly in the README rather than glossed — a code cannot be shown without its secret, so a paired, unlocked watch is now another place a token exists. Two send triggers are load-bearing, and both were found by running against a paired watch rather than by reading the code: - `OTPDataStore.init` offers the loaded list, because the path a returning user takes — `loadCodes()` finding tokens already in the Keychain — calls `saveCodes()` not at all. Without it the watch stayed empty until the user happened to edit a token, which is exactly the case for someone who installs the watch app *after* filling their phone. - The relay re-offers on `AppActivity.didBecomeActive`, because `activationDidCompleteWith` was observed never to arrive at all on some launches, which left the watch on a stale list with nothing logged. **`Shared/`.** The OTP core — `OTPCode`, `OTPGenerator`, `OTPAlgorithm`, `ColorHex`, `KeychainStore`, `WatchTokenPayload` — moved out of `Vaultic/` so one implementation compiles into both targets, wired as a `PBXFileSystemSynchronizedRootGroup` in each. `ColorHex` picks up `canImport(UIKit)` in place of an `os(iOS)` test, because watchOS has UIKit too and macOS is the platform that genuinely lacks it, plus a `nonisolated init?(hex:)`, which the watch build needs to pass it as a function value under the module's default `MainActor` isolation. **Store metadata as JSON, in seven languages.** `metadata/` held `.strings` files, which `asc metadata validate` refuses outright ("no metadata .json files found"), so nothing could read them. The same values are now the canonical `.json` layout `asc metadata pull`/`push` speaks, and the extracted lengths match the live listing. 2.4 is localized into en-US, ja, es-ES, zh-Hans, pt-BR, de-DE and fr-FR; 2.0–2.3 stay en-US, since re-translating shipped release notes buys nothing. `CHANGELOG.md` records the conversion and why it happened. **The backend scaffold is gone.** `Vaultic/backend/` carried a Teenybase/Cloudflare Workers scaffold whose `.dev.vars` — live JWT signing secrets, an admin service token, a Mailgun API key — was copied straight into `Autheris.app` by the synchronized folder, and had been since `169e539`. Nothing used it: the app talks to no backend, the Blitz registrations pointing at it were dangling symlinks, its `node_modules` were never installed, `wrangler.toml` still held the starter template's placeholders, and no dev server ever ran. It is deleted along with `.claude/rules/teenybase.md` and the Teenybase section of `Vaultic/CLAUDE.md`, both of which told agents to use a backend that no longer exists. `VaulticTests/BundledResourcesTests.swift` now fails if developer material reaches the bundle again, matching by name *and* by shape — `.md`, `.toml`, `.ts`, hidden files — so a renamed or newly-added file is caught too, and it walks the whole bundle so the embedded watch app is covered as well. **Also.** Version 2.4, build 19, in all four places, with matching release notes in `ChangelogView` and `CHANGELOG.md`. The App Store screenshots are committed: the Mac set the README already described as committed, plus the new watch set. `ExportOptions.plist` for the Mac App Store `.pkg` export. And a `.gitignore` whose `.asc/`, `.dev.vars` and `.env` rules are the part that matters — this repository has committed a `.dev.vars` before. Verified on this tree: `xcodebuild test` on an iOS Simulator destination — 175 tests, 0 failures — and a `VaulticWatch` watchOS build.

• Hunter Eddington(25 Sept 26)

  Add an App Store review prompt Raises the system review prompt once per version, and only when the user changes a setting in Settings — a deliberate, engaged moment that is not in the middle of the task the app exists for. A Settings change is the only trigger: adding or copying a code deliberately does not count, because a prompt there interrupts the exact thing the user opened the app to do. Settings also gains a "Rate Autheris" row. It is a link to the product page with action=write-review rather than AppStore.requestReview, for two reasons Apple documents: the prompt API "may not present an alert" so must not be called from a button tap, and it has no effect at all in TestFlight builds. - ReviewPromptPolicy: pure, testable rules — vault of at least two codes, once per version, and nothing recorded when the version is unknown - PlatformReview: the one platform-specific requestReview anchor - support email -> [email protected], About -> autheris.app - the README's download badge pointed at a 404 (apps.apple.com/app/autheris) and its images at paths that do not exist on the new domain - CURRENT_PROJECT_VERSION 2 -> 3

• Hunter Eddington(24 Sept 26)

  Rename the Mac app to Autheris, ship 2.3 macOS takes an app's name from the bundle and CFBundleName, not from CFBundleDisplayName the way iOS does, so PRODUCT_NAME = "$(TARGET_NAME)" shipped a Mac app called Vaultic.app — in the Dock, the menu bar and the Applications folder. 2.2 has already gone live with that name. - PRODUCT_NAME = Autheris, with PRODUCT_MODULE_NAME = Vaultic so the Swift module the tests import keeps its name - TEST_HOST and the scheme's BuildableNames follow the new product - MARKETING_VERSION 2.2 -> 2.3, CURRENT_PROJECT_VERSION 1 -> 2 - 2.3 notes in the ChangelogView catalog, CHANGELOG.md and metadata/version/2.3/en-US.strings macOS 2.3 is submitted for review; iOS stays on 2.2.

• Hunter Eddington(23 Sept 26)

  Mac version release.

• Hunter Eddington(23 Sept 26)

  2.1 - iPad Support

• Hunter Eddington(22 Sept 26)

  docs: add CHANGELOG.md Backfill release notes for 1.0 through 2.0 from Vaultic/ChangelogView.swift.

• Hunter Eddington(21 Sept 26)

  2.0

• Hunter Eddington(21 Sept 26)

  Major 2.0 Final Push

• Hunter Eddington(20 Sept 26)

  2.0 Push

• Hunter Eddington(20 Sept 26)

  Big 2.0 Version

• Hunter Eddington(19 Sept 26)

  Added Change Log

• Hunter Eddington(18 Sept 26)

  Updated version

• Hunter Eddington(18 Sept 26)

  iCloud Sync Added

• Hunter Eddington(04 Sept 26)

  chore: restore final 1.2 release Remove the optional iCloud Sync implementation and restore the app source and project configuration to the final 1.2 release state.\n\nCo-authored-by: Copilot <[email protected]>

• Hunter Eddington(04 Sept 26)

  Revert "fix: preserve dirty local sync changes" This reverts commit 94de5ff68eacfc227fabacff212e2dfe0970f01e.

• Hunter Eddington(04 Sept 26)

  Revert "fix: avoid stale iCloud sync overwrites" This reverts commit 10c6d0c80e52579013ef7ab913f5d82d8aa109d9.

• Hunter Eddington(04 Sept 26)

  Revert "fix: pull changed CloudKit records reliably" This reverts commit 1893baacc71eeedd2d684cae73b400e754782d34.

• Hunter Eddington(04 Sept 26)

  Revert "fix: migrate iCloud sync metadata baseline" This reverts commit 74c90f76d5cbf1ef49b1f77b7afaaff815d7ab81.

• Hunter Eddington(03 Sept 26)

  fix: migrate iCloud sync metadata baseline Initialize last-synced hashes for metadata created by earlier app versions so existing devices do not repeatedly upload stale local records over newer CloudKit changes.\n\nCo-authored-by: Copilot <[email protected]>

• Hunter Eddington(03 Sept 26)

  fix: pull changed CloudKit records reliably Treat a changed CloudKit content hash as a remote update when the local device has no unsynced edit, and do not requeue remote-won records for upload in the same merge.\n\nCo-authored-by: Copilot <[email protected]>