Open-source project
strongbox-password-safe/Strongbox avatar
strongbox-password-safe/Strongbox

Strongbox for KeePass and Password Safe on iOS and macOS

A KeePass/Password Safe Client for iOS and OS X

1,470 stars126 forksObjective-CAGPL-3.0

At a glance

What is it?
Strongbox is a native password manager for Apple platforms that opens KeePass 1, KeePass 2, and Password Safe 3 files. It suits users who want to use an existing cross-platform vault, although the repository is source-available rather than a reproducible open-source build.
Who is it for?
Strongbox is appropriate for iPhone, iPad, and Mac users who already rely on KeePass or Password Safe files and value native Apple-platform access. It is a poor choice for developers who need to reproduce the complete application from source or organizations that require an OSI-compliant release.
Can I use it commercially?
Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
Is it still maintained?
Yes. The repository last received commits 98 days ago.
What is it written in?
Mainly Objective-C, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Strongbox's KeePass and Password Safe Use Case

Strongbox solves a specific vault-access problem: people who keep passwords in KeePass or Password Safe databases often use several operating systems, but not every password manager is native to iOS and macOS. Strongbox gives Apple-platform users a client for Password Safe version 3 files and KeePass 1 and 2 databases. The documented formats include KDB and KDBX releases 3.1 and 4, so users are not limited to a proprietary Strongbox database.

The application is aimed at users who manage credentials, groups, and individual entries across Apple devices. KeePass files can also contain file attachments, which Strongbox supports. The README also identifies YubiKey support and browser autofill extensions for Chrome, Chromium, and Firefox. Those features place Strongbox between a vault reader and a broader credential-management client rather than a minimal file viewer.

A useful distinction is that Strongbox is a client for existing password formats, not the origin of those formats. Its documentation credits the Password Safe and KeePass projects and says that their database parsing, navigation, interface, and cloud interaction are Strongbox's own work. This makes format compatibility the adoption point for anyone already invested in one of those databases. A user creating a new vault may have more freedom to choose a client that offers a documented cross-platform development workflow.

Vault Formats and Cryptographic Components

According to the README, Strongbox uses implementations associated with Twofish, Argon2d, ChaCha20, AES, and Salsa20. It also names SHA-256, HMACs, and cryptographically secure random number generators. The repository acknowledges TomCrypt and libsodium as the main sources of its cryptography, while Strongbox handles Password Safe and KeePass parsing, navigation, the interface, and cloud interaction.

The format list matters because file compatibility is not limited to a single KeePass generation. Strongbox documents KDB, KDBX 3.1, KDBX 4, and Password Safe version 3. That range is especially relevant during migration because it covers established KeePass generations, but the README does not document every edge case, attachment limit, or behavior associated with a particular database option. Compatibility should therefore be checked against a copy of the user's real vault before migration.

Strongbox also uses the Have I Been Pwned service through its Pwned Passwords API. The README does not state when that service is queried, what network metadata is sent, or whether every password check is available offline. Users with strict network-control requirements should inspect the application behavior before adopting it. The cryptographic algorithm list also should not be read as a substitute for reviewing the exact protected values and settings used by an existing database.

Apple Platform Coverage and Sync Boundaries

The repository layout reflects several Apple-specific surfaces rather than a single command-line program. Top-level entries include `macbox/`, `StrongBox Auto Fill/`, `StrongBox/`, `StrongboxWidget/`, `Watch-App/`, `Try Pro/`, and `Purchases/`. That arrangement indicates code associated with the Mac application, browser autofill, the main client, a widget, an Apple Watch application, trial handling, and purchases. The public README explicitly positions Strongbox for iOS and macOS and links an Apple App Store application.

The documentation also discusses cloud and local synchronization, but it does not provide a complete account matrix or explain which providers operate in every subscription tier. For iCloud trouble, the README suggests signing out of iCloud and iCloud Drive. For local file sync on macOS 15, it identifies a concrete permission failure: if Local Network access is denied, Strongbox cannot see peers on the LAN and local file sync can stop silently.

The documented recovery path is to open `System Settings`, select `Privacy & Security > Local Network`, and enable Local Network access for Strongbox. This is a platform permission issue rather than a database format issue. It also means that local sync has an operating-system dependency outside the app. Sync success should be verified on the exact macOS and iOS versions involved, especially when the vault is the primary copy of the user's password data.

Installing Strongbox and Making a First Vault Access

The README directs ordinary users to the Apple App Store rather than providing a reproducible application build. It links the following application page:

https://apps.apple.com/app/strongbox-password-safe/id897283731

The README says the free version is functional, but it does not document a first-run sequence for importing a KeePass database, enabling browser autofill, connecting a YubiKey, or validating a sync pair. Consequently, no import command or configuration file can be supplied without guessing. A first real use should begin with the existing vault file, open it in the store-installed application, and confirm that the expected groups and entries appear before making any changes.

