# bitwarden/ios: two Swift apps and the extension soup around them

> The Bitwarden iOS repository is not one app but two, the Password Manager and the Authenticator, each with its own build, test and release pipelines, plus share extensions, an auto-fill extension and a watch app, all sharing a large Swift module set.

**bitwarden/ios** — Bitwarden mobile apps (Password Manager and Authenticator) for iOS.

- Repository: https://github.com/bitwarden/ios
- Website: https://bitwarden.com
- Stars: 714 · Forks: 171
- Language: Swift
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bitwarden-ios

## Two apps share one repository, and the pipelines know it

The repository holds the Bitwarden mobile apps for iOS, and the description names two of them: the Password Manager and the Authenticator. What makes the structure unusual is that the two are not just two folders in one build. The CI configuration at the top level shows four separate workflows: a build workflow for the Password Manager on main, a build workflow for the Authenticator on main, a test workflow for the Password Manager, and a test workflow for the Authenticator. The release tags confirm the split, with separate version lines for each app, such as Password Manager 2026.10.0 and Authenticator 2026.10.0, each carrying its own build number. The project configuration follows the same pattern, with separate Configs and Configs-bwa directories, separate Scripts and Scripts-bwa directories, and separate test helper sets named GlobalTestHelpers, GlobalTestHelpers-bwa and GlobalTestHelpers-bwth.

## The extension set is where most of the iOS-specific work lives

A password manager on iOS is mostly extensions, and the top level of the repository makes that concrete. There is a BitwardenAutoFillExtension, a BitwardenShareExtension for the share sheet, a BitwardenActionExtension, and a BitwardenNotificationExtension for handling notification content. An AuthenticatorBridgeKit sits alongside AuthenticatorShared and BitwardenShared, which suggests the two apps share a common core with a bridge for handing data between the password manager and the authenticator. A BitwardenKit directory and a BitwardenSdkMocks directory point at a separation between app code and the underlying SDK, with mocks standing in for the SDK in tests. BitwardenResources holds assets, and there is a separate Authenticator directory for the second app. Reading this list is the fastest way to understand the scope of the codebase before you look at a single line of Swift.

## The watch app and its widget live in the same tree

Apple Watch support is present and is broken out properly. BitwardenWatchApp, BitwardenWatchShared and BitwardenWatchWidgetExtension form a separate island in the top level, and the README files for the watch client, README-bwth.md, sit next to the Authenticator one, README-bwa.md, and the main README.md. The watch widget extension is a distinct target rather than a screen inside the main app. Two project definition files, project-bwa.yml and project-bwk.yml, sit at the root next to the Bitwarden.xcworkspace, so the Xcode workspace is checked in and the project files are generated or at least maintained outside it. A contributor editing the watch app is editing different targets, different test helpers and different pipelines from someone editing the Password Manager screens.

## The toolchain is pinned in the repository, not on your machine

The dotfiles at the root describe the development environment more precisely than most READMEs do. There is a .xcode-version file, a .ruby-version file, a .swiftformat configuration for formatting, a .swiftlint.yml for lint rules, a .typos.toml for spell checking, an .editorconfig, and a .gitattributes. There are also two test simulator settings, .test-simulator-device-name and .test-simulator-ios-version, which tell you the test run targets a specific simulator device and iOS version rather than whatever the machine happens to have. The Ruby side is managed with a Gemfile and Gemfile.lock, a Brewfile for Homebrew packages, and a Mintfile for the Mint package manager. Two separate licence manifests, .license-plist-bwa.yml and .license-plist-pm.yml, exist for the Authenticator and the Password Manager, which suggests third party licence listings are checked per app rather than once for the whole tree.

## Test infrastructure has its own directories and a shared harness

Testing gets as much attention as the app code here. There is a TestHarness directory with a matching TestHarnessShared, a TestHelpers directory, a ViewInspectorTestHelpers directory, and a TestPlans directory, which is where Xcode test plans live. The project also carries a Sourcery directory, pointing to code generation being part of the workflow rather than something done by hand. Translation goes through crowdin.yml, so the string catalogue is handled by Crowdin. The practical effect for a contributor is that the testing setup is not a single scheme. There are helper libraries, a harness, a plan-based runner and a simulator configuration, and getting a first test to run is the real work of a first contribution.

