AusweisApp: building the German eID client from source

What the AusweisApp is, and who publishes the binary

AusweisApp is the official electronic identity client of the federal government of Germany, the program a citizen uses to talk to the chip on the new German ID card. The project description says it plainly: it is the official eID client of the Bund, and the Governikus Service GmbH publishes the official version on behalf of the federal government at ausweisapp.bund.de.

What sits on GitHub is the source. The default branch is named community, and the code is C++ with a Qt user interface, with the repository topics pointing at the technology itself: apdu, eid, smartcard and ausweisapp2. The audience for the repository is narrower than the audience for the application. End users install the signed release from the government site. Developers, integrators and anybody who needs a build for a platform the official installer does not cover come here, and the rest of this article is about that second group.

The project is not archived, and the last push was on 2026-10-14, the same day the 2.6.1 release was tagged. Releases come thick and fast, with 2.5.5 on 2026-08-14, 2.6.0 on 2026-10-07 and 2.6.1 on 2026-10-14.

Two licences in one repository

The licensing arrangement is unusual enough to be the first thing an integrator should read. The README states that the source code is provided under the EUPL v1.2. A second file, LICENSE.officially.txt, applies exclusively to the official version of AusweisApp, the one that Governikus Service GmbH publishes on behalf of the federal government at ausweisapp.bund.de. A LICENSE.txt sits alongside both at the repository root.

The practical distinction is between what you compile and what you download. A binary you build from the community branch carries the EUPL v1.2 terms. A binary you take from the official distribution is covered by the separate terms in LICENSE.officially.txt, and the README is careful to draw exactly that line rather than presenting one licence for the whole repository. Whether either set of terms fits your organisation is a question for your own counsel, but the fact that two documents exist and apply to different artifacts is stated in the repository itself.

The repository also carries a Governikus_CLA.pdf, a contributor licence agreement, alongside an AUTHORS file, which tells you that outside contributions are expected and are covered by a contributor agreement rather than being merged informally.

The CMake configure step and the out-of-source rule

Building the desktop application means generating a Makefile with CMake, and the README shows the command-line form of that. The generator matters: under Windows with MinGW the README names "MinGW Makefiles", and with MSVC it names "NMake Makefiles" or "Ninja".

C:>cd C:/build
C:\build>cmake -G "MinGW Makefiles" -DCMAKE_PREFIX_PATH=C:/qt/dist C:/AusweisApp -DCMAKE_BUILD_TYPE=release

CMAKE_PREFIX_PATH is the mechanism for telling CMake where the toolchain lives, and the README notes that it is an alternative to putting the same folders on %PATH% or $PATH. The example assumes a Qt distribution unpacked at C:/qt/dist and a source tree at C:/AusweisApp, with the build happening in a third directory.

That separation is not a style preference. The README states that AusweisApp allows only so-called out-of source tree builds, and that the build folder must not sit inside the source folder. CMake also detects dependencies during the configure phase, so the configure run is where a missing toolchain shows up. One piece of documentation hygiene is worth flagging: the sample output pasted into the README still reports VERSION: 1.24.0 and a DVCS distance of 23, which is older than the 2.6.x releases described above, so treat that transcript as an illustration of the log format rather than a current description of the build.

Toolchain setup lives in the libs directory

No build instructions live in the root README alone. The setup of the toolchain is described in the ./libs subfolder, in a separate README there and a script beside it, and those two files exist to set up the build environment and to build the required external libraries with the appropriate patches. Anyone who wants to reproduce a build from source needs that directory, not just the top-level document.

The mobile variants add to that requirement. The README states that building the mobile version of AusweisApp needs, depending on the platform, additional external components, and that they are described in the Android and iOS sections of the same README under ./libs. In other words, the top-level README covers the desktop build and defers everything platform specific to a nested document, which is a mild but real friction point for newcomers.

The repository tree shows the supporting cast around the application code: src/ for the sources, test/ for the test suite with a CTestConfig.cmake, docs/, ci/ for CI helper scripts including a ci.cmake, cmake/ for the CMake modules, resources/ for assets, and CMakeGraphVizOptions.cmake for inspecting the CMake dependency graph. That last file is a hint about how large the CMake configuration has grown, since a visualised dependency graph is a tool for large build systems.

Android and iOS builds with their own toolchain files

On Android, CMake needs an explicit toolchain file, and the README gives the sequence including the extra make target that produces the package:

$ cd build
$ cmake -DCMAKE_PREFIX_PATH=/home/governikus/Toolchain/dist -DCMAKE_TOOLCHAIN_FILE=../AusweisApp/cmake/android.toolchain.cmake ../AusweisApp
$ make
$ make apk

The resulting AusweisApp apk lands under ./dist/bin. Signing the package needs environment variables when CMAKE_BUILD_TYPE is set to RELEASE:

QT_ANDROID_KEYSTORE_PATH=/home/governikus/AusweisApp.apk.keystore.jks
QT_ANDROID_KEYSTORE_ALIAS=ausweisapp
QT_ANDROID_KEYSTORE_STORE_PASS=123456

The default CPU architecture is armeabi-v7a, and the README gives the CMake parameter for changing it, -DCMAKE_ANDROID_ARCH_ABI=x86.

The iOS path is different in kind, because Xcode does the building rather than a Makefile. The provisioning profile is passed through the PROVISIONING_PROFILE environment variable, and the profiles configured in Xcode are visible under ~/Library/MobileDevice/Provisioning Profiles. The README also warns that XCode permission problems with the keys are common and that granting access to the macOS keychain often resolves them, with the matching security command given in the same paragraph.

The archive step then follows the usual Xcode pattern, producing an .xcarchive that is exported into an .ipa:

$ xcodebuild -configuration MinSizeRel -archivePath AusweisApp.xcarchive -scheme AusweisAppBinary -destination "generic/platform=iOS" archive
$ xcodebuild -configuration MinSizeRel -archivePath AusweisApp.xcarchive -exportArchive -exportOptionsPlist exportOptions.plist -exportPath .

Both mobile builds therefore demand a host macOS or Linux setup with a full vendor toolchain, and the iOS branch additionally needs a signing identity.

Packaging for Windows, macOS and Android

Once the build environment is in place, the packaging step differs per platform, and the README is explicit about why. Under Windows the WiX Toolset is required, and the README records version 6.0.0 as the one it was tested with. Running mingw32-make package builds the application and provides an MSI package. Under macOS, make package builds the application and provides a DMG.

Android is the odd one out, because CMake does not support the format yet, so two commands are needed after configuring the project:

$ make install
$ make apk

The fact that the Windows path uses mingw32-make rather than plain make is a small but real trap: following the macOS instruction on a MinGW shell gives you nothing.

The packaging chain is also where the licence split becomes visible in practice. The MSI and DMG you build yourself come from the community branch and fall under the EUPL v1.2 terms, while the signed installer the government publishes at ausweisapp.bund.de is a different artifact with its own licence file.

The container build and the reproducible-build claim

The repository carries a Dockerfile, and it is the fastest way to see what the maintainers consider the supported build environment. The build stage is based on Alpine, pinned through an ARG ALPINE_VERSION=3.24 argument, and the package list gives the dependency set in one line: patch, cmake, ccache, make, ninja, g++, pkgconf, pcsc-lite-dev, binutils-gold, eudev-libs, perl, python3 and linux-headers. The presence of pcsc-lite-dev and eudev-libs is the clearest signal of what the application does at runtime, since those are the pieces a smartcard client needs to talk to a reader.

FROM alpine:$ALPINE_VERSION AS builder
RUN apk --no-cache upgrade -a && apk --no-cache add patch cmake ccache make ninja g++ pkgconf pcsc-lite-dev binutils-gold eudev-libs perl python3 linux-headers

The Dockerfile also supports a remote ccache, configured through environment variables for the storage endpoint and flags for remote-only operation and resharing. A second file, Dockerfile.vnc, sits next to it, which suggests a variant intended for headless inspection of the running application.

On reproducibility the README is unusually committed. It says the build of the official binary is meant to be traceable, that the README in./libs describes the build environment and the external libraries, and that the CI configuration in the./ci/ subfolder and the.gitlab-ci.yml files lets a reader reproduce the build. The claim is specific: a rebuild should differ from the official binary only in paths, a date or timestamp, and signatures. The README also links to reproducible-builds.org for the wider context.

Tooling, quality gates and the pace of releases

The surrounding tooling shows how a government-adjacent project runs its quality checks, and much of it is visible in the file list. There is a .clang-tidy configuration for C++ static analysis, uncrustify.cfg for formatting, ruff.toml for Python, .yamllint and .yamlfmt for YAML, .qmllint.ini and .qmlformat.ini for the QML parts of the interface, .codespellrc and .typos.toml for spelling, and .grype.yml for the vulnerability scan. publiccode.yml records the project's metadata for the publiccode registry, and appveyor.yml and the GitLab CI files cover two different CI systems.

The release numbering moved from 2.5.5 on 2026-08-14 to 2.6.0 on 2026-10-07 and 2.6.1 on 2026-10-14, with the last push on 2026-10-14. The gap between the releases before and after 2.6.0 is about seven weeks, which is the pace to plan for if you need to track a specific fix.

For an integrator, the two things that matter most are the licence split and the build environment. Everything else, from the container image to the reproducible-build scripts, is there to make the second of those repeatable.

Editorial conclusion

Adopt the source build if you need to compile AusweisApp yourself for an internal rollout or a platform the official installer does not cover, and do not treat it as a general eID toolkit, since the code targets the German identity card. Before you start, read LICENSE.txt next to LICENSE.officially.txt to see which terms apply to what you produce, keep the build directory outside the source tree as the README insists, and check that a Qt distribution is present under the prefix you pass to CMAKE_PREFIX_PATH.

Frequently asked questions

Official sources

1. Governikus/AusweisApp on GitHub
2. Issues
3. Project website
4. README
5. Releases