After the initial open, the user should verify attachment access where relevant and confirm synchronization through a separate device rather than assuming that a successful import also means sync is configured. Browser autofill is distributed separately through the linked Chrome, Chromium, and Firefox extension listings. The README does not document the exact browser permissions or extension pairing steps, so those settings should be confirmed from the installed app and browser interface.

Why the Strongbox Source Tree Is Not a Reproducible Build

Strongbox explicitly says it is not easy to build from the source repository. The README instructs contributors not to file build issues and says that contributors are not currently accepted. It describes the code as the functional code used to build the app, while omitting non-functional assets such as artwork, images, and build configurations. Translation strings also live in the separate Babel repository.

A further build dependency is access to Google Drive, OneDrive, and Dropbox developer accounts with keys and secrets. Familiarity with CocoaPods and other build tools is also presented as a prerequisite. These omissions are substantial. A source checkout cannot be treated as a complete development package that an engineer can configure from documented inputs, and the README gives no supported build command that would make the omission reproducible.

The project addresses the licensing question directly. Its December 3, 2024 clarification says Strongbox is not compliant with the OSI definition of open source because the native application cannot be built easily from the repository. It notes that some observers may classify it as proprietary software or source-available software. The repository license is AGPL-3.0, but that identifier does not erase the project's own explanation that missing resources and build configuration prevent an easy native build. An organization choosing software partly on open-source criteria should record that distinction rather than treating the public repository as equivalent to a complete upstream build.

Strongbox Compared with KeePassXC-Style Vault Portability

KeePassXC is named in the acknowledgements, but the README gives only that mention and does not document a feature-by-feature comparison. The concrete difference available here is format and source-model related. Strongbox provides a native iOS and macOS client for KeePass 1 and 2, KDBX 3.1 and 4, and Password Safe 3 files. Its repository emphasizes Apple interfaces, browser autofill, an Apple Watch application, a widget, and platform permissions.

KeePassXC is associated in the README with cross-platform password management, but no claim about its exact supported formats, sync model, extensions, or source build should be inferred beyond that acknowledgement. The defensible comparison is therefore limited. Strongbox is a clear fit when the required destination is an Apple device and the existing source is a supported password database. It is less suitable when the immediate requirement is a complete source build from a public repository, because Strongbox itself says that this repository omits necessary application resources and build configuration.

Maintenance Evidence, Upgrades, and AGPL-3.0

The repository is not archived, and its last push was on 2026-07-17. The repository also has no GitHub releases. This means the GitHub release page cannot be used to inspect a documented upgrade history or packaged artifacts. The README points users to the App Store for the application, so end-user upgrades are expected to come through that distribution channel rather than GitHub Releases.

Upgrade planning therefore needs attention to the store-installed version, the user's vault format, and synchronization behavior. The documentation does not provide a database migration procedure, release notes tied to GitHub tags, rollback instructions, or compatibility guidance for each app version. It also does not state whether older KDBX or Password Safe files are transformed during normal operation. Users should keep a separate backup before upgrading or testing a new version, although the README does not prescribe a particular backup command.

The stated repository license is AGPL-3.0. The README separately says the application should not be redistributed to bypass built-in Pro or Free limitations. Those statements need to be reviewed together when considering forks, redistribution, or modified builds. This is a licensing and distribution boundary, not legal advice, and it differs from the project's explicit OSI-compliance statement.

Editorial conclusion

Strongbox is appropriate for iPhone, iPad, and Mac users who already rely on KeePass or Password Safe files and value native Apple-platform access. It is a poor choice for developers who need to reproduce the complete application from source or organizations that require an OSI-compliant release. Verify first that the store version opens and synchronizes your existing vault, that every required YubiKey workflow works on your devices, and that the AGPL-3.0 and source-available terms match your review requirements.

Frequently asked questions

Which password database formats does Strongbox support?

Strongbox documents support for Password Safe version 3, KeePass 1, and KeePass 2 databases, including KDB and KDBX 3.1 and 4. The README also says KeePass file attachments can be stored.

Can I build Strongbox from the GitHub repository?

The README says the source tree is not easy to build and does not accept pull requests or build-related issues. It omits artwork, images, build configurations, and other non-functional files, and it requires developer accounts with keys and secrets for Google Drive, OneDrive, and Dropbox.

Does Strongbox support YubiKey and browser autofill?

The README states that YubiKey is supported. It also links separate Strongbox autofill listings for Chrome, Chromium, and Firefox, but it does not document the exact pairing or permission procedure.

Official sources

  1. Issues
  2. License: AGPL-3.0
  3. Project website
  4. README
  5. strongbox-password-safe/Strongbox on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/strongbox-password-safe-strongbox.svg)](https://hysenlabs.com/projects/strongbox-password-safe-strongbox)

Was this useful?