## Releases go out through fastlane, one app at a time

A fastlane directory at the root handles the release side, and the two version lines in the tags show it is driven separately for each app. The release naming is worth noting because it is unusual: the Password Manager 2026.10.0 release carries build number 3551 and the Authenticator 2026.10.0 release carries build 898, so the build counters are independent even though the version date matches. Before that, Password Manager 2026.9.1 with build 3533 shipped on 2026-10-02. The iOS apps are the visible surface of a much larger operation, and the project points at three related repositories for the rest of it: bitwarden/server as the core infrastructure backend with the API, the database and Docker pieces, bitwarden/clients for the non-mobile client applications, and bitwarden/directory-connector for syncing a directory such as AD, LDAP, Azure, G Suite or Okta to an organisation.

## Security reporting, licensing and the boundary of the repository

The project states that security audits and feedback are welcome, and asks that an issue be opened or that a private email be used if a report is sensitive in nature, with the security policy in the SECURITY.md file. The licence is GPL-3.0, with the text in LICENSE.txt at the repository root, which matters for anyone considering reusing code: a copyleft licence means a derived application has obligations that a permissive licence would not impose. And the boundary of this repository is worth stating plainly, because it is a common mistake to read it as the whole of Bitwarden. The mobile client is here, the server that stores and syncs your vault is in a different repository, and the desktop, browser and CLI clients are in a third. If you are trying to understand how a Bitwarden deployment works end to end, this repository only covers the phone and watch.

## Conclusion

bitwarden/ios fits a Swift developer who wants to work on a password manager or a two-factor authenticator where security is the product, and it fits anyone who wants to see how a large Swift codebase splits an app into shared modules, extensions and separately tested app targets. It does not fit a developer who wants to reuse it as a library, because this is application source under a GPL-3.0 licence rather than a package, and it does not fit someone who wants to build the app without a Mac, since the project depends on Xcode, simulators and a set of pinned tool versions. Before you open a pull request, read the iOS section of the Contributing Documentation for the build instructions and tooling, target your change at the main branch, and check which of the two apps it touches, because the Password Manager and the Authenticator have separate CI workflows, separate configuration directories and separate test helper sets.

## FAQ

### What is in the bitwarden/ios repository?

The Swift source for the Bitwarden mobile apps for iOS, which are the Password Manager and the Authenticator, together with the auto-fill, share, action and notification extensions, the Apple Watch app and its widget extension, and the shared module code they all build on.

### How do the Password Manager and the Authenticator builds differ?

They are separate apps with separate pipelines. The CI configuration has dedicated build and test workflows for each on main, and the release tags carry separate version lines, with the Password Manager 2026.10.0 at build 3551 and the Authenticator 2026.10.0 at build 898. Configuration, scripts and test helper directories are also split per app.

### What do I need to build the Bitwarden iOS apps?

The project sends contributors to the iOS section of the Contributing Documentation for build instructions and recommended tooling. The repository pins the toolchain itself with a .xcode-version file, a .ruby-version file, a .swiftformat config, a .swiftlint.yml, a Brewfile and a Mintfile, and the tests target a simulator named in .test-simulator-device-name and .test-simulator-ios-version.

### What licence is the Bitwarden iOS code released under?

GPL-3.0, with the licence text in LICENSE.txt at the repository root. The related server, non-mobile clients and directory connector live in separate repositories.

## Sources

- [bitwarden/ios on GitHub](https://github.com/bitwarden/ios)
- [License: GPL-3.0](https://github.com/bitwarden/ios/blob/main/LICENSE)
- [Project website](https://bitwarden.com)
- [README](https://github.com/bitwarden/ios/blob/main/README.md)
- [Releases](https://github.com/bitwarden/ios/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bitwarden-